Tag: RPA

Every enterprise automation conversation in 2026 eventually arrives at the same three-way standoff. LLM vendors promise that language models can now reason through any workflow. RPA incumbents argue their bots aren’t going anywhere — they’re just getting smarter. And API platform teams quietly remind everyone that none of it moves without them.

All three are right. And all three are wrong about who’s in charge.

The real battle isn’t between tools — it’s between layers. Whichever vendor or framework controls the orchestration layer, owns your stack. Whoever owns your stack, owns your automation roadmap for the next five to eight years. That’s not a technology question. That’s a strategic one.

This post maps the fight layer by layer. Not from the perspective of “which tool should I pick” — that framing is already obsolete. Instead, it examines what each layer actually does, where the genuine architectural leverage sits, which vendors are quietly cementing control, and what the compounding costs of bad layer decisions look like in production. By the end, you’ll have a clearer picture of the battlefield than most of the vendors currently trying to sell you a seat at the table.

One critical framing note before we begin: this is not about which AI model wins. Model wars are largely over as a decision-making variable. GPT-4o, Claude 3.5, Gemini 1.5 Pro — they’re all capable enough for most enterprise workflows. The models are commoditising. The stack around the models is not.

The Stack Is Not a Tool — It’s a Power Structure

Most teams approach the agentic stack as a shopping list. Pick an LLM. Choose an orchestration framework. Bolt on some RPA bots for legacy system access. Wrap it in an API gateway. Ship it. This approach produces demos that look impressive and production systems that break in ways nobody anticipated.

The reason is that an agentic stack isn’t a collection of tools — it’s a layered power structure, where each layer makes decisions that constrain the layers below and depend on the layers above. If you pick those layers without understanding who controls them, who can change them, and what it costs to replace them, you’re not building automation infrastructure. You’re accumulating technical debt with a very impressive-looking interface.

The five load-bearing layers

A mature enterprise agentic stack in 2026 has five distinct layers, each with its own failure modes, vendor dynamics, and lock-in profile:

• Layer 1 — Reasoning: The LLM or model ensemble responsible for planning, decision-making, and natural language understanding. This is the layer most people obsess over — and the layer that matters least for long-term architecture decisions.
• Layer 2 — Orchestration: The runtime that coordinates agent tasks, manages state, handles retries, and routes decisions between agents and tools. This is the highest-stakes architectural decision in any agentic stack.
• Layer 3 — Execution: Where actual work happens — API calls, RPA bot triggers, database writes, file operations, browser automation. The execution layer is often inherited from existing infrastructure, which creates the RPA integration problem explored below.
• Layer 4 — Tool & API Access: The standardised interface through which agents discover, call, and authenticate against external systems. This layer has been fundamentally reshaped by the Model Context Protocol (MCP).
• Layer 5 — Governance & Observability: Audit logs, access controls, human-in-the-loop gates, cost monitoring, and behavioural evaluation. In 2026, this layer is frequently the difference between an agent that scales and one that gets shut down after its first major error.

Gartner projects that roughly 40% of enterprise applications will embed task-specific AI agents by the end of 2026 — up from under 5% in 2025. Most of those deployments will be decided by layer 2 choices made in the next 12 months. That’s the battlefield.

Why “which LLM” is the wrong first question

It’s tempting to anchor your stack decision to a model choice. In practice, well-architected stacks are model-agnostic at the reasoning layer — routing between GPT-4o, Claude, Gemini, and smaller fine-tuned models depending on task type, latency requirements, and cost targets. If your stack is deeply coupled to a single model provider at the reasoning layer, that’s not a feature — it’s a fragility.

The decision that locks you in isn’t which model you use. It’s which orchestration runtime you build your workflow logic inside. Everything downstream inherits that choice.

Layer 1: The Reasoning Brain — Model Routing Over Model Loyalty

The first question most teams ask when building an agentic stack is: “Which LLM do we use?” It’s a reasonable starting point — but in 2026, treating it as a binary decision is a sign of architectural immaturity.

