The AI Agent Platform
An LLM that chats convincingly and an agent that can safely take a real action are not the same thing. This blueprint documents the reusable foundation for the second one: grounded execution, bounded task scope, human escalation, and an audit trail, before any decision gets made about how many agents you actually need.
Chatting Well and Acting Safely Are Different Problems
Most teams build their first AI agent the same way: a system prompt, a general-purpose LLM, and a set of tools it's allowed to call. It works in the demo. Every question gets a fluent, confident answer. The problem shows up later, in production, the first time the agent is confidently wrong about something that matters: a fact it never actually looked up, a booking it made against the wrong record, an amount it approved that it shouldn't have.
The goal of this pattern isn't a better chat interface. It's the architecture underneath any agent that's allowed to take a real action with real consequences: retrieve facts instead of generating them, keep each agent's job narrow enough to reason about, escalate to a person the moment confidence drops, and log everything from the first interaction so the whole system is auditable, not just plausible.
This is deliberately the layer underneath a specific product. An AI receptionist, a loan origination assistant, and a customer support bot are different Industry Solutions built on top of the same foundation. Get this layer right once, and every agent built on top of it inherits the same safety guarantees by default, instead of each product team re-deriving them from scratch.
Anthropic's own engineering guidance draws a hard line between a workflow, where the LLM and tools run through a predefined code path, and an agent, where the LLM dynamically directs its own process and decides what to do next. Their advice is to start with the simplest thing that works, often a plain workflow, and only reach for an agent when the task is genuinely open-ended enough that the number of steps can't be predicted in advance. Everything below assumes that decision has already been made honestly. If a fixed sequence of steps would solve the problem, build that instead: it's cheaper, faster, and doesn't need any of what follows.
In the one industry where this has been studied rigorously, healthcare, simulated studies have found LLMs fabricating diseases, lab values, and clinical signs in up to 83% of cases when no safety measures were in place, and the ECRI Institute named AI chatbot misuse the top health technology hazard for 2026. Healthcare makes the failure mode visible and measurable, but the underlying mechanism, an LLM generating a plausible answer instead of retrieving a verified one, is not healthcare-specific. It shows up anywhere an agent is asked a question it doesn't actually have grounded data for.
The Generalist Agent Gets Worse, Not Better, as Scope Grows
The naive approach is a single agent with one large system prompt, asked to handle every request type a product needs: answer questions, take bookings, process requests, and everything else, all from the same undifferentiated pool of instructions. It works fine in a demo with three example queries. It degrades as real usage arrives, for three structural reasons.
The first reason is accuracy: a model asked to handle everything has no way to signal "I don't actually know this" versus "here's a plausible-sounding guess," because both come out of the same generation process. The second is accountability: when a single agent handles ten different task types and one of them goes wrong, there's no natural boundary for reviewing or fixing just that failure mode without touching the other nine. The third is auditability: without a designed logging layer, there's no reliable record of what the agent actually decided and why, which becomes a real problem the first time a customer, a regulator, or a court asks.
None of this is solved by making the model bigger or the prompt more detailed. It's solved by architecture: deciding what any given agent is allowed to be confident about, and building an explicit path for everything else.
The Trusted Agent Framework: Five Parts, Regardless of How Many Agents You End Up With
Grounded execution, verified action, bounded scope, escalation, audit trail: this is what we call the Trusted Agent Framework internally, and it's the load-bearing part of this whole blueprint. None of the five parts depend on whether the finished system is one agent or several, that's a separate decision, covered below. They also don't depend on the agent being conversational: an agent triggered by an incoming file, a scheduled job, or a change in another system's state needs the same five parts as one triggered by a person typing a message. What matters first is that every agent in the system is built the same way.
Retrieve, don't generate
Confirm before acting
One narrow job each
Know what it doesn't know
Every step, logged
What Actually Executes This: The Loop and the Harness
The five parts below aren't free-floating principles, they get enforced at every step of a specific mechanism: the agent loop. In the dominant pattern, ReAct (Yao et al., 2022), the model produces a thought explaining its reasoning, takes an action by calling a tool, and receives an observation with the result, then reasons again before deciding the next step. This isn't cosmetic: models that reason, act, observe, and reason again measurably outperform ones that just act, a 34% improvement on one benchmark, 10% on another, because each observation corrects the next decision instead of the agent running blind for several steps at once.
The loop doesn't run in open air. It runs inside a harness, the runtime layer that actually wraps the model: it assembles the context for each step, exposes the tool interface, and, critically, is what enforces authorisation and logging rather than trusting the model to enforce them on itself. When "Verified Action Execution" says a tool call needs an idempotency key, or "Bounded Task Scope" says an agent can only call certain tools, those aren't prompt instructions the model might ignore under pressure, they're constraints the harness enforces at the code level, outside the model's control. This is also where the excessive agency mitigation from the section below actually lives: authorisation checked by the harness against the external system, never delegated to the model's own judgement.
-
1Grounded Execution. The agent retrieves facts from an authoritative source before deciding anything, rather than generating them from what the model already knows. A booking availability check reads the live calendar. A policy question retrieves the actual policy document. A balance check reads the ledger. When that authoritative source is itself scattered across several fragmented systems, this step is often where the Federated Data Nexus does the work of unifying them into one queryable view. If the source can't be retrieved, the agent says so, it doesn't fill the gap with a plausible guess.
-
2Verified Action Execution. Retrieving a fact and taking an action are different problems. A tool call that writes to another system, books a slot, moves money, updates a record, can fail halfway, time out, or get retried, and unlike a read, a retry can duplicate the side effect if the call isn't idempotent. Every action-taking tool needs an idempotency key or an equivalent safeguard, a defined behaviour for partial failure, and for anything irreversible, a confirmation step before it executes, not just a log entry after.
-
3Bounded Task Scope. Every agent has an explicit, narrow definition of what it's allowed to be confident about, and an explicit, narrow list of tools it's allowed to call. A scheduling agent handles scheduling, not medical triage. A fraud-screening agent flags anomalies, it doesn't also draft customer replies. Scope isn't a nice-to-have, it's what makes an agent's failures reviewable: a narrow agent can be tested, monitored, and fixed independently of every other agent in the system.
-
4Escalation as the Safety Valve. When confidence drops below a defined threshold, a request falls outside an agent's scope, or a tool call fails in a way the agent isn't authorised to resolve on its own, it hands off to a person (or an alerting system, for agents with no human in the loop by default) with full context attached, rather than guessing or retrying blindly. This is the single most important behavioural guarantee in the whole pattern.
-
5Audit Trail by Design. Every decision, retrieval, tool call, and escalation is logged from the first interaction: what was asked or triggered, what was retrieved, what action was taken and against which system, and why. Built in from day one, this is a cheap logging layer. Retrofitted after an incident, it's a forensic reconstruction project with gaps.
"The system is designed to know what it doesn't know." Everything in the Trusted Agent Framework, the retrieval discipline, the scope boundaries, the harness enforcement, exists to make that one sentence true in production, not just in the pitch.
Choosing a Topology: One Agent, Several, a Pipeline, or a Swarm
"Multi-agent" isn't a single design, and it isn't the default answer either. It's a decision about how to divide bounded task scope across more than one agent, made for a specific reason, not assumed upfront. Four common shapes:
One task, done well
Coordinates specialists
Sequential execution
Peer-to-peer, no supervisor
| Topology | How it works | Fits when |
|---|---|---|
| Single agent | One agent, one well-defined task, a small set of tools it can call | The task genuinely is one thing: answer FAQs, check one type of status |
| Supervisor-routed | A router classifies intent and delegates to one of several specialist agents | Several distinct task types share one entry point, whether that's a chat channel or an inbound event queue |
| Pipeline | Agents run in sequence, each one's output feeding the next | The task is genuinely a sequence of stages, not a choice between parallel options |
| Swarm | Agents communicate peer-to-peer with no central router, coordinating through a shared channel or state | Rarely, for most business tasks: dense peer-to-peer wiring multiplies the coordination surface and works against the Audit Trail and Observability parts of this framework. Real fit is closer to drone or IoT-style coordination without fixed infrastructure than to a loan origination or support agent |
The mistake isn't picking the wrong topology, it's skipping the decision and defaulting to a supervisor-routed design because it's the most commonly written about. If the task is genuinely one thing, a single well-scoped agent is simpler to build, test, and reason about than a router with one specialist behind it. And for the regulated, auditable business tasks this framework is built for, swarm is included here for completeness, not as a live recommendation.
AI Receptionist for HealthTech uses the supervisor-routed shape because the task genuinely is several distinct things behind one patient-facing entry point: scheduling, prescription requests, and symptom triage each need different data sources and different escalation rules. A Supervisor Agent classifies the incoming request and routes it to the matching specialist, each one still built on the same five-part foundation above. See the worked example under "Where This Pattern Applies" below.
Four Things the Core Pattern Doesn't Cover on Its Own
Grounded execution, verified action, bounded scope, escalation, and audit logging make an agent safe to point at a real task. They don't, by themselves, make it perform well over a long conversation, resist manipulation, or stay debuggable once it's non-deterministic. Four separate concerns, each with its own body of practice.
Context engineering decides what the model sees at every step, and it's not optional
Every step of the loop feeds the model a fresh context: the system prompt, the tool definitions, the relevant conversation history, whatever was just retrieved or observed, and anything pulled from long-term memory. Deciding what earns a place in that limited window, at every single step, not once at the start, is its own discipline now, distinct from writing a good prompt. Get it wrong and the failure modes are specific: context poisoning (a bad or manipulated result early in the loop corrupts every reasoning step after it), context overload (too much irrelevant material drowns out the signal), and simple token cost. Memory is the clearest case: stuffing the entire conversation history into every prompt is the naive default, and it measurably underperforms. On the LoCoMo benchmark, a full-context baseline scores 72.9% accuracy at roughly 26,000 tokens per query and 17.12 seconds p95 latency; a proper two-layer memory architecture (working memory for the current task, a separate retrieval layer for everything else) scores 91.6% at roughly 6,956 tokens and 1.44 seconds p95. Better accuracy, a quarter of the tokens, a fraction of the latency, from context engineering alone.
Excessive agency is a named, specific security risk, not a vague one
OWASP's Top 10 for Agentic Applications names this directly: an agent granted delete permissions when read-only would do, full record access when scoped access would do, or the ability to execute without approval when human oversight is critical. The fix isn't a smarter prompt. It's enforcing authorisation in the external system the tool calls, never delegating that decision to the LLM's own judgement, and running every tool call in the requesting user's actual security context rather than one shared high-privilege identity. This connects directly to Bounded Task Scope above: scope isn't just what an agent should focus on, it's the hard technical ceiling on what it's capable of doing even if manipulated into trying.
Prompt injection can arrive through a document, not just a user
OWASP ranks prompt injection as the single highest risk to LLM applications, and for an agent it's more dangerous than for a chatbot: injected instructions don't just produce a bad reply, they can trigger a real tool call. The injection doesn't have to come from the person typing. A retrieved document, an email, or a webpage the agent reads as part of Grounded Execution can carry hidden instructions the model treats as legitimate. Defences remain incomplete industry-wide; the practical mitigation is the same least-privilege enforcement as excessive agency, so that even a successfully hijacked agent is limited in what it can actually do.
Observability is a different job from audit logging
The Audit Trail step above answers "what did the agent do and why," for compliance and incident review. It doesn't answer "why did the agent behave differently on two identical-looking requests," because agent behaviour is genuinely non-deterministic: the same input can produce a different tool sequence or a different answer from temperature sampling, tool latency, or context effects alone. That needs tracing, not logging: capturing the full reasoning chain as replayable spans, then closing the loop by promoting confirmed production failures into an offline evaluation dataset that runs as a regression suite. Without it, every prompt or tool change is a guess about whether it made things better or worse.
Architecture: From Trigger to Verified Action
or staff handoff
with full context attached
The trigger doesn't matter to the pattern, a phone call, a webhook firing, and a scheduled job are treated identically once they enter the agent layer. Event-driven triggers specifically depend on the services underneath being properly decoupled in the first place, the same problem the Event-Driven Platform pattern solves. What matters next is what happens inside the agent layer: it retrieves before it decides anything, a confidence check determines whether the result is trustworthy enough to act on, and everything, the successful path and the escalation path alike, gets logged.
The property this architecture protects above all: the agent never presents a guess as a verified fact. A low-confidence result routes to a person instead of reaching the end user dressed up as certainty. That single rule is what turns a chatbot into something safe to put real decisions behind.
One Pattern, Several Industries
The five-part foundation doesn't change by industry. What changes is what "authoritative source" means, what counts as out of scope, and who the escalation routes to. A few examples:
Patient scheduling, prescriptions, and triage, each retrieval-only
A supervisor-routed build: a Triage agent retrieves against approved clinical protocols rather than generating a clinical opinion, a Booking agent reads live EMR availability, and every interaction escalates to staff below a confidence threshold. See the full worked example: AI Receptionist for HealthTech →
Loan origination and KYC onboarding, grounded against source documents
Document verification, identity checks, and affordability assessment each retrieve from a specific authoritative source (submitted documents, sanctions lists, credit data) rather than inferring an answer, with anything below a confidence threshold routed to a human underwriter, not auto-approved.
Customer support that knows the difference between a known answer and a guess
A single well-scoped agent retrieves from product documentation and account data to answer routine tickets, and hands off to a human the moment a question needs judgement the documentation doesn't cover, rather than improvising a plausible-sounding fix.
Campaign optimisation that recommends within guardrails, not one that spends unsupervised
An agent continuously analyses live campaign performance and proposes budget or targeting changes, bounded to a defined adjustment range, with anything outside that range escalated for human sign-off rather than executed automatically.
A learning assistant that retrieves from the course's own material, not general knowledge
Grounded against the specific curriculum and a student's own progress data rather than the model's general training, with anything resembling a graded assessment or an accessibility accommodation decision routed to an instructor instead of answered automatically.
Contract review that flags clauses against a firm's own playbook, not a legal opinion
The agent retrieves against the firm's approved clause library and precedent documents to flag deviations, and every flag is scoped to "this differs from the standard" rather than "this is acceptable," with the actual legal judgement always escalated to a qualified reviewer.
The five parts of the Trusted Agent Framework (grounded execution, verified action, bounded scope, escalation, audit trail) stay the same regardless of industry. What changes is the authoritative source each agent retrieves from, the specific scope boundaries, and who sits at the other end of an escalation.
Where Production Agent Builds Actually Fail
Most of these map directly to a part of the framework being skipped, not a new failure mode. Listed here as a single checklist because in practice teams find it faster to audit an existing build against a list than to re-read the whole pattern.
Building one giant autonomous agent. Gets less reliable as scope grows, not more, see The Generalist Agent Gets Worse above.
Giving agents unrestricted permissions. Named directly by OWASP as Excessive Agency, delete access when read-only would do.
No human approval workflow. Escalation isn't a fallback feature, it's the framework's single most important guarantee.
Using prompts instead of authorisation. "Please don't delete records you shouldn't" is not a security boundary. The harness enforces it, not the prompt.
No observability. Audit logging answers what happened. Without tracing, nobody can answer why identical requests behaved differently.
No evaluation strategy. Every prompt or tool change becomes a guess about whether it helped, see Agent Evaluation below.
No rollback capability. A new prompt version or tool schema goes to production with no way to revert it independently of a full deploy, so a regression stays live until the next release.
Overusing LLM reasoning. Routing a deterministic task through the model anyway, see "Does the task even need an agent?" above.
Framework, or Build the Harness Directly?
A framework doesn't replace the Trusted Agent Framework above, it's one way to implement the harness underneath it. Several established options exist, each with a real trade-off, not a universally correct answer.
| Option | Strength | Fits when |
|---|---|---|
| LangGraph | Explicit graph-based control flow: you define exactly how control moves between steps and where errors route. The most production-battle-tested of the group. | The workflow is genuinely stateful and complex, and you want fine-grained control over routing and error handling rather than a framework making those decisions for you. |
| CrewAI | Fastest path to a working multi-agent prototype, built around role-based collaboration between agents. | You're validating whether a supervisor-routed or pipeline shape is even the right topology, before committing to a production build. |
| OpenAI Agents SDK | Fastest path from zero to a working agent with handoff patterns and guardrails built in, if you're committed to OpenAI models. | The product is already OpenAI-native and staying that way is an acceptable trade-off for build speed. |
| Semantic Kernel | Lightweight, strong .NET integration, built for enterprise environments already running on Microsoft infrastructure. | The team and the surrounding stack are already Azure-centric, and that alignment outweighs the ecosystem size of the alternatives. |
| Custom orchestration | No framework opinions to work around, or against. | The loop is genuinely simple (one agent, a small fixed tool set) and a framework's abstractions would add more overhead than the problem justifies, consistent with the "start simple" principle in Section 01. |
Whichever option is chosen, it needs to satisfy the harness's four necessary elements from Section 03: an agent loop, a tool interface, context management, and control mechanisms for authorisation and logging. A framework that's fast to prototype in but can't cleanly enforce the Excessive Agency mitigation, authorisation checked externally, never delegated to the model, isn't a shortcut, it's a gap the team will have to fill in by hand anyway.
Measuring a System That Doesn't Give the Same Answer Twice
This is the practical half of the Observability concern from Section 03: tracing tells you what happened in one run, evaluation tells you whether the system is getting better or worse over time. Without a small set of tracked metrics, every prompt or tool change is a guess.
| Metric | What it catches |
|---|---|
| Task completion rate | Whether the agent actually finishes what it was asked, versus stalling, looping, or escalating unnecessarily |
| Hallucination rate | How often a response asserts something that wasn't actually retrieved, the direct measure of whether Grounded Execution is holding |
| Tool success rate | How often a tool call succeeds cleanly versus failing, timing out, or needing a retry, the operational health of Verified Action Execution |
| Human escalation rate | Trending up can mean the agent is being appropriately cautious, or that scope or grounding has quietly broken, worth investigating either way |
| Average latency | Per step and end to end; a loop that reasons too many times before acting is a context engineering problem, not just a speed one |
| Cost per successful task | Not cost per request, cost per outcome actually delivered, since retries and escalations both consume tokens without producing a result |
| Retry frequency | A leading indicator of tool reliability or prompt drift, usually visible before task completion rate drops |
| User satisfaction | The only metric on this list that isn't purely internal, and the one that ultimately validates whether the others are being tracked correctly |
In practice: production traces surface failing cases, a human reviews and confirms which ones are real failures, and confirmed failures get promoted into an offline evaluation dataset that runs as a regression suite against every future change. That loop, not any single metric on its own, is what makes iteration on a non-deterministic system safe.
Running This Costs More Than Building It
Architecting the system well is Sections 03 and 04. Keeping it running well is a separate, ongoing job, and the cost profile is different from typical software because every loop iteration is a network call to a model, not a function call.
Cost compounds with loop depth, not just request volume
Every think-act-observe cycle is another model call, another set of tool calls, another slice of context to assemble. A task that takes four loop iterations instead of two roughly doubles its cost and latency, independent of how many users are hitting the system. Context engineering (Section 03) is a direct cost lever, not just an accuracy one.
Memory and audit data grow indefinitely unless something prunes them
Session state, long-term memory, and the audit log all accumulate. Retrieval quality degrades as the store grows unless there's an explicit archival or summarisation strategy, and the audit log specifically needs a retention policy decided upfront, not discovered when storage costs show up on a bill.
Caching trades cost for staleness, deliberately, not by accident
Caching retrieval results or tool responses cuts both cost and latency, but it directly works against Grounded Execution's premise that the agent reads live data. Every cache needs an explicit invalidation rule tied to how quickly the underlying source actually changes, not a blanket time-to-live picked for convenience.
Operational complexity scales with agents and tools, not with users
Ten specialist agents each calling several tools is ten times the surface area to monitor, version, and debug compared to one, regardless of traffic. This is the practical cost of the topology decision in Section 03: a supervisor-routed design with five specialists carries five times the operational surface of a single well-scoped agent, and that cost is worth paying only when the task genuinely needs it.
Is the AI Agent Platform the right architecture?
This pattern fits when
A wrong answer has a real consequence: money, health, legal exposure, or a customer relationship
There's a verifiable source of truth the agent can retrieve against, not just a general knowledge question
Request volume justifies the engineering investment over handling everything manually
There's a real team that can own reviewing escalations and maintaining the guardrails, not just launching the agent
This pattern does not fit when
A fixed, predictable sequence of steps would solve it: build that workflow instead, it's cheaper and doesn't need any of this pattern's safety machinery
The task is genuinely creative or subjective, with no ground truth to retrieve against and check confidence on
Volume is too low to justify building and maintaining retrieval, escalation, and logging layers
The business requires zero errors even with a human escalation backstop, some tasks need full pre-verification, not verify-then-escalate
No authoritative source exists yet to retrieve against, build that first, this pattern grounds an agent, it doesn't create the ground
Not sure what an AI agent would actually cost to build for your product? Run the AI Agent Estimator →
This pattern draws on TechTek's AI & Automation and Software Development capabilities. Want it scoped against your actual use case? Book an architecture review →