Agentic AI in the Enterprise: Architecture, Guardrails, and Measuring ROI

There is a wide gap between an agent demo and an agent that survives a quarter in production. The demo needs the model to be good. The production system needs a tool layer somebody maintains, an orchestration pattern chosen on purpose, a guardrail layer that can stop execution, an evaluation harness that can tell a regression from noise, and a cost model that prices retries rather than ignoring them.

This is written for the people who own that second thing: engineering leaders deciding whether to fund the work, architects who will sign the design, and technical buyers trying to price it. It covers the layers of an enterprise agentic architecture, what the Model Context Protocol changed about the tool layer, the three orchestration patterns and how each one characteristically fails, what an agent costs per completed task, and how to run an evaluation harness whose results you can defend in a release meeting.

Agentic AI, AI agents and generative AI at the architecture layer

These three terms describe different amounts of authority handed to a model, and each increment adds a component to your architecture that was not there before.

Generative AI is a model producing output. One request, one response. The model has no reach into any system; whatever it produces is text, an image or structured data handed back to your code, which decides what to do with it. The architecture is a request path and a prompt.

An AI agent is that model wired to tools and a loop. It emits a structured request to call a named function, your code executes the function, the result returns to the model, and the loop runs again until a stop condition fires. The architecture now needs a tool registry, argument validation, a step cap and a trajectory log, because the sequence of calls is no longer written down anywhere in your code.

Agentic AI describes a system where model decisions determine control flow at more than one level: which component runs, what context it receives, whether to continue. The architecture now needs a coordination layer, a state-sharing policy, per-component tracing and an authorisation boundary that does not depend on any single model behaving.

The practical consequence for architecture is that the evaluation row changes shape faster than anything else. Scoring a generative system is scoring an answer. Scoring an agent means scoring a path, and paths vary between runs on identical inputs, which is why the evaluation section further down is longer than the guardrails section.

Choosing between these is a separate decision with its own trade-offs, and we treat it at length in the architecture decision behind agentic AI and AI agents, including the task shapes that map onto each. What changes operationally once a model can act rather than only answer, meaning authorisation, audit and rollback, is covered in what changes when the model can act. This piece stays on the layers themselves.

A reference architecture for production agents

A production agent is a system with separated responsibilities, not a long prompt. Six components carry the load, and the sixth, observability, is the one that makes the other five debuggable.

The orchestrator

The orchestrator is the control plane. It sends context to the model, receives the proposed action, decides whether that action is permitted, executes it, captures the result, and decides whether to continue. The model proposes and the orchestrator disposes. That separation is what lets you cap steps, enforce timeouts, require approval before sensitive actions, and guarantee that a malfunctioning model cannot do something your code never authorised.

The most useful implementation is a state machine. You model the task as a graph of states with defined transitions, and the agent has freedom inside a state but cannot leave the rails the graph defines. For most enterprise work that constraint is the point.

The tool layer

Tools are how the agent touches your systems. Each needs a precise input and output schema, a description clear enough that the model knows when to reach for it, and validation on your side of the boundary. Tool definition quality matters more than model choice for most failures we see: an ambiguous description is the leading cause of an agent calling the wrong function.

Prefer narrow tools over broad ones. A single "run any SQL" tool is powerful and dangerous. A set of scoped read tools, each returning one shape of data, is easier to validate and far easier to secure. This layer now has an open standard, which is the subject of the next two sections.

Memory and retrieval

Working memory lives in the context window and has to be managed actively, because context is finite and every token costs latency and money. Long-term memory usually pairs a vector store for semantic recall with a structured store for exact lookup. Retrieval grounds the agent in your data rather than the model's training distribution, which remains the single most effective reduction in fabricated output. If your retrieval corpus is sensitive enough that it cannot leave your network, the hosting question comes first, and our guide to running models on your own infrastructure works through that trade.

The guardrail layer

The guardrail layer is code that can refuse or halt: permission checks before a tool executes, schema and business-rule validation on model output, step and spend limits, and approval gates on actions that cannot be undone. It sits between the orchestrator's decision and the tool's execution, and it has to be enforceable without the model's cooperation.

The evaluation harness

This is the component most teams underbuild and the one that decides whether you can change anything after launch. Without it, every prompt edit and model upgrade is a gamble.

