Agentic AI has emerged as the software industry’s latest shiny thing. Beyond smarter chatbots, AI agents operate with increasing autonomy, making them poised to drive efficiency gains across enterprises.

“Agentic refers to AI systems that can take actions on behalf of users, not just generate text or answer questions,” says Andrew McNamara, director of applied machine learning at Shopify. Agentic systems run continuously until a task is complete, he adds, citing Shopify’s Sidekick, a proactive agent for merchants.

Development of agentic AI now spans many business domains. According to Anthropic, a provider of large language models (LLMs), AI agents are most commonly deployed in software engineering, accounting for roughly half of use cases, followed by back-office automation, marketing, sales, finance, and data analysis.

“A concrete example is in IT incident resolution,” says Heath Ramsey, group VP of AI platform outbound product management at ServiceNow. In this context, AI agents surface contextual data across systems, check prior resolutions and policies, issue fixes, update records, and loop in team members, he says.

But agent-centered development demands a new form of systems thinking to avoid pitfalls such as indeterminism and token bloat. There are also pressing LLM-derived security gaps, such as a model’s willingness to lie or fabricate information to achieve a goal, a condition researchers call agentic misalignment.

For teams building agents that integrate with other systems and reason through various options to execute multi-step workflows, the proper upfront planning is table stakes. For these reasons and more, agentic architecture design requires a new playbook. 

“Building agentic systems requires a fundamentally new architecture, one designed for autonomy, not just automation,” says Anurag Gurtu, CEO of AIRRIVED, an agentic AI platform provider. “Agents need a runtime, a brain, hands, memory, and guardrails.”

Although agentic AI shows promise, ROI from AI is a moving target. Less than half of organizations report a measurable impact from agentic AI experiments, according to Alteryx, with less than a third trusting AI for accurate decision-making.

So, what are the ingredients behind successful enterprise-grade agentic systems? Rather than focusing on how to build within a single vendor platform, let’s explore the common traits across agentic systems to surface practical guidance and lessons learned for developers and architects.

Architectural components of an agentic system

Agentic systems are composed of a handful of building blocks that make it all possible. Together, they form an interconnected web of software architecture, with different components serving different purposes. “Building an AI agent is like constructing a nervous system,” says Ari Weil, cloud evangelist at Akamai. 

This system spans layers for reasoning, memory, context-gathering, coordination, validation, and human-in-the-loop guardrails. “Agentic systems rely on a combination of AI, workflow automation, and enterprise controls working together,” adds ServiceNow’s Ramsey. 

Reasoning model

First off, if you break down agentic systems into their foundational components, you have to begin with the underlying model.

“A reasoning model sits at the core,” says Frank Kilcommins, head of enterprise architecture at Jentic, builders of an integration layer for AI. This reasoning engine performs the planning based on the user’s prompt, combined with the context-at-hand and available capabilities. 

Some reasoning models are better suited than others. “We look for models that feel agentic,” says Shopify’s McNamara. “They have the right amount of tool calls, and have strong instruction following that’s easy to prompt and steer.”

Context and data

Next, an agent needs context. This may take the form of internal company data, institutional knowledge and policies, system prompts, external data, memory of past chats, and agentic metadata, i.e., the user prompts, reasoning steps, and interactions with tools and data sources that allow you to observe and debug the agent’s behavior.

According to Edgar Kussberg, product director for AI, agents, IDE, and devtools at Sonar, sources for data can include databases and APIs, retrieval-augmented generation (RAG) systems and vector databases, file systems and document stores, internal dashboards, or external systems like Google Drive.

Organizations are actively building agentic knowledge bases to organize such data and streamline the retrieval process. Simultaneously, patterns are emerging behind semantic retrieval processes that power agentic context management systems.

“For memory, most teams combine a vector store like pgvector with something structured like a data catalog or knowledge graph,” says Anusha Kovi, a business intelligence engineer at Amazon. 

Tools and discovery

But for agents to be actionable, they need more than just static context — they need read and write access to databases, tools, and APIs.

“Some of the most important work being done to make agents more powerful is happening with the ways we connect AI and existing systems,” says Jackie Brosamer, head of data and AI at Block, the financial services company behind Square and Cash App.

To enable access to such capabilities, the industry has really coalesced around the Model Context Protocol (MCP) as a universal connector between agents and systems. MCP registries are emerging to unify and catalog MCP capabilities for agents at scale.

There are numerous public case studies of MCP use within agentic architectures, including Block’s open-source goose agent for LLM-powered software development and Workato’s use of MCP for Claude-powered enterprise workflows.

Defined workflows 