Multi-model routing is now the baseline

Enterprise teams that have moved from pilot to production consistently describe the same progression. They start with a single model (usually OpenAI or Anthropic), get good demo results, move to production, then realise they need different models for different task types. A large context window model for document analysis. A smaller, faster model for real-time classification. A fine-tuned domain-specific model for compliance checks. A cheap open-source model for high-volume preprocessing.

Multi-model routing — dynamically selecting which model handles which task within a single workflow — has become a standard pattern. The orchestration layer handles this routing, which means your model provider diversification strategy is actually an orchestration layer design decision.

What the reasoning layer is actually responsible for

Within an agentic stack, the LLM reasoning layer performs four distinct functions that are worth separating in your architecture:

1. Planning: Breaking a high-level goal into a sequence of sub-tasks. This is where LLM quality most directly impacts workflow success rates.
2. Tool selection: Choosing which tool or API to call for each sub-task. Tool-calling reliability varies significantly across models and is often the most common source of workflow failures.
3. Context management: Maintaining relevant context across multiple steps without hallucinating or losing track of prior state. This is a context engineering problem as much as a model quality problem.
4. Exception handling: Recognising when a step has failed and deciding whether to retry, escalate, or reroute. Weaker models tend to loop silently; stronger models tend to escalate appropriately.

The practical implication: you don’t need your most expensive model doing all four. Planning and exception handling benefit from the strongest available model. Tool selection and preprocessing can often use smaller, cheaper alternatives — cutting per-workflow costs by 40–60% without meaningful quality loss.

Context engineering: the silent performance variable

One of the most underappreciated variables in reasoning layer performance is context design — what information the agent receives, in what order, and how it’s structured. A well-orchestrated context pipeline can make a mid-tier model outperform an expensive one on a specific task. This is why “context engineering” is increasingly discussed as a first-class skill alongside prompt engineering — and why it sits at the intersection of the reasoning layer and the orchestration layer.

Layer 2: The Orchestration Battlefield

If you want to understand where the real architectural power in an agentic stack is concentrated, watch which layer is generating the most VC investment, the most open-source activity, and the most enterprise vendor anxiety. That’s the orchestration layer. And in 2026, it’s genuinely contested terrain.

What orchestration actually does

Orchestration is the control plane of the agentic stack. It decides:

• Which agent runs next
• What state gets passed between agents
• When to call a tool vs. when to ask a human
• How to handle failures, timeouts, and retries
• How to route tasks across a multi-agent network
• How to enforce cost limits and governance policies

Get the orchestration layer wrong and no amount of model quality or RPA investment can save you. Get it right and you have a system that can absorb changes in models, tools, and business logic without requiring a full rebuild.

The main frameworks — and what they’re actually for

The four frameworks that dominate enterprise conversations in 2026 are LangGraph, AutoGen, CrewAI, and Temporal. They are not direct competitors in the way vendors sometimes present them. They solve different orchestration problems.

LangGraph (LangChain) is the closest thing to a general-purpose production orchestration runtime. Its graph-based state machine model gives teams precise control over workflow branching, cycle detection, and state persistence. LangSmith provides integrated observability. The trade-off is a steeper learning curve and strong coupling to the LangChain ecosystem — a lock-in risk that deserves deliberate consideration.

AutoGen (Microsoft) is optimised for conversational multi-agent systems and code-executing agents. It excels in research environments and developer tool workflows where agent-to-agent dialogue drives decision-making. The Microsoft backing means tight integration with Azure AI services — convenient if you’re already Azure-native, a significant constraint if you’re not.

CrewAI offers the fastest time-to-prototype for role-based multi-agent teams. Its abstraction model — where agents are assigned roles, goals, and backstories like members of a team — makes it accessible to developers who aren’t deep experts in graph theory or distributed systems. The downside is that this simplicity creates ceilings. Complex, stateful enterprise workflows tend to outgrow CrewAI’s abstractions.