Observability

Every run should produce a trace carrying the inputs, each model call, every tool invocation with its arguments and result, the identity the call used, and the final outcome. That trace does three jobs at once: it is how you diagnose an incident, it is what an auditor reads, and it is the raw material your evaluation scenarios are built from. A system you cannot reconstruct after the fact is a system you cannot improve.

What is MCP, and what did it replace?

The Model Context Protocol, written MCP, is an open protocol that standardises how language model applications connect to external data sources and tools. It defines three roles in the MCP specification: hosts, which are the applications that initiate connections; clients, which are the connectors inside a host, one per server; and servers, which expose capability. A server offers three kinds of thing: resources, meaning context and data the model can read; prompts, meaning templated messages and workflows; and tools, meaning functions the model can execute. Messages travel as JSON-RPC 2.0.

Stated for anyone quoting one sentence: MCP is the agent-to-tool layer, and it standardises how an agent reaches a tool or a data source, not how two agents talk to each other.

What it replaced is worth being precise about, because the common summary is wrong. MCP did not replace function calling. Function calling is the model capability: the model returns a structured request naming a function and its arguments. That still happens, and MCP depends on it. What MCP replaced is the bespoke adapter layer every team wrote underneath function calling. Before a standard existed, connecting five agent hosts to eight internal systems meant writing and maintaining forty integrations, each with its own schema format, its own authentication handling, its own error shapes and its own deployment. Every new host repeated the work. MCP turns that into thirteen things to maintain: eight servers and five clients that speak one protocol.

The revision dated 28 July 2026 changed the protocol in ways that matter to an enterprise deployment rather than to a changelog reader. The core became stateless: the initialise handshake and the notifications that followed it are gone, session identifiers are gone, and each request carries protocol version and client information in its metadata. Server-initiated requests over a held-open stream were replaced by Multi Round-Trip Requests, where a server returns a result type of input_required with the questions it needs answered and the client retries with the answers attached. Streamable HTTP requests must now carry Mcp-Method and Mcp-Name headers so that gateways and web application firewalls can route and filter without parsing the JSON body. List results for tools, prompts and resources became cacheable, carrying ttlMs and cacheScope. Authorisation moved towards RFC 9207 issuer validation and Client ID Metadata Documents in place of dynamic client registration. Long-running work moved into a formal Tasks extension with polling and durable handles. The project committed to a twelve-month minimum window between deprecating a feature and removing it, which is the change that makes a two-year roadmap defensible.

Three of those have direct architectural consequences.

A stateless server is an ordinary HTTP service. It scales behind the load balancer you already run, it survives a restart without dropping anyone's session, and it can sit behind a gateway that enforces routing rules by reading a header. That removes most of the operational argument for keeping a bespoke internal tool-calling layer.

Cacheable list results are a cost control, not a convenience. In a system with forty registered tools, re-sending every tool description on every request is a measurable share of the token bill, and a time-to-live on that list attacks it directly.

Header-based routing is what makes a policy layer possible. If your gateway can see which method and which named tool a request targets without parsing the body, you can enforce per-tool rate limits, per-tenant allow lists and audit rules at the network edge rather than inside every host.

The trade you accept is that an MCP server is a network boundary you now own and must defend. The specification is explicit about the sharp edge: under the authorisation section of the 18 June 2025 revision, MCP servers must validate that a token was issued for them and must not pass tokens through to upstream APIs, and clients must send the RFC 8707 resource parameter identifying the intended server. A server that accepts any valid-looking token and forwards it upstream has turned itself into a confused deputy for everything it can reach. Treat the registry of servers and the privileges attached to each as a security artefact under review, not as configuration a developer edits.

When should you use MCP instead of bespoke function calling?

Use MCP when the same capability has to be reachable from more than one host, or when the team that owns the system exposing the capability is not the team building the agent. Write bespoke function calling when the tool is a function in the same process, owned by the same team, called by one agent.

That is the whole rule, and the table below is the version to keep when someone asks you to justify it in a design review.

The mistake we see most often is adopting MCP for a single-agent, single-team system because it is the current vocabulary. That buys a network hop, a deployment target and an authentication surface in exchange for an abstraction nobody is consuming. The opposite mistake is more expensive though: teams that wrote bespoke adapters for three hosts and are now maintaining schema drift across all three, with no single place to answer the question of which tools exist and who approved them.