Another useful component is having clearly documented workflows for common procedures. These include multi-step actions that are interlinked between MCP servers or direct API calls. 

“What matters is that these agents are coordinated through defined workflows,” says ServiceNow’s Ramsey, “so autonomy scales in a predictable and governed way rather than becoming chaotic.”

Jentic’s Kilcommins describes how this can be achieved using “clear, machine-readable capability definitions,” referencing the Arazzo specification, an industry standard from the OpenAPI Initiative, as a method to document such behaviors.

Multi-agent orchestration

On that note, agents must be equipped to integrate with each other and fit well into a continuous feedback loop.

Multi-agent systems typically become necessary at scale, says AIRRIVED’s Gurtu. “Instead of one generalist agent, you often have teams of specialized agents such as reasoning agents, retrieval agents, action agents, and validation agents.”

This reality necessitates connective tissue. “At the core, you need an orchestration layer for the plan-do-evaluate loop,” says Amazon’s Kovi.

Common components for orchestration, adds Kovi, include LangGraph, a low-level orchestration framework, CrewAI, a Python framework for multi-agent orchestration, and Bedrock Agents, for helping agents automate multi-step tasks.

Open standards and protocols, like the A2A protocol for agent-to-agent communications, will also be important to enable AI agents to collaborate effectively.

Security and authorization

Given LLMs’ propensity to hallucinate and deviate from expectations, security is perhaps the most important element of building safe agentic systems.

“You’re no longer securing software that suggests, you’re securing software that acts,” says Gurtu. “Once agents can change access, trigger workflows, or remediate incidents, every decision becomes a potential control failure if it isn’t governed.” 

According to Kilkommins, the potential blast radius for agentic actions is huge, especially for uncontrolled, chained executions. He recommends having clearly defined permissions to avoid privilege escalation and sensitive data exposure.

In agentic systems, nuanced security methods are necessary. “An agent decides at run time what to query and what tools to call, so you can’t scope permissions the traditional way,” adds Kovi. Experts say that just-in-time authorization will be crucial to future-proof the non-human internet. 

Kovi adds that safety rules, like “don’t query personal information columns,” shouldn’t live in the prompt window. “Guardrails belong in identity and access management policies and configuration, not just prompt instructions.” 

Human checkpoints

Even with advanced authentication and authorization, sensitive actions will require human approvals.

Shopify defaults to “human-in-the-loop by design,” says McNamara. They’ve adopted approval gates to prevent fully autonomous changes to production systems. This allows merchants to review Sidekick’s AI-generated content before it goes live.

Others take a similar stance, particularly for financial transactions. “Our general rule is that anything touching production systems needs human checkpoints,” says Block’s Brosamer, referring to how user confirmation is a key element of Moneybot, the agent inside Cash App.

Evaluation capabilities

Building agentic systems also requires a good deal of upfront testing to evaluate whether outcomes match the intended results. 

For instance, Shopify performs rigorous pre-deployment evaluation on agentic outputs using both human testing and user simulation with specialized LLM-based judges. “Once your judge reliably matches human evaluators, you can trust it at scale,” says McNamara.

Others agree that evaluations are critical for enterprise-grade agentic systems. “Treat agents like regulated systems,” says Gurtu. “Sandbox changes, and test agents in simulation.” 

Behavioral observability

Lastly, another core layer is observability. For agentic systems, this must go beyond traditional monitoring or failure detection to capture advanced signals, such as why agents failed, or why they picked certain actions over others.

“Observability must be built in from day one,” says Sonar’s Kussberg. “You need transparency into every step of execution: prompts, tool calls, intermediate decisions, and final outputs.”

With more observable agent behaviors, you can improve the system continuously over time. As Kussberg says, “transparency fuels improvement.” 

Context optimization strategies 

Nearly all experts agree: giving AI agents minimal, relevant data is far better than data overload. This is critical to avoid maxing out context windows and degrading output quality.

“Thoughtful data curation matters far more than data volume,” says Brosamer. “The quality of an agent’s output is directly tied to the quality of its context.” 

At Block, engineers maintain clear README files, apply consistent documentation standards and well-structured project hierarchies, and adhere to other semantic conventions that help agents surface relevant information.

“Agentic systems don’t need more data, they need the right data at the right time,” adds Sonar’s Kussberg. “Effective systems give agents versatile discovery tools and allow them to run retrieval loops until they determine they have sufficient context.” 

The prevailing philosophy is to adopt progressive disclosure of information. Shopify takes this to heart, using modular instruction delivery. “Just-in-time context delivery is key,” says McNamara. “Rather than overloading the system prompt, we return relevant context alongside tool data when it’s needed.”