Temporal is not strictly an AI orchestration framework — it’s a durable execution engine that has been widely adopted for agentic workflows requiring long-running, fault-tolerant processes. Where LangGraph manages agent reasoning graphs, Temporal manages the reliability of the execution itself: ensuring that a workflow that runs for hours or days doesn’t lose state when a server fails. Many mature production stacks use both — LangGraph for agent logic, Temporal for durability.

The convergence trap

In early 2026, the frameworks have been converging on similar abstractions: stateful graphs, tool registries, memory management, human-in-the-loop gates. This convergence makes it tempting to treat them as interchangeable. They are not. The differences that matter aren’t feature lists — they’re operational maturity, ecosystem depth, observability support, and most importantly, which cloud vendor controls the runtime’s long-term direction. Choosing AutoGen is, in practice, a partial bet on Microsoft’s AI roadmap. That may be exactly the right bet for your organisation. But it should be made explicitly, not by accident.

Layer 3: Where RPA Actually Belongs in a Cognitive Stack

The hottest take in enterprise automation circles in 2026 is “RPA is dead.” It makes for a compelling vendor narrative — particularly from LLM-native automation startups pitching against UiPath and Automation Anywhere. The reality is substantially more complicated, and the organisations that act on the “RPA is dead” thesis without nuance are discovering it through expensive production failures.

Why traditional RPA isn’t going anywhere — yet

Traditional RPA bots have a specific set of properties that make them genuinely irreplaceable for a class of enterprise workflows:

• Deterministic execution: A well-built RPA bot does exactly what it’s scripted to do, every time. In compliance-sensitive workflows — payroll, regulatory filings, audit trails — this predictability isn’t a limitation. It’s a requirement.
• Structured system integration: Many enterprise systems — particularly legacy ERP platforms, mainframes, and COBOL-era applications — don’t expose APIs. RPA bots interact with their UIs directly. Until those systems are modernised (a multi-year effort in most large organisations), RPA is the only practical access mechanism.
• Existing investment: The average large enterprise has hundreds to thousands of deployed RPA bots. Replacing them wholesale isn’t a technology decision — it’s a budget, risk, and operational continuity decision. The deprecation curve for mature RPA infrastructure is measured in years, not quarters.

The cognitive promotion: what agentic AI actually adds to RPA

The most accurate framing isn’t “agents replace RPA” — it’s “agents give RPA a manager.” In a well-architected hybrid stack, RPA bots remain the execution workers for deterministic, high-volume, rules-based tasks. Agentic AI handles the higher-level work that RPA can’t: interpreting unstructured inputs, handling exceptions, making contextual decisions, and coordinating across multiple systems.

Consider a practical example: invoice processing in accounts payable. A traditional RPA bot can extract structured data from a standard PDF invoice and enter it into an ERP system with high speed and reliability. But it fails immediately when the invoice is a scanned image with unusual formatting, or when it requires a decision about whether a line item qualifies for a specific cost centre, or when there’s a discrepancy that needs negotiation with the vendor. These exceptions previously required human intervention.

In a hybrid agentic stack, the LLM-powered agent handles the exception — reading the unstructured input, querying relevant policy documents via RAG, making a contextual decision, and then handing a structured instruction back to the RPA bot for execution. The bot does what it’s good at. The agent does what the bot can’t.

The three-tier execution model

The most effective enterprise automation architectures in 2026 use a three-tier execution model:

1. Deterministic tier (RPA bots): High-volume, rules-based, stable-format tasks. Zero tolerance for variability. Compliance-critical paths.
2. Adaptive tier (LLM agents): Exception handling, unstructured data interpretation, multi-step decisions, cross-system coordination.
3. Human-in-the-loop tier: Decisions above a defined confidence threshold, novel situations outside training data, high-stakes irreversible actions.