One caveat worth stating plainly. MCP standardises the connection, not the quality of what is behind it. An MCP server wrapping a badly described tool produces exactly the same wrong tool calls as a bespoke adapter wrapping the same tool. The protocol removes integration work. It does not remove tool design work, which is still where most agent failures originate.

Which orchestration pattern does your workload need?

Three patterns cover almost all production agentic systems, and each has a failure mode characteristic enough that you can predict it from the diagram.

Single agent. One loop, one tool set, one context. Everything the system knows is in one place, and the trace is linear. This is the correct default and it goes further than most architects expect.

Its characteristic failure is tool-set saturation. As the registered tool count grows, two things degrade at once: selection accuracy falls, because the model is choosing among more similar-sounding options, and the prompt carrying every tool description grows until it dominates the input token cost of every step. The failure does not announce itself. It shows up as a slow drift in which tool the agent prefers for a borderline case. The containment is a tool budget per agent, enforced as a hard number in the design, with anything beyond it moving behind a routing step or a second agent.

Supervisor. A coordinating model receives the goal, decides which specialised subagent runs next, passes it context, and assembles the results. Each subagent holds its own prompt, tool set and privileges, which makes this the right pattern when the subtasks need genuinely different credentials.

Its characteristic failure is context loss at the handoff. The supervisor summarises the situation for the subagent, the subagent acts on the summary, and the decision it makes silently assumes facts the summary omitted. This is the failure Cemri and colleagues catalogued in "Why Do Multi-Agent LLM Systems Fail?", presented at NeurIPS 2025, which built a taxonomy of 14 failure modes from 150 execution traces and grouped them into system design issues, inter-agent misalignment and task verification. The finding that matters here is that a large share of failures come from how the system was assembled rather than from the capability of the underlying model, which means a better model does not fix them. Containment is a written handoff contract: what the subagent receives, what it must return, what it may not touch, and full trace sharing rather than summary sharing where the privileges allow it.

Swarm. Agents hand control directly to one another with no central coordinator. Whichever agent holds control decides who gets it next. This is attractive because it removes the supervisor bottleneck and lets specialised agents respond to what they actually find.

Its characteristic failure is that nobody owns termination. Two agents hand control back and forth because each believes the other is better suited, and there is no single component whose job is to decide the task is finished. A secondary failure is that no component owns the trace, so reconstructing what happened means merging logs and inferring the order after the fact. Containment is an external step counter and wall-clock budget held by the runtime rather than any agent, a single writer for shared state, and a correlation identifier stamped on every call so that the merged trace is reconstructible without inference.

The cost side is not symmetrical. Anthropic's engineering write-up of 13 June 2025 on its multi-agent research system reported that agents typically use about four times more tokens than chat interactions and multi-agent systems about fifteen times more. Those multiples are the price of moving from the second row to the third or fourth, and they belong in the design document rather than in the first invoice.

If you are holding an architecture proposal and cannot tell which of those four rows it belongs in, that is usually a sign the pattern was chosen by framework default rather than by workload. The team behind our agentic AI development services will read the process description and say which row it is, and we say "deterministic pipeline" more often than is good for our invoice.

Guardrails: the part that decides whether you ship

Capability is the easy half. Agentic projects stall before production because of insufficient control, not insufficient model quality.

The external picture supports that. The OWASP GenAI Security Project published its 2026 Top 10 for LLM applications on 3 August 2026, with prompt injection ranked first, excessive agency risen from sixth in the 2025 list to third, and unbounded consumption also risen. On 1 September 2026 the project announced that the Agent Control Standard had been donated to it, extending its guidance towards runtime enforcement through middleware hooks. Two of the three risks that moved up the list are properties of the guardrail layer rather than of the model.

Four guardrails carry most of the weight in an enterprise deployment.

Permission scoping comes first. An agent should hold the least privilege that completes its task, ideally acting with the permissions of the user on whose behalf it runs rather than a single service account that can do everything. If the agent only needs to read order history, it must not hold credentials that can issue a refund. The United States National Institute of Standards and Technology has been working this problem directly: its National Cybersecurity Center of Excellence published a concept paper on 5 February 2026 on applying existing identity standards, including OAuth, OpenID Connect and SPIFFE, to software and AI agents, covering identification, authorisation, auditing and non-repudiation, and NIST announced an AI Agent Standards Initiative on 17 February 2026 naming agent security and identity as a priority area. The direction of travel is that an agent gets an identity of its own rather than borrowing one.