Others point out that context should include semantic nuances too, says Kovi. “If an agent doesn’t know ‘active users’ means something different in product versus marketing, it’ll give confident wrong answers,” she says. “That’s hard to catch.”

Architectural best practices

There are plenty of additional recommendations regarding agentic systems development. First is the realization that not everything needs to be agentified.

Pairing LLMs and MCP integrations is great for novel situations requiring highly scalable, situationally-aware reasoning and responsiveness. But MCP can be overkill for repetitive, deterministic programmed automation, especially when context is static and security is strict.

As such, Kilkommins recommends determining what behavior is adaptive versus deterministic, and codifying the latter, as this will allow agents to initiate intentionally-defined programmed behaviors, bringing more stability.

Determining the prime areas for agentic processes also comes down to finding reusable use cases. “Organizations that have successfully deployed agentic AI most often start by identifying a high-friction process,” says Ramsey. This could include employee service requests, new-hire onboarding, or customer incident response, he says. 

Gurtu adds that agents perform best when they are given concrete business goals. “Start with decisions, not demos,” he says. “What doesn’t work is treating agents like stateless chatbots or replacing humans overnight,” says Gurtu. 

Others believe that narrowing an agent’s autonomy yields better results. “Agents work best as specialists, not generalists,” Kussberg says. 

For instance, Shopify sets clear boundaries when scaling tools. “Somewhere between 20 and 50 tools the boundaries start to blur,” says McNamara. While some propose separating role boundaries with distinct task-specific agents, Shopify has opted for a sub-agent architecture with low-level tools.

“Our recommendation is actually to avoid multi-agent architectures early,” McNamara says. We are now getting into sub-agents with the right approach, and one key principle is to build very low-level tools and teach the system to translate natural language to that low-level language, rather than building out tools scenario by scenario.”

Experts share other wisdom for designing and developing agentic systems:

• Use open infrastructure: Open agents and vendor-agnostic frameworks allow you to use the best fit-for-purpose models.
• Think API-first: Good API design and clear, machine-readable definitions better prepare an organization for AI agents.
• Keep data in sync: Keeping shared data in sync is another challenge. Event-driven architectures can keep data fresh.
• Balance access with control: Keeping agentic systems secure will require offensive security exercises, comprehensive audit logs, and defensive data validation.
• Continually improve: To avoid agent drift, agentic systems development will inevitably require ongoing maintenance as the industry and AI technology evolve. 

The future for agentic systems

Agentic AI development has moved forward at a blistering pace. Now, we’re at the point where agentic system patterns are beginning to solidify.

Looking to the future, experts anticipate a turn toward more multi-agent systems development, guiding the need for more complex orchestration patterns and reliance upon open standards. Some forecast a substantial overhaul to knowledge work at large.

“I expect that in 2026, we will see experimentation with frameworks to structure ‘factories’ of agents to coordinate producing complex knowledge work, starting with coding,” says Block’s Brosamer. The most challenging aspect will be optimizing existing information flows for agentic use cases, she adds. 

One aspect of that future could be more emphasis on alternative clouds and edge-based inference to move certain workloads out of centralized cloud architecture to reduce latency.

“The future of competitive AI demands proximity, not just processing power,” says Akamai’s Weil. “Agents need to act in the real world, interacting with users, devices, and data as events unfold.” 

All in all, building agentic systems is a highly complex endeavor, and the practices are still maturing. It will take a combination of novel technologies, microservices-esque design thinking, and security guardrails to take these projects to fruition at scale in a meaningful and sustainable way — all while still granting agents meaningful autonomy.

The future looks agentic. But the smart system design underpinning agentic systems will set apart successful outcomes from failed pilots.

I’ve been arguing for a while now that enterprise AI won’t really take off until it gets boring. Not boring in the sense of uninspired; no, I mean boring in the sense that enterprises can trust it, govern it, observe it, and hand it to rank-and-file employees without undue concern that things will go wrong.

We have no shortage of over-funded startups clamoring to be the next big thing in AI, but not nearly enough that are quietly doing the essential work to make AI safe for enterprise consumption. Enter Stacklok.

On the surface, this might look like yet another startup trying to surf the AI agent wave. It’s not. Stacklok is exciting precisely because its executive team is deeply experienced in being unexciting. Back at Google, Craig McLuckie and Joe Beda were instrumental in the creation of Kubernetes. They took the messy, chaotic world of container orchestration and built an abstraction layer that made it “boring” enough that the largest banks, telcos, and retailers in the world could rely on it with confidence. Now they’re bringing that ability to wring order out of chaos to agentic AI, and they recognize that the real problem in enterprise AI has more to do with operational accountability than model quality.