The RPA vendor ecosystem has responded to this reality. UiPath, Automation Anywhere, and Blue Prism are all shipping agentic AI integrations — positioning their bot infrastructure as the execution layer of agentic stacks rather than a competing paradigm. This is the correct architectural framing. It’s also a smart commercial survival strategy.

Layer 4: APIs as the Action Layer — Why Gateways Now Run the Show

The least glamorous layer of the agentic stack is the one that increasingly runs it. API gateways — long understood as security and traffic management tools — have become the functional nervous system of any enterprise agent deployment. In 2026, this shift has become too significant to treat as an infrastructure detail.

The action layer problem

An agentic system’s value is entirely determined by what it can do. Reading data is useful. Writing to a database, triggering a workflow, sending a notification, updating a CRM record, initiating a payment — that’s where automation value is actually realised. All of that happens through APIs. Which means every action an agent takes is an API call. And every API call is a governance event.

In a traditional application, API traffic is relatively predictable. A human user triggers an action; the application makes a call. Volume is bounded by human interaction speed. In an agentic stack, agents can make hundreds or thousands of API calls per minute, across dozens of endpoints, with tool selection driven by probabilistic LLM inference rather than deterministic code paths. The governance requirements are fundamentally different.

What the modern AI gateway does

The AI gateway — distinct from a traditional API gateway in its awareness of LLM-specific traffic patterns — now handles five distinct functions in the agentic stack:

• Tool discovery: Exposing a catalogue of available APIs to agents in a structured format they can reason about. Rather than agents being hardcoded with specific endpoints, they query the gateway for what’s available.
• Identity and access control: Enforcing which agents can call which APIs, under what conditions, and with what rate limits. This is especially critical in multi-agent systems where one agent might spawn sub-agents that inherit (or shouldn’t inherit) its permissions.
• Semantic routing: In advanced deployments, the gateway routes tool calls to the most appropriate backend based on the call’s intent — not just its endpoint. This enables fallback logic, load balancing across equivalent services, and graceful degradation.
• Cost and latency tracking: Logging the token cost, latency, and error rate of every tool call. Without this, there is no reliable way to track the true cost of an agent workflow or identify which tool calls are responsible for performance problems.
• Audit trail generation: Creating an immutable record of every action an agent took. In regulated industries, this audit trail isn’t optional — it’s a compliance requirement.

The gateway as the choke point of agent governance

Here’s the uncomfortable strategic reality: in an agentic stack without a well-configured AI gateway, there is no reliable way to control what your agents do. You can write governance policies at the orchestration layer, but if an agent can make direct API calls that bypass the gateway, those policies are advisory, not enforced. The gateway is the enforcement point. Building governance into the prompt is theatre. Building governance into the gateway is architecture.

The MCP + A2A Protocol Shift That Changes Everything

If there’s a single technical development in 2026 that most practitioners are underweighting, it’s the rapid standardisation of the Model Context Protocol (MCP) and the Agent-to-Agent (A2A) coordination protocol as the foundational communication standards of the agentic stack.

What MCP actually is — and why it matters beyond the hype

MCP, originally developed by Anthropic and now adopted broadly across the ecosystem, solves a specific and genuinely painful problem: how does an agent discover, authenticate against, and call external tools in a standardised way? Before MCP, every agent-to-tool integration was bespoke. Building an agent that could use Salesforce, Jira, a custom database, and a payment processor required four separate integration implementations, each with its own authentication handling, error management, and data serialisation logic.

MCP defines a standard protocol for this. An MCP server wraps an external tool or data source, exposes a standardised interface, and handles the translation between the agent’s requests and the tool’s native API. The agent doesn’t need to know whether it’s talking to Salesforce or a legacy internal database — it makes the same type of MCP call either way.

The practical impact: teams that have migrated their tool integrations to MCP report dramatically reduced integration maintenance overhead and the ability to swap underlying tools without rewriting agent logic. This is the portability benefit that matters most for long-term stack governance.

A2A: the agent-to-agent coordination layer