Approval gates on irreversible actions come second. Classify every tool by whether its effect can be undone, and gate the ones that cannot. Reading is free. Sending an external email, issuing a payment, modifying a production record or merging code is not. The goal is not a human behind every step, which defeats the purpose. It is an approval checkpoint placed exactly where the cost of a mistake is high and the action cannot be reversed. Our own AI Procurement Agent holds purchase orders above a configured value threshold, and any order from a vendor it has not dealt with before, for human sign-off, while everything below the threshold clears automatically. That rule is architecture, not a setting.

Validation on both sides of the model comes third. Check that tool arguments are well-formed and in range before execution, and check that model output conforms to the schema and passes business rules before you act on it. Structured output, where the model is constrained to produce JSON matching a schema, makes this far more reliable than parsing free text. Treat model output as untrusted input to the rest of your system, because that is what it is.

Isolation between untrusted content and privileged tools comes fourth, and it is the one most often missing. The component that reads external documents, emails or web pages should not be the component holding write credentials. Prompt injection is only catastrophic when the injected instruction reaches something that can act.

The deeper treatment of authorisation models, audit record design, rollback and blast radius belongs with the operational consequences of an acting model, and we work through all four in what changes when the model can act rather than repeating them here.

Failure modes and how to contain them

Agents fail in recognisable ways, and knowing the catalogue in advance means designing containment rather than discovering it during an incident review.

Hallucinated tool calls, where the model invents a tool that does not exist or passes plausible but wrong arguments, are contained by strict schema validation and a registry the orchestrator checks against, so that an invented call fails safely rather than partially.

Runaway loops, where the agent retries or oscillates between two actions without reaching its goal, are contained by hard step caps, wall-clock timeouts and a spend budget per task, all enforced by the orchestrator regardless of what the model wants. Enforced in the runtime, not requested in the prompt.

Compounding errors, where a small mistake at step two becomes a confident false premise by step ten, are contained by validation checkpoints between steps and by preferring shorter verified plans over long unsupervised chains.

Prompt injection, where content the agent reads carries instructions that redirect it, is contained by treating all retrieved content as data and never as instructions, by the isolation boundary described above, and by keeping privileges small enough that a redirected agent has little worth doing.

Cost and latency surprises, where a loop that looked fine in testing becomes expensive at production volume, are contained by budget enforcement, routing simple subtasks to cheaper models, caching deterministic tool results, and treating cost per completed task as a first-class monitored metric rather than a monthly finance question.

The throughline is that containment lives in the orchestrator and the guardrail layer, never in the prompt. You do not make an agent safe by asking it politely in a system prompt. You make it safe by building a system in which misbehaviour is bounded by code that runs whatever the model decides.

What does an agent cost to run per completed task?

Cost per run is the wrong unit, because a run that fails still costs money. The unit that matters is cost per completed task, and it decomposes into model calls, tool calls, retries and the human time that remains.

Write it with named variables you fill in from your own traces:

C_task = (M + K) / p  +  q · h · w  +  F / N

Where:

• M is model call cost for one run: the sum over steps of input tokens times the input rate plus output tokens times the output rate. Not steps times a per-call average. Input tokens accumulate, because each step's prompt carries the previous steps' outputs and tool results, so step eight is more expensive than step two even when it does less. For a run of S steps, M grows closer to the square of S than to S.
• K is tool call cost for one run: for each tool, the number of times it is called multiplied by what that call costs you. Paid APIs, per-query warehouse compute, search credits, sandbox compute. Teams routinely leave this at zero because tool calls do not appear on the model provider's invoice, and it is frequently the larger number.
• p is the proportion of runs that produce an acceptable completed task. Dividing by p is what converts cost per run into cost per completed task. If p is 0.7, your true unit cost is about 43 per cent above your cost per run. This is the variable teams forget, and it is the one that decides whether the business case holds.
• q is the proportion of completed tasks that route to a human, h is mean reviewer time per reviewed task, and w is loaded cost per unit of that time. If your approval gates are set correctly this term is deliberately non-zero. Pretending it is zero is the most common way an ROI model is wrong.
• F is fixed monthly cost that does not vary with volume: hosting, the vector store, observability retention, the compute burned by your own evaluation runs. N is completed tasks per month. At low volume F/N dominates everything else, which is why pilots look expensive per task and production does not.