I interviewed McLuckie and Beda to better understand the opportunity to create a “Kubernetes moment” in agentic AI.

Targeting accountability

McLuckie founded Stacklok in early 2023. Beda, his Kubernetes and later Heptio counterpart, had “semi-retired” in 2022. Beda doesn’t need to make more money, and he’s not joining out of nostalgia. As he tells it, this is “an extraordinary moment in the industry,” with “an opportunity to bring deep expertise in developer platforms and enterprise-grade infrastructure” to solving key enterprise problems.

“The biggest problem,” McLuckie says, “is accountability.” He explains: “An agent, no matter how sophisticated, no matter how capable, no matter how useful, cannot be held accountable for the work it undertakes.” That’s exactly right. A large language model can write code, summarize a contract, file a ticket, or trigger a workflow, but if it mangles customer data, oversteps its permissions, or keeps running after the employee who launched it has left the company, nobody gets to shrug and blame the model. The enterprise still owns the outcome.

Even OpenAI, which has been slower to take the enterprise seriously than Anthropic, now recognizes that enterprises need AI to fit inside workflows, controls, deployment models, and day-to-day operations. It’s no longer just about raw model prowess, as Tom Krazit writes. In other words, the market is slowly rediscovering what infrastructure people have known for a long time: Enterprises may buy capability, but they deploy control.

A related issue, according to Beda, is that AI’s speed changes everything. Tasks that used to take a human days or weeks may soon be completed in minutes by an agent. That doesn’t just create productivity. It creates scale, and scale turns manageable sloppiness into operational disaster. As he puts it, “The volume dial is going to 11 across the board.” I recently said that humans don’t use most of their granted permissions, but agents will. That’s exactly why identity, authorization, and auditability suddenly stop being problems for the security team and become architecture.

This is where the Kubernetes analogy is actually useful, rather than just founder mythmaking.

AI’s Kubernetes moment

Too many people remember Kubernetes as a container story. Enterprises embraced it for a more practical reason: It gave them a common operating model across environments, plus an ecosystem of policy, security, observability, and workflow tools layered on top. Cloud Native Computing Foundation now says 82% of container users run Kubernetes in production, and the organization explicitly frames Kubernetes as the operating system for AI. In our interview, McLuckie describes Kubernetes’ deeper contribution as “self-determination.” That is, it gave enterprises a consistent substrate on premises, at the edge, and in the cloud. That consistency is what helped an ecosystem to flourish around it.

Beda goes one step further: “One of the core ideas in Kubernetes is that you describe what you want to happen, and then you have the system go make it happen.” This, he says, means that Kubernetes is essentially “control theory rendered into software. Over time, an enterprise’s desired state moves into code, into version control, and into systems traceable back to accountable humans. Nerdy and sort of dull? Sure. But that’s the point. Enterprise AI doesn’t just need smarter models. It needs systems where humans declare intent, machines execute it, and the whole mess remains observable and auditable.

This is why I keep insisting that the biggest strategic question in agentic AI isn’t whether agents are cool. They are—or at least they can be. No, the real question is who owns the control plane. Stacklok matters because it is explicitly aiming at that layer. The company’s bet is that enterprises want to run and manage Model Context Protocol–based agent infrastructure on the Kubernetes they already know. They want policy, identity, isolation, and observability built in, not bolted on afterwards.

That last part matters because MCP is important, but it isn’t enough. Anthropic introduced MCP in November 2024 as an open standard for connecting AI systems to tools and data. Later, they donated it to the Linux Foundation’s Agentic AI Foundation to keep it neutral and community-driven. It worked. Anthropic reports there are now more than 10,000 active public MCP servers and support across ChatGPT, Cursor, Gemini, Microsoft Copilot, and VS Code.

That’s awesome, but it’s also not enough. Why? Because a protocol isn’t a platform. A protocol can help an agent talk to a tool, but it doesn’t, by itself, tell an enterprise who approved that agent, what data it can touch, how its actions are logged, or how to shut it down safely when the human who launched it has left the company.

Meeting users where they are

That’s where Stacklok’s self-hosted, Kubernetes-native bias starts to look smart rather than stodgy. (Though, again, “stodgy” isn’t a bad thing for risk-averse enterprises.) McLuckie is blunt: “If you’re an enterprise connecting agents to sensitive data, you are almost certainly not comfortable with that data egressing your security domain or being sent to a SaaS endpoint that a vendor controls.” We’ve seen this movie before. When your hosting, identity, tool integration, and policy layers all belong to the same vendor, “choice” starts to mean “replatform.”