While MCP handles agent-to-tool communication, A2A (Agent-to-Agent protocol, championed by Google) handles a different problem: how do agents from different systems, built by different teams or vendors, coordinate with each other?

In a multi-agent enterprise workflow, you might have a procurement agent built on one framework, a compliance checking agent built by a vendor, and a financial approval agent built on a different platform entirely. A2A provides a standard protocol for these agents to discover each other, delegate tasks, and return results — without requiring a shared underlying runtime.

The emerging consensus is that MCP and A2A are complementary rather than competing standards. MCP is the agent’s interface to the tool layer. A2A is the agent’s interface to other agents. Together, they form what is beginning to look like a genuine interoperability standard for the agentic ecosystem — which would be significant if adoption continues at its current pace.

The gateway-as-MCP-broker pattern

The most architecturally elegant deployment pattern emerging in 2026 is the AI gateway functioning as an MCP broker — sitting between agents and MCP servers, adding governance, security, and observability to every tool call without requiring agents to handle those concerns themselves. This pattern cleanly separates the agent’s reasoning responsibility from the platform’s governance responsibility, which is exactly the separation you want for maintainability and compliance.

The Hidden Cost Stack Nobody Shows You at Demo Day

Vendor demos of agentic AI are, almost universally, cost-optimistic. This isn’t dishonesty — it’s the natural consequence of showing a system at demo scale rather than production scale, in a controlled environment rather than an enterprise one, with happy-path scenarios rather than exception-heavy real workloads. The TCO gap between a compelling demo and a sustainable production deployment is one of the most consistent sources of agentic AI project failure in 2026.

What vendors quote vs. what you actually pay

The visible costs in any agentic AI proposal are LLM token costs, software licensing, and cloud infrastructure. These are real costs — but in a mature enterprise deployment, they typically represent 20–30% of total spend. The 70–80% sits below the waterline:

• Orchestration engineering: Building, testing, and maintaining the workflow logic that coordinates agents is a significant engineering investment. Every edge case in a business process becomes an orchestration decision. Typical enterprise deployments require 2–4 senior engineers working on orchestration full-time for the first 6 months.
• Data preparation: Agents require clean, well-structured, contextually appropriate data. In most enterprises, data is messy, inconsistent, and scattered across siloed systems. Getting data to a state where agents can reliably use it is often the longest phase of any deployment — and it’s rarely in the vendor quote.
• Governance and compliance engineering: Building the audit trails, access controls, human-in-the-loop workflows, and policy enforcement mechanisms required for regulated industries is a separate engineering project running parallel to the agent development itself.
• Evaluation and quality assurance: Unlike traditional software, agentic systems require continuous behavioural evaluation — not just unit tests. Building evaluation frameworks, defining success metrics for agent behaviour, and running regular evals against those metrics is an ongoing operational cost.
• Human oversight infrastructure: Even well-performing agents need human review mechanisms for edge cases. Designing, building, and staffing those review workflows — the “human in the loop” — is a cost that’s often underestimated until the first major production incident.

The TCO multiplier in practice

Research across enterprise deployments in 2026 suggests that total cost of ownership for agentic AI stacks runs 2–3× naive initial estimates. For a mid-sized deployment initially quoted at $200,000 for the first year, realistic TCO including all the above layers is typically $400,000–$600,000. Upfront implementation costs for enterprise-grade stacks typically range from $40,000 to $200,000+, with ongoing operational costs of $5,000–$25,000 per month depending on scale and complexity.

This doesn’t mean agentic AI is a bad investment — the ROI data is compelling for well-scoped deployments. But it does mean that organisations evaluating proposals on quoted cost rather than realistic TCO are systematically underestimating the commitment they’re making.

The FinOps discipline for agentic stacks

The operational response from mature teams is treating agentic AI costs with the same rigour as cloud infrastructure costs — a FinOps discipline applied to the agent layer. This means per-workflow cost attribution, token budget controls enforced at the gateway layer, regular cost-per-outcome tracking, and explicit ROI review cycles tied to specific workflow automations rather than the program as a whole.