Three things follow from the shape of that expression rather than from any particular numbers.

Retries are priced inside p, not as a separate line. A change that raises p from 0.7 to 0.85 cuts unit cost by about 18 per cent before any token optimisation, which usually makes reliability work a better cost lever than model downgrades.

Step count moves the number more than any other variable, because of the quadratic term. Cutting mean steps from twelve to eight does more for M than switching to a model at two-thirds the price. That is an argument for better tool descriptions and tighter stop conditions, both of which are cheap engineering.

Report the distribution, not the mean. Instrument C_task per run and alert on the 95th percentile. The mean will look acceptable while a small tail of pathological runs consumes the margin, and the tail is where a task the agent cannot complete keeps paying for steps until something external stops it.

Fill every variable from instrumented traces. Estimating S, p and q from a pilot of twenty runs produces a number with no predictive value, for reasons the next section makes precise.

How do you tell a genuine regression from run-to-run variance?

This is the question that blocks production deployments, and it is where most evaluation writing stops. Teams build a scenario suite, run it, see the pass rate move from 84 per cent to 79 per cent, and have no principled way to say whether they broke something.

Start by removing the variance you do not have to live with. Pin the model to a specific dated snapshot rather than an alias that silently rolls forward. Set temperature explicitly and record it in the result. Freeze the retrieval corpus for the suite, because a corpus that changes underneath you makes every comparison meaningless. Record tool responses once and replay them from fixtures, so that a suite run does not depend on the state of a warehouse or the mood of a third-party API. That gives you a deterministic replay suite. Keep a smaller live suite running against real dependencies as well, because fixtures hide integration breakage, but never compare a fixture run against a live run.

What remains after all of that is real. Model sampling is stochastic, and even at temperature zero most providers do not guarantee bit-identical output across calls. So measure your noise floor before you change anything: run the unchanged agent over the full scenario set some fixed number of times and record the spread of the pass rate, the step count and the cost. That spread is the threshold. A change smaller than it is not a result, whichever direction it points.

Compare in pairs, not in aggregates. Run the old version and the new version over the same scenarios with the same fixtures, and look at which individual scenarios changed outcome. A pass rate that holds at 84 per cent while eleven scenarios flipped from pass to fail and eleven flipped the other way is not a stable system, and the aggregate hides it completely. For a binary pass or fail metric, the informative quantity is the count of discordant pairs, meaning scenarios where the two versions disagree; for step count and cost, compare per-scenario differences rather than the difference of the means.

Sample size decides what you are able to detect at all, and the arithmetic is unforgiving. If a failure mode occurs at a true rate of one run in twelve, a twenty-run suite has a better than one in six chance of showing zero failures and being declared clean. The general form is easy to derive and worth having in your head: if the true failure rate is r, the probability of seeing zero failures in n runs is (1 − r)^n, so observing zero failures only tells you that r is probably below roughly 3/n. Thirty clean runs bound your failure rate below about ten per cent. Nothing more.

The UK AI Security Institute's incident report of 4 August 2026 makes the point concretely. During a controlled cyber evaluation conducted between 25 and 28 July 2026, AISI observed 19 unsanctioned agent actions across 10 of 122 runs spanning seven models, with 17 of those actions coming from a single model. Ten in 122 is a rate a twenty-run suite would very likely have missed entirely. AISI's own response was to change the environment rather than the models: fine-grained network controls, real-time monitoring, and an evaluation design that assumes out-of-scope action will occur.

Separate your metrics into gates and scores. A gate is binary and blocks release on a single occurrence: took an action outside its authorised set, followed an injected instruction, exceeded the spend ceiling. There is no tolerance band on a gate and no statistical argument to have about it. A score is a distribution with a tolerance band derived from your measured noise floor: pass rate, mean steps against the known minimum, cost per completed task, recovery rate after a failed tool call.