No one wants that.

This is also where open source matters, though not in the simplistic sense that open source automatically wins. It doesn’t. Enterprises don’t buy ideology: they buy simplicity. But in a young market, they also value leverage. I’ve written before that open source doesn’t magically redistribute market power. What it can do is give customers options and some control over their fate. In AI, where model switching costs are still relatively low, that optionality matters. Talking with McLuckie and Beda, it’s clear they are open source true believers, but not obnoxiously so. That’s good, because enterprises don’t need a sermon on openness; they just need enough neutrality to avoid getting trapped while the market is still changing underneath them.

It’s all about meeting enterprises where they are and helping them to incrementally move to where they’d like to be. As McLuckie stresses, most enterprise AI teams are being asked to deliver more with AI while running with flat or capped headcount. They don’t need and can’t implement a grand theory of some idealized, fully autonomous enterprise. Instead, they need an accretive (golden) path from here to there using things they already understand, such as containers, isolation, OpenTelemetry, Kubernetes, existing identity systems, and existing observability stacks.

Sound boring? Good!

The opposite of “boring” in enterprise AI isn’t innovation. It’s slideware or demoware that looks great in a keynote but dies on contact with procurement, security review, compliance, and the first ugly bit of enterprise data. McLuckie captures this perfectly: “Vibe-coding a platform for two weeks can produce something plausible. It won’t produce something accurate, hardened, or enterprise-grade.”

Will Stacklok be the company that defines this layer? It’s way too early to say. Markets this young are littered with smart people who were directionally right and commercially wrong. But the company is aiming at the right problem, and that already puts it ahead of a depressingly large percentage of the AI industry.

Again, the next era of enterprise AI will be won by whoever makes agents governable, portable, observable, and boring enough to trust. Kubernetes helped do that for cloud-native infrastructure. Stacklok is betting the same playbook can work for agentic infrastructure. That’s not a nostalgic rerun of Kubernetes. It’s a recognition that enterprises still need what they’ve always needed: not more magic, but a way to control it.

Oracle says its new Trusted Answer Search can deliver reliable results at scale in the enterprise by scouring a governed set of approved documents using vector search instead of large language models (LLMs) and retrieval-augmented generation (RAG).

Available for download or accessible through APIs, it works by having enterprises define a curated “search space” of approved reports, documents, or application endpoints paired with metadata, and then using vector-based similarity to match a user’s natural language query to the most relevant of pre-approved target, said Tirthankar Lahiri, SVP of mission-critical data and AI engines at Oracle.

Instead of retrieving raw text and generating a response, as is typical in RAG systems that rely on LLMs, Trusted Answer Search’s underlying system deterministically maps the query to a specific “match document,” extracts any required parameters, and returns a structured, verifiable outcome such as a report, URL, or action, Lahiri said.

A feedback loop enables users to flag incorrect matches and specify the expected result.

Lahiri sees a growing enterprise need for more deterministic natural language query systems that eliminate inconsistent responses and provide auditability for compliance purposes.

Independent consultant David Linthicum agreed about the potential market for Trusted Answer Search.

“The buyer is any enterprise that values predictability over creativity and wants to lower operational risk, especially in regulated industries, such as finance and healthcare,” he said.

Trade-offs

That said, the approach comes with trade-offs that CIOs need to consider, according to Robert Kramer, managing partner at KramerERP. While Trusted Answer Search can reduce inference costs by avoiding heavy LLM usage, it shifts spending toward data curation, governance, and ongoing maintenance, he said.

Linthicum, too, sees enterprises adopting the technology having to spend on document curation, taxonomy design, approvals, change management, and ongoing tuning.

Scott Bickley, advisory fellow at Info-Tech Research Group, warned of the challenges of keeping curated data current.

“As the source data scales upwards to include externally sourced content such as regulatory updates or supplier certifications or market updates that are updated more frequently and where the documents may number in the many thousands, the risk increases,” he said.

“The issue comes down to the ability to provide precise answers across a massive data set, especially where documents may contradict one another across versions or when similar language appears different in regulatory contexts. The risk of being served up results that are plausible but wrong goes up,” Bickley added.

Oracle’s Lahiri, however, said some of these concerns may be mitigated by how Trusted Answer Search retrieves content.

Rather than relying solely on large volumes of static, curated documents that require constant updating, the system can treat “trusted documents” as parameterized URLs that pull in dynamically rendered content from underlying systems, according to Lahiri.

Live data sources

This enables it to generate answers from live data sources such as enterprise applications, APIs, or regularly updated web endpoints, reducing dependence on manually maintained document repositories, he said.