Teams that implement this discipline early consistently report better cost control and higher stakeholder confidence in continued investment. Those that don’t tend to experience the classic pattern: exciting early results, cost shock at the first renewal conversation, difficult internal justification battles.

Failure Modes That Don’t Show Up Until Production

The failure modes of agentic AI stacks are categorically different from those of traditional software. Traditional software fails in predictable, reproducible ways: a specific input triggers a specific error. Agentic systems fail in probabilistic, context-sensitive, sometimes-undetectable ways. Understanding this failure profile is essential for building production systems that survive first contact with real workloads.

The six failure categories that actually kill production deployments

1. Context overflow and information loss. As a workflow lengthens, the agent’s context window fills with accumulated task history, tool outputs, and intermediate results. When that window is exceeded — or when the agent is poorly designed and loses track of earlier context — it begins making decisions based on incomplete information. This produces outputs that are locally coherent but globally wrong, and they’re often extremely hard to detect without workflow-level tracing.

2. Tool call hallucination. Agents occasionally invoke tools with incorrect parameters, against endpoints that don’t exist, or with fabricated authentication credentials. Unlike a traditional software bug, this failure mode doesn’t throw an obvious error — it generates a plausible-looking API call that simply fails. Without comprehensive tool-call logging at the gateway layer, these failures are nearly invisible.

3. Infinite retry loops. When a tool call fails, a well-designed agent should either try an alternative approach or escalate to a human. A poorly designed one retries the same call indefinitely, or cycles between two failed approaches. Without hard timeout limits and loop-detection logic at the orchestration layer, this can exhaust both token budgets and downstream API rate limits before anyone notices.

4. State memory corruption in multi-agent systems. When multiple agents share access to a state store and one agent writes incorrect or malformed state data, every downstream agent that reads that state inherits the corruption. In a five-agent pipeline, a state corruption in agent two can silently invalidate the outputs of agents three, four, and five. This is the multi-agent equivalent of a database transaction failure — and it requires explicit state validation logic to catch.

5. Goal drift in long-running workflows. In workflows that run over hours or days, agent behaviour can drift from the original objective as accumulated context shifts the model’s interpretation of the task. This is especially pronounced in workflows where agents interact with external systems that return evolving data. The goal the agent is optimising for at step 50 may not be the same goal it was given at step 1.

6. Inter-agent trust escalation. In multi-agent systems, agents often delegate tasks to sub-agents. If permissions aren’t explicitly scoped at each delegation level, a sub-agent may inherit (or claim) permissions beyond what its principal intended. This is the agentic equivalent of a privilege escalation attack — and it’s a genuine security risk in any system where agents can create other agents.

Observability as a first-class design requirement

The common thread across all these failure modes is that they are invisible without purpose-built observability. Standard application monitoring — uptime checks, error rate dashboards, response time percentiles — does not capture the failure signatures of agentic systems. You need session-level tracing that records every agent decision, every tool call, every state transition, and every model inference, along with the ability to replay and inspect any workflow after the fact.

Teams that treat observability as a nice-to-have tend to discover these failure modes from user complaints or system incidents. Teams that build observability as a first-class infrastructure component discover them from their monitoring dashboards — a distinction that is the difference between proactive and reactive operations.

The Lock-In Map: Where You’re Already Trapped

One of the most consistent findings from enterprise architecture reviews in 2026 is that teams dramatically underestimate lock-in risk in their agentic stack decisions. This isn’t because they’re naive — it’s because the lock-in in these systems is structural and often invisible until you try to change something.

Where the real lock-in lives

Contrary to popular assumption, model-level lock-in is now the easiest to escape. Switching from GPT-4o to Claude or Gemini is largely an API and prompt engineering exercise — meaningful work, but achievable in weeks. The lock-in that actually constrains organisations for years is concentrated in different places.