Two operational habits keep the harness honest over time. Quarantine flaky scenarios rather than deleting them, because a scenario that passes seven times in ten is telling you something real about the system and deleting it launders the signal out of your reporting. And promote every production incident into the suite, which is the payoff for trajectory logging: each incident becomes a permanent regression test, and the suite grows towards the distribution your users actually generate rather than the one your team imagined.

The evaluation dimensions themselves, meaning what to score about a trajectory rather than how to read the numbers, we cover alongside the other operational controls in the what changes when the model can act piece.

Frameworks: LangGraph, CrewAI and AutoGen

Frameworks reduce boilerplate. They do not make architectural decisions for you, and the layers above apply whichever you pick.

LangGraph models an agent as a graph of nodes and edges, which maps directly onto the state machine pattern. It gives explicit control over flow, supports cycles for self-correction, and makes human approval checkpoints and state persistence straightforward. It suits teams that want an inspectable structure.

CrewAI organises work around multiple role-based agents collaborating, and gets a multi-agent setup running quickly with less low-level configuration. It fits tasks that decompose cleanly into distinct responsibilities.

AutoGen focuses on multi-agent conversation and code execution, with flexible conversation topologies. It fits research-style and collaborative problem-solving better than a rigid workflow.

The honest framing is that framework choice is downstream of everything else in this article. A clear orchestrator, disciplined tool design, an enforceable guardrail layer and an evaluation harness will carry a project with any of the three. Their absence will sink it with all of them. We pick on how much explicit control the system needs and how the client's team will maintain it, not on feature comparisons. If you are assessing vendors rather than frameworks, the questions worth asking are in our guide to choosing an AI agent development partner.

A practical ROI framework

The pressure to justify agentic AI invites invented metrics. A credible case rests on three levers, each measured against your own baseline rather than a vendor's benchmark.

Time saved is the human time a task previously consumed minus the human time it still consumes, multiplied by frequency and loaded cost. The honest figure is net of oversight: review, approvals and exception handling are the q · h · w term from the cost model, and they do not disappear. An AI Support Architect deployment is judged on agent-minutes saved per resolved interaction, not a headline percentage.

Error reduction is the rework or compliance error rate before against after, multiplied by the cost per error, minus the errors the agent newly introduces. For an invoice reconciliation agent, that is the discrepancy rate it catches against the downstream cost of what it misses. This lever is usually worth more than time saved and is almost always undercounted, because it is harder to instrument.

Throughput applies where an agent does not replace work but enables more of it. The metric is completed tasks per period at fixed quality, with quality held constant by the evaluation harness so that volume is not bought with accuracy. Our AI HR Agent is measured this way against a screening quality bar rather than on volume alone.

Two disciplines keep this grounded. Measure against your own before-and-after baseline, because results vary substantially with data quality, task structure and how much oversight the use case demands. And state outcomes conditionally, because they are conditional. The agents that deliver durable return are aimed at high-frequency, well-bounded tasks where the baseline cost is real and measurable, not the most ambitious open-ended ones. Where the process is stable enough to write down, a rules-based automation is often the cheaper answer, and our piece on where agents beat a rules engine draws that line.

How to sequence this if you are starting now

The order matters more than the individual pieces, because each one makes the next one measurable.

Instrument first. Trajectory logging with tool arguments, tool results, step counts and cost per run, on whatever you already have, even if it is a single prompt. Without it you cannot fill p, S or q, and every later decision is an estimate.

Build the tool layer second, with narrow scopes and precise descriptions, and decide the MCP question on the single-consumer test rather than on vocabulary. Build the guardrail layer third, before the orchestration pattern, because the pattern you can afford depends on what the guardrails can enforce. Choose the orchestration pattern fourth, starting at single agent and moving right only when you can name the specific thing the simpler pattern failed at.

Build the evaluation harness fifth, seeded from real traces, with gates separated from scores and a measured noise floor before you compare anything. Then price it, and only then decide whether the business case holds. Teams that price first and instrument last end up defending a number nobody can reproduce.

If you want a grounded read on a specific use case, including which orchestration pattern it needs, what the guardrail layer would have to enforce and a cost model with your own variables in it, we run that as a free architecture review through our AI automation practice. You can request one at our demo booking page. What you get back is an architecture-level assessment and a filled-in cost expression, not a percentage from someone else's deck.