Linthicum was not fully convinced by Lahiri’s argument, agreeing only that Oracle’s approach could help reduce content churn.

“In fast-moving domains, keeping descriptions, synonyms, and mappings current still needs disciplined owners, approvals, and feedback review. It can scale to thousands of targets, but semantic overlap raises maintenance complexity,” he said.

Trusted Answer Search puts Oracle in contention with offerings from rival hyperscalers. Products such as Amazon Kendra, Azure AI Search, Vertex AI Search, and IBM Watson Discovery already support semantic search over enterprise data, often combined with access controls and hybrid retrieval techniques.

One key distinction, between these offerings and Oracle’s, according to Ashish Chaturvedi, leader of executive research at HFS Research, is that the rival products typically layer generative AI capabilities on top to produce answers.

Enterprises can evaluate Trusted Answer Search by downloading a package that includes components such as vector search, an embedding model to process user queries, and APIs for integration into existing applications and user interfaces. They can also run it through APIs or built-in GUI applications, which are included in the package as two APEX-based applications, an administrator interface for managing the system and a portal for end users.

Transformative new Python features are coming in Python 3.15. In addition to lazy imports and an immutable frozendict type, the new Python release will deliver significant improvements to the native JIT compiler and introduce a more explicit agenda for how Python will support WebAssembly.

Top picks for Python readers on InfoWorld

Speed-boost your Python programs with the new lazy imports feature
Starting with Python 3.15, Python imports can work lazily, deferring the cost of loading big libraries. And you don’t have to rewrite your Python apps to use it.

How Python is getting serious about Wasm
Python is slowly but surely becoming a first-class citizen in the WebAssembly world. A new Python Enhancement Proposal, PEP 816, describes how that will happen.

Get started with Python’s new frozendict type
A new immutable dictionary type in Python 3.15 fills a long-desired niche in Python — and can be used in more places than ordinary dictionaries.

How to use Python dataclasses
Python dataclasses work behind the scenes to make your Python classes less verbose and more powerful all at once.

More good reads and Python updates elsewhere

Progress on the “Rust for CPython” project
The plan to enhance the Python interpreter by using the Rust language stirred controversy. Now it’s taking a new shape: use Rust to build components of the Python standard library.

Profiling-explorer: Spelunk data generated by Python’s profilers
Python’s built-in profilers generate reports in the opaque pstats format. This tool turns those binary blobs into interactive, explorable views.

The many failures that led to the LiteLLM compromise
How did a popular Python package for working with multiple LLMs turn into a vector for malware? This article reveals the many weak links that made it possible.

Slightly off-topic: Why open source contributions sit untouched for months on end
CPython has more than 2,200 open pull requests. The fix, according to this blog, isn’t adding more maintainers, but “changing how work flows through the one maintainer you have.”

In a recent article chronicling the history of Microsoft Azure and its intensifying woes, we see a narrative that has been building throughout the industry for years. As cloud computing evolved from a buzzword to the backbone of digital infrastructure, major providers like Microsoft, Amazon, and Google have had to make compromises. Their promises of near-perfect uptime shifted from an expectation to “good enough,” influenced by economic pressures that have seen the cloud giants prioritize cost cuts and staff reductions over previously non-negotiable service reliability.

Frankly, many who follow the cloud space closely, including myself, have been warning about this situation for some time. Cloud outages are no longer rare, freak events. They are ingrained in the model as accepted collateral for the rapid growth and relentless cost-cutting that define this era of cloud computing. The story of Azure, as discussed in the referenced Register piece, is simply the latest and most prominent example of a much larger, industrywide trend.

This is not to say that cloud computing is inherently unstable or that its advantages—agility, scalability, rapid deployment—are a mirage. Enterprises aren’t abandoning the cloud. Far from it. Adoption continues at pace, even as these high-profile outages occur. The question is not whether the cloud is worth it, but rather, how much unreliability is acceptable for all that innovation and efficiency?

The price of cost optimization

If you trace the decisions of major public cloud players, a clear theme emerges. Competitive pressure from rivals translates to constant cost control, rushing services to market, shaving operational budgets, automating wherever possible, and reducing (or outright eliminating) teams of deeply experienced engineering talent who once ensured continuity and institutional knowledge. The comments from a former Azure engineer clearly illustrate how an exodus of talent, paired with an almost single-minded focus on AI and automation, is having downstream effects on the platform’s stability and support.