Orchestration runtime lock-in is the most significant. Once you’ve built complex multi-agent workflows inside LangGraph’s state machine model, migrating that logic to a different orchestration framework is effectively a rewrite. Your workflow definitions, state schemas, memory patterns, and tool integrations are all expressed in the framework’s abstractions. That’s not porting — it’s rebuilding.

Memory and state layer lock-in is emerging as a critical new category. Agents that maintain long-term memory about users, processes, and organisational context accumulate that memory in specific formats tied to specific databases and retrieval systems. As these memory stores grow, they become increasingly difficult to migrate without data loss or quality degradation.

Hyperscaler platform lock-in is the most familiar pattern, and arguably the most dangerous. Microsoft’s Azure AI Foundry and Google’s Vertex AI are both building comprehensive agentic platforms that bundle orchestration, model access, storage, and governance into a single offering. The convenience is real. So is the eventual pricing power once switching costs are high enough to deter exit.

Proprietary agent platform lock-in from newer startups selling “complete agentic platforms” presents a different risk profile: these companies are early-stage, potentially less stable, and their platforms are less battle-tested in enterprise environments. The appeal is a faster time-to-value. The risk is platform instability, acquisition, or pivot.

The open vs. closed architecture decision

The strategic question isn’t whether to accept any lock-in — some is inevitable in any technology stack. The question is which lock-in you can afford and which you can’t. Teams that have navigated this most successfully in 2026 use the following framework:

• Keep the reasoning layer model-agnostic by design. Use routing abstractions that allow model swapping without workflow changes.
• Prefer open orchestration frameworks (LangGraph, Temporal) over proprietary platforms for complex workflows. Accept proprietary platforms only for well-scoped, contained use cases.
• Insist on MCP-compliant tool integrations as a procurement requirement. Non-MCP tool integrations create integration debt that compounds as the stack grows.
• Design the governance and observability layer to be cloud-agnostic. Audit logs, policy definitions, and evaluation frameworks should be portable — not stored in a hyperscaler’s proprietary format.

How to Architect for Composability, Not Just Speed

The instinct in any competitive technology adoption cycle is to move fast and standardise later. In enterprise agentic AI, this instinct is actively dangerous. The architectural decisions made in the first 6–12 months of a deployment define the composability ceiling for everything built on top of them.

The composability principle in agentic stacks

A composable agentic stack is one where new capabilities — new agents, new tools, new models, new workflow patterns — can be added without requiring changes to existing components. This sounds obvious. It’s surprisingly rare in practice, because the shortcuts taken during fast-moving initial development tend to produce coupling between layers that should be independent.

The most common composability failure: agents that are tightly coupled to specific tool implementations rather than to standardised tool interfaces. When the tool changes — the underlying API is updated, the vendor is replaced, the integration is refactored — agents that hold references to specific implementation details break. Agents that call through an MCP-standardised interface are insulated from those changes.

Design patterns for composable agentic architecture

The specialist-coordinator pattern: Design agents as specialists — narrow, deep, highly capable within a specific domain. Then build coordinator agents whose sole function is to route tasks to the appropriate specialist and aggregate results. This pattern mirrors how effective human organisations work, and it produces systems that are easier to extend (add a new specialist) without modifying existing components.

Explicit state contracts: Define the shape of the data that flows between agents as explicit schema contracts — not implicit conventions. Every agent publishes what state it expects to receive and what state it will produce. This contract becomes the interface that allows agents to be replaced or upgraded without breaking downstream consumers.

Graceful degradation by design: Every agent should have a fallback behaviour when its primary approach fails: retry with a different model, route to a simpler rule-based fallback, or escalate to human review. Systems designed with graceful degradation produce much more predictable failure modes and are dramatically easier to operate under adversarial real-world conditions.