The irony is sharp: As cloud providers trumpet their AI prowess and machine-driven automation, the human expertise that built and reliably ran these platforms is no longer considered mission-critical. Automation isn’t a cure-all; companies still need experienced architects and operators who understand system limits, manage dependencies, handle failures, and respond deftly to unpredictable failures. Recent major outages reflect the slow but sure loss of that critically embedded human knowledge. Meanwhile, engineering decisions are increasingly made by those tasked with juggling ever-larger portfolios, new feature launches, and cost-reduction mandates, rather than contributing a methodical focus on resilience and craftsmanship.

Azure faces growing pains at scale, with tens of thousands of AI-generated lines of code created, tested, and deployed daily—sometimes by other AI agents —creating a self-reinforcing cycle of complexity and opacity. The resulting “compute crunch” puts even more strain on infrastructure, which, despite its sophistication, now handles heavier loads with fewer people providing oversight.

Outages aren’t driving users away

A natural question emerges: With reliability clearly taking a back seat, why aren’t enterprises reconsidering cloud altogether? I’ve argued for years that the game has changed. The benefits of cloud centralization, automation, and connectivity have become so fundamental to operations that the industry has quietly recalibrated its tolerance for outages. Public cloud is so deeply embedded into the business and digital operations that stepping back would mean undoing years, and often decades, of progress.

Headline-grabbing outages are dramatic but usually survivable. Disaster recovery plans, multi-region deployments, and architectural workarounds are now essentials for all major cloud-based companies. Building with failure in mind is a standard cost, not an avoidable exception. For most CIOs, the persistent risk of downtime is a manageable variable, balanced against the unmatchable benefits of cloud agility and in-house scale.

Providers know this well, and their actions reflect it. Outages may sting a bit in the press, but the real-world consequences have yet to outweigh the benefits to companies that push further into the cloud. As such, the providers’ logic is simple: As long as customers accept outages, however grudgingly, there’s little incentive to switch to costlier, less scalable systems.

How enterprises can adapt

With outages now the price of admission, enterprises should recognize that neither staff cuts nor the blind pursuit of automation will stop anytime soon. Cloud providers may promise improvements, but their incentives will remain focused on cost control over reliability. Organizations must adapt to this new normal, but they can still make choices that reduce their risk.

First, enterprises should prioritize fault-resistant cloud architecture. Adopting multicloud and hybrid cloud strategies, while complex, reduces the technical risk associated with reliance on a single provider.

Second, it’s crucial to invest in in-house expertise that understands both the workloads and the nuances of cloud service behavior. While the providers may treat their operations talent as expendable, nothing will replace the value of an enterprise’s in-house team to independently monitor, test, and prepare for the unexpected.

Finally, enterprises must enforce strict vendor management. This means holding providers accountable for promised service-level agreements, monitoring transparency in communication and incident reporting, and leveraging contracted services to their fullest extent, especially as the cloud market matures and customer influence grows.

The era of the infallible cloud is over. As public cloud providers pursue operational efficiency and AI dominance, resilience has taken a hit, and both providers and users must adapt. The challenge for today’s enterprises is to strategically mitigate the most likely consequences before the next outage strikes.

Anthropic has today released a new, improved Claude model, Opus 4.7, but has deliberately built it to be less capable than the highly-anticipated Claude Mythos.

Anthropic calls Opus 4.7 a “notable improvement” over Opus 4.6, offering advanced software engineering capabilities and improved visioning, memory, instruction-following, and financial analysis.

However, the yet-to-be-released (and inadvertently leaked) Mythos seems to overshadow the Opus 4.7 release. Interestingly, Anthropic itself is downplaying Opus 4.7 to an extent, calling it “not as advanced” and “less broadly capable” than the Claude Mythos Preview.

The Opus upgrade also comes on the heels of the launch of Project Glasswing, Anthropic’s security initiative that uses Claude Mythos Preview to identify and fix cybersecurity vulnerabilities.

“For once in technological history, a product is being released with a marketing message that is focused more on what it does not do than on what it does,” said technology analyst Carmi Levy. “Anthropic’s messaging makes it clear that Opus 4.7 is a safer model, with capabilities that are deliberately dialed down compared to Mythos.”

‘Not fully ideal’ in some safety scenarios

Anthropic touts Opus 4.7’s “substantially better” instruction-following compared to Opus 4.6, its ability to handle complex, long-running tasks, and the “precise attention” it pays to instructions. Users report that they’re able to hand off their “hardest coding work” to the model, whose memory is better than that of prior versions. It can remember notes across long, multi-session work and apply them to new tasks, thus requiring less up-front context.

Opus 4.7 has 3x more vision capabilities than prior models, Anthropic said, accepting high-resolution images of up to 2,576 pixels. This allows the model to support multimodal tasks requiring fine visual detail, such as computer-use agents analyzing dense screenshots or extracting data from complex diagrams.

Further, the company reported that Opus 4.7 is a more effective financial analyst, producing “rigorous analyses and models” and more professional presentations.

Opus 4.7 is relatively on par with its predecessor in safety, Anthropic said, showing low rates of concerning behavior such as “deception, sycophancy, and cooperation with misuse.” However, the company pointed out, while it improves in areas like honesty and resistance to malicious prompt injection, it is “modestly weaker” than Opus 4.6 elsewhere, such as in responding to harmful prompts, and is “not fully ideal in its behavior.”

Opus 4.7 comes amidst intense anticipation of the release of Claude Mythos 2, a general-purpose frontier model that Anthropic calls the “best-aligned” of all the models it has trained. Interestingly, in its release blog today, the company revealed that Mythos Preview scored better than Opus 4.7 on a few major benchmarks, in some cases by more than ten percentage points.

The Mythos Preview boasted higher scores on SWE-Bench Pro and SWE-Bench Verified (agentic coding); Humanity’s Last Exam (multidisciplinary reasoning); and agentic search (BrowseComp), while the two had relatively the same scores for agentic computer use, graduate-level reasoning, and visual reasoning.

Opus 4.7 is available in all Claude products and in its API, as well as in Amazon Bedrock, Google Cloud’s Vertex AI, and Microsoft Foundry. Pricing remains the same as Opus 4.6: $5 per million input tokens, and $25 per million output tokens.

What sets Opus 4.7 apart

Claude Opus is being branded in the industry as a “practical frontier” model, and represents Anthropic’s “most capable intelligent and multifaceted automation model,” said Yaz Palanichamy, senior advisory analyst at Info-Tech Research Group. Its core use cases include complex coding, deep research, and comprehensive agentic workflows.

The model’s core product differentiators have to do with how well-coordinated and composable its embedded algorithms are at scaling up various operational use case scenarios, he explained.

Claude Opus 4.7 is a “technically inclined” platform requiring a fair amount of deep personalization to fine-tune prompts and generate work outputs, he noted. It retains a strong lead over rival Google Gemini in terms of applied engineering use cases, even though Gemini 3.1 Pro has a larger context window (2M tokens versus Claude’s 1M tokens), although, he said, “certain [comparable] models do tend to converge on raw reasoning.”

The 4.7 update moves Opus beyond basic chatbot workflows, and positions it as more of “a copilot for complex, technical roles,” Levy noted. “It’s more capable than ever, and an even better copilot for knowledge workers.” At the same time, it poses less risk, making it a “carefully calculated compromise.”

He also pointed out that the Opus 4.7 release comes just two months after Opus 4.6 was introduced. That itself is “a signal of just how overheated the AI development cycle has become, and how brutally competitive the market now is.”

A guinea pig for Mythos?

Last week, Anthropic also announced Project Glasswing, which applies Mythos Preview to defensive security. The company is working with enterprises like AWS and Google, as well as with 30-plus cybersecurity organizations, on the initiative, and claims that Glasswing has already discovered “thousands” of high-severity vulnerabilities, including some in every major operating system and web browser.

Anthropic is intentionally keeping Claude Mythos Preview’s release limited, first testing new cyber safeguards on “less capable models.” This includes Opus 4.7, whose cyber capabilities are not as advanced as those in Mythos. In fact, during training, Anthropic experimented to “differentially reduce” these capabilities, the company acknowledged.

Opus 4.7 has safeguards that automatically detect and block requests that suggest “prohibited or high-risk” cybersecurity uses, Anthropic explained. Lessons learned will be applied to Mythos models.

This is “an admission of sorts that the new model is somewhat intentionally dumber than its higher-end stablemate,” Levy observed, “all in an attempt to reinforce its cyber risk detection and blocking bona fides.”

From a marketing perspective, this allows Anthropic to position Opus 4.7 as an ideal balance between capability and risk, he noted, but without all the “cybersecurity baggage” of the limited availability higher-end model.

Mythos may very well be the “ultimate sacrificial lamb” at the root of broader Opus 4.7 mass adoption, Levy said. Even in the “increasing likelihood” that Mythos is never publicly released, it will serve as “an ideal means of glorifying Opus as the one model that strikes the ideal compromise for most enterprise decision-makers.”

Palanichamy agreed, noting that Opus 4.7 could serve as a public-facing guinea pig to live-test and fine-tune the automated cybersecurity safeguards that will ultimately “become a mandatory precursory requirement for an eventual broader release of Mythos-class frontier models.”

This article originally appeared on Computerworld.