Evals as the acceptance test: Before any agent component is promoted to production, it should pass a defined evaluation suite that tests its behaviour across representative edge cases. This is not optional quality assurance — it’s the mechanism that ensures the composable stack remains composable as it grows. Components without evals are components whose behaviour is undefined, and undefined components poison composability.

The governance-by-design imperative

One of the most consistent findings from organisations that have successfully scaled agentic stacks is that governance built into the architecture from the start is dramatically cheaper than governance retrofitted after deployment. Audit trails designed as a core feature cost a fraction of audit trails bolted on after the system is in production. Access controls defined at the orchestration level require a tenth of the engineering effort of access controls that have to intercept existing tool calls retroactively.

This isn’t just a technical observation — it’s a strategic one. Organisations that architect for governance from day one are consistently better positioned for the regulatory scrutiny that enterprise AI is beginning to face in 2026. Those that treat governance as a deployment-phase concern tend to face painful retrospective engineering when the audit or the regulator arrives.

Stop Choosing Tools — Start Owning Layers

The agentic stack wars are not going to be resolved by a single winning framework, a single winning model, or a single winning vendor. The enterprise automation landscape in 2026 is genuinely pluralistic — and that’s not a temporary state of market immaturity. It’s the permanent condition of an infrastructure layer that runs across too many different industries, regulatory environments, and legacy system profiles to be served by any monoculture.

What will be resolved, one enterprise at a time, is the question of which organisations have made deliberate, strategic choices about their stack architecture — and which have accumulated a collection of well-intentioned point solutions that don’t compose, don’t scale, and don’t survive the next vendor pivot.

The strategic reframe: layer ownership over tool selection

The most useful mental shift for engineering leaders, architects, and technology executives working through agentic stack decisions in 2026 is this: stop asking “which tool should I choose?” and start asking “which layers do I want to own?”

Owning a layer means having the architectural control to swap the underlying implementation without breaking dependent systems. It means your governance policies are expressed in your infrastructure, not in a vendor’s SaaS platform. It means your evaluation frameworks, observability systems, and state contracts are yours — not licensed from a third party who can change the terms.

You may choose to outsource some layers entirely — and that can be the right call for specific components at specific stages of maturity. But it should be a deliberate choice made with eyes open to the lock-in implications, not a default outcome of defaulting to whatever the most convenient vendor includes in the package.

Five actionable decisions to make before your next build sprint

1. Declare your model-agnosticism policy. Before writing a line of orchestration code, decide which models you’ll route between and design the routing abstraction. This is a 2-day architectural decision that saves months of rework later.
2. Choose your orchestration runtime deliberately, not by default. Evaluate LangGraph, Temporal, and your hyperscaler’s native offering against a specific rubric: lock-in profile, observability depth, stateful workflow support, and ecosystem stability. Make the decision in writing and document the trade-offs you accepted.
3. Set an MCP compliance requirement. New tool integrations go through MCP-compliant interfaces. No exceptions. This creates the portability infrastructure you’ll thank yourself for in two years.
4. Build your governance layer before you need it. Design the audit trail, access control, and human-in-the-loop mechanisms before the first production workflow goes live. The cost of doing this as a first-class design activity is a fraction of the cost of retrofitting it.
5. Deploy eval-first. Every agent component gets an evaluation suite before it touches production data. Define what “good behaviour” means in measurable terms, test against it, and gate promotion on it. This is the discipline that keeps a composable stack composable as it scales.

The longer view

The organisations that emerge from the agentic stack wars with durable competitive advantage won’t be the ones that moved fastest. They’ll be the ones that moved deliberately — building composable, governed, observable infrastructure that can absorb the inevitable model upgrades, framework evolutions, and vendor pivots that characterise any technology layer in early maturity.

The stack wars are real. The battleground is your orchestration layer, your API governance, your memory architecture, and your lock-in decisions. The outcome — whether you own your automation future or rent it from vendors who do — depends entirely on the architectural choices you make in the next 12 months.

The good news: those choices are still mostly in your hands. That window won’t stay open indefinitely.