Quick Navigation
- Start here — The evolution of automation
- What agentic systems are
- Architecture patterns for agents
- MCP and A2A protocols
- Human-in-the-loop design
- Governance and risk
- Where to start
- Orchestration tools and frameworks
- Guardrails and evaluation
- Observability
- Economic guardrails
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
Automation has moved beyond scripts and rules. AI agents can plan, decide, and use tools autonomously — shifting the architecture challenge from integrating APIs to orchestrating reasoning-based workflows that operate across systems. I've seen organisations treat agents like scripts — brittle, unmonitored, and dangerous. They're not. They're fundamentally different.
Agents plan, act, and use tools — the architecture challenge shifts from integration to orchestration.
Agentic systems require new architectural patterns — orchestration, memory, tool use, human oversight. MCP (Model Context Protocol) and A2A (Agent-to-Agent) are the emerging standards for agent integration. Human oversight must be designed in, not assumed. The shift from static integrations to agentic workflows is a fundamental architectural change.
Keep it in mind.
1. The evolution of automation — From scripts to rules to AI agents
Most organisations treat automation as "write a script, run a job." But automation has evolved through four distinct stages — each requiring fundamentally different architecture. Treating agents like scripts leads to brittle, unmonitored, and dangerous systems.
Each stage of automation evolution demands new architectural capabilities:
flowchart LR
SCRIPTS["📜 Scripts\nExecute predefined steps\nSequential, imperative"] --> RULES["⚙️ Rules\nDecide based on conditions\nIf-then, rules engine"]
RULES --> WORKFLOWS["🔀 Workflows\nOrchestrate multi-step\nBPM, state machines"]
WORKFLOWS --> AGENTS["🤖 Agents\nPlan, decide, act\nOrchestration, memory, tools"]
SCRIPTS --> ARCH_S["Architecture:\nSequential logic"]
RULES --> ARCH_R["Architecture:\nDecision trees"]
WORKFLOWS --> ARCH_W["Architecture:\nState machines"]
AGENTS --> ARCH_A["Architecture:\nPlanning + memory\n+ tool use + oversight"]
The critical shift — from workflows to agents:
| Stage | Decides the steps? | Architecture pattern |
|---|---|---|
| Scripts | Developer (hardcoded) | Sequential, imperative |
| Rules | Rules engine (conditional) | Rules engine, if-then |
| Workflows | Workflow designer (predefined) | BPM, state machines |
| Agents | The agent (dynamic) | Orchestration, memory, tool use |
The shift from workflows to agents is the shift from "do these steps" to "achieve this goal." The agent decides the steps — and that changes everything about how you architect, monitor, and govern the system.
Each stage builds on the previous: scripts → rules → workflows → agents. Don't jump from scripts to agents without building intermediate capabilities.
Scripts → Rules → Workflows → Agents — each stage requires new architecture, not just new code.
Try it yourself — The maturity check
Where does your organisation's automation sit on the maturity model?
| Automation | Current stage | Architecture pattern |
|---|---|---|
If you're treating agents like scripts, you're building on the wrong foundation.
2. What agentic systems are — Planning, tool use, memory, and orchestration
"AI agent" is used loosely — sometimes for a chatbot, sometimes for a rules engine, sometimes for a simple API wrapper. Without a clear definition, organisations build things they call agents that lack the core capabilities agents actually need.
An AI agent has four capabilities that distinguish it from simpler automation:
flowchart TD
AGENT["🤖 AI Agent"] --> PLAN["📋 Planning\nBreaks goal into steps\nDecides what to do next"]
AGENT --> TOOLS["🔧 Tool Use\nInvokes APIs, DBs, code\nActs on the world"]
AGENT --> MEMORY["🧠 Memory\nRetains context across steps\nShort-term + long-term"]
AGENT --> ORCH["🔀 Orchestration\nCoordinates steps\nHandles errors and loops"]
PLAN --> RESULT["✅ Autonomous Goal Achievement\nAgent receives a goal\nPlans, acts, observes, adjusts"]
TOOLS --> RESULT
MEMORY --> RESULT
ORCH --> RESULT
The agent capability table:
| Capability | What it does | Architecture implication |
|---|---|---|
| Planning | Breaks a goal into steps | Planner component; plan storage |
| Tool use | Invokes external tools (APIs, databases, code) | Tool registry; tool calling protocol |
| Memory | Retains context across steps | Short-term (conversation) + long-term (knowledge) |
| Orchestration | Coordinates steps, handles errors, loops | Orchestrator; state management |
The agent test — is it really an agent?
| Question | If yes | If no |
|---|---|---|
| Does it decide its own steps? | Agent | Scripted automation |
| Does it use external tools to act? | Agent | Chatbot |
| Does it retain context across steps? | Agent | Stateless function |
| Does it adjust its plan based on results? | Agent | Predefined workflow |
Agent architecture components: Planner — breaks goals into executable steps. LLM-based planning, task decomposition. Tool registry — defines available tools and their contracts. MCP servers, function definitions. Executor — calls tools and observes results. Tool calling API, error handling. Memory (short-term) — retains conversation context. Context window, session state. Memory (long-term) — retains knowledge across sessions. Vector store, knowledge base. Orchestrator — manages state, retries, loops. State machine, LangGraph. Guardrails — safety, cost, compliance constraints. Output filters, budget limits. Human-in-the-loop — approval checkpoints. Interrupt/resume patterns.
Planning + Tool use + Memory + Orchestration = an agent — design for all four, or it's not an agent.
Try it yourself — The agent test
Take something you're calling an "agent." Run it through the test:
| Question | Your answer |
|---|---|
| Does it decide its own steps? | |
| Does it use external tools to act? | |
| Does it retain context across steps? | |
| Does it adjust its plan based on results? |
If you answered "no" to two or more, it's not an agent. It's automation. That's fine — just don't call it an agent.
3. Architecture patterns for agents — Single agent, multi-agent, and orchestrated workflows
Not all agentic workloads need the same architecture. Using a multi-agent system for a simple task adds unnecessary complexity. Using a single agent for a complex, multi-domain task leads to hallucination and failure.
Three architectural patterns for agentic systems — each suited to different complexity levels:
flowchart TD
PATTERNS["🏗️ Agent Patterns"] --> SINGLE["🔵 Single Agent\nOne agent handles entire workflow\nSimple, but limited"]
PATTERNS --> MULTI["🟢 Multi-Agent\nMultiple specialised agents\nCoordinator routes tasks"]
PATTERNS --> ORCH["🟠 Orchestrated Workflow\nHuman-designed workflow\nAgents called at specific steps"]
SINGLE --> USE_S["Best for:\nSimple, well-defined tasks\nHigh control needed"]
MULTI --> USE_M["Best for:\nComplex tasks\nDiverse skills needed"]
ORCH --> USE_O["Best for:\nRegulated processes\nAuditability required"]
Pattern comparison:
| Pattern | Complexity | Control | Best for |
|---|---|---|---|
| Single agent | Low | High | Simple, well-defined tasks |
| Multi-agent | Medium | Medium | Complex tasks requiring diverse skills |
| Orchestrated workflow | Medium | High | Regulated, auditable processes |
Pattern selection decision:
| Question | If yes → | If no → |
|---|---|---|
| Is the task simple and well-defined? | Single agent | Consider multi-agent |
| Do you need diverse domain expertise? | Multi-agent | Single agent or orchestrated |
| Is regulatory compliance required? | Orchestrated workflow | Multi-agent or single agent |
| Do you need full auditability? | Orchestrated workflow | Multi-agent |
Single agent architecture: Goal → Agent → [Plan → Execute → Observe] loop → Result. Tool calls via MCP. Memory (short + long term). Guardrails.
Multi-agent architecture: Goal → Coordinator Agent → Routes to specialist agents (Agent A, Agent B, Agent C). Each agent has own tools, memory, guardrails. Agents communicate via A2A protocol.
Orchestrated workflow architecture: Workflow Engine → Step 1 → Agent A (with human approval) → Step 2 → Agent B (auto-execute) → Step 3 → Human review → Step 4 → Agent C (auto-execute). Workflow is predefined; agents are components.
Start with orchestrated workflows for control; move to multi-agent for complexity — don't start with the most complex pattern.
Try it yourself — The pattern selection
For your agentic use case:
| Question | Your answer | Pattern it points to |
|---|---|---|
| Is the task simple and well-defined? | ||
| Do you need diverse domain expertise? | ||
| Is regulatory compliance required? | ||
| Do you need full auditability? |
If your answers point in different directions, start with orchestrated workflow and evolve.
4. MCP and A2A — The protocols reshaping how systems connect
Without standardised protocols, every agent integration is bespoke — custom API wrappers, custom tool definitions, custom inter-agent communication. This creates integration debt that compounds as agent adoption grows.
Two emerging protocols standardise agent integration:
flowchart TD
PROTOCOLS["🔌 Agent Protocols"] --> MCP["🔧 MCP\nModel Context Protocol\nAgent ↔ Tool communication"]
PROTOCOLS --> A2A["🤝 A2A\nAgent-to-Agent Protocol\nAgent ↔ Agent communication"]
MCP --> DISCOVER_T["Tools: discoverable\nAgents find tools dynamically\nNo custom integration"]
A2A --> DISCOVER_A["Agents: discoverable\nAgents find peers dynamically\nNo hardcoded routing"]
DISCOVER_T --> RESULT["✅ Reduced Integration Complexity\nStandardised discovery\nDynamic capability composition"]
DISCOVER_A --> RESULT
Protocol comparison:
| Protocol | What it standardises | Direction | Example |
|---|---|---|---|
| MCP | Agent-to-tool communication | Agent → Tool | Agent calls an API via MCP |
| A2A | Agent-to-agent communication | Agent → Agent | Agent delegates a sub-task to a peer |
Why these matter for architects: MCP standardises how agents integrate with your systems — you expose tools via MCP, not custom APIs. A2A standardises how agents collaborate — you design agent boundaries, not just service boundaries. Both protocols reduce integration complexity — agents discover capabilities dynamically instead of hardcoded wiring.
MCP architecture: Agent (MCP Client) → MCP Server (exposes tools) → Tool 1: Database query, Tool 2: API call, Tool 3: File operation. MCP defines: discovery, invocation, result format.
A2A architecture: Agent A (Coordinator) → Discovers Agent B via A2A registry → Sends task to Agent B → Agent B executes and returns result. A2A defines: discovery, task delegation, result format.
MCP = how agents call tools. A2A = how agents call each other. Design your systems to be agent-accessible.
Try it yourself — The protocol check
Which of your systems are agent-accessible?
| System | Exposed via MCP? | Exposed via A2A? | Gap |
|---|---|---|---|
If the answer to both columns is "no," your systems aren't ready for agents.
5. Human-in-the-loop design — Building oversight into agentic architectures
Agents without human oversight are an architectural risk. If an agent can plan and act autonomously, it can also plan and act incorrectly — at scale, at speed, without anyone noticing until damage is done.
Human-in-the-loop design builds approval checkpoints into agentic workflows:
flowchart TD
HITL["👁️ Human-in-the-Loop"] --> PRE["✅ Approval Before Action\nHigh-risk actions require\nhuman approval first"]
HITL --> POST["📋 Review After Action\nMedium-risk actions are\nreviewed after execution"]
HITL --> ESC["🚨 Escalation on Failure\nAgent uncertain →\nescalate to human"]
HITL --> AUDIT["🔍 Periodic Audit\nContinuous oversight\nReview agent decisions"]
PRE --> RISK_H["High Risk\nFinancial transactions\nData deletion\nExternal communications"]
POST --> RISK_M["Medium Risk\nData updates\nInternal changes\nRoutine operations"]
ESC --> RISK_U["Uncertainty\nAmbiguous situations\nConflicting data"]
AUDIT --> RISK_C["Continuous\nPattern detection\nBias monitoring"]
Checkpoint design matrix:
| Checkpoint type | When to use | Risk level | Implementation |
|----------------|-------------|------------|----------------|
| **Approval before action** | High-risk actions | High | Interrupt, wait for approval, resume |
| **Review after action** | Medium-risk actions | Medium | Execute, log, notify for review |
| **Escalation on failure** | When agent is uncertain | Variable | Detect uncertainty, route to human |
| **Periodic audit** | Continuous oversight | Low | Sample decisions, review patterns |
Design principles: High-risk actions require human approval before execution. Medium-risk actions are reviewed after execution. All actions are logged for audit. Escalation paths exist when agents are uncertain. The human is the architect of oversight — not an afterthought.
HITL implementation patterns: **Interrupt-resume** — agent pauses, waits for human input, resumes. LangGraph interrupt nodes. **Approval gate** — agent proposes action, human approves or rejects. Custom approval workflow. **Confidence threshold** — agent self-reports confidence; low confidence → escalate. Agent confidence scoring. **Delegation chain** — agent → junior human → senior human (escalation). Workflow orchestration.
**Design human oversight into the architecture — approval checkpoints, escalation paths, and kill switches are architectural components, not afterthoughts.**
---
### Try it yourself — The oversight check
For your agentic use case:
| Action | Risk level | Checkpoint type |
|---|---|---|
| | | |
| | | |
If you haven't classified actions by risk, you don't have oversight. You have hope.
---
<a id="governance"></a>
## 6. Governance and risk — What can go wrong and how to design against it
Agentic systems introduce new risks that traditional architecture doesn't address. Agents can hallucinate, misuse tools, enter infinite loops, leak data, exceed budgets, and gradually expand their autonomy beyond intended scope.
A comprehensive risk taxonomy with corresponding mitigations:
```mermaid
flowchart TD
RISKS["🛡️ Agentic Risks"] --> HALL["🎭 Hallucination\nAgent produces\nincorrect information"]
RISKS --> MISUSE["⚠️ Tool Misuse\nAgent calls tools\nin unexpected ways"]
RISKS --> LOOP["🔄 Infinite Loops\nAgent stuck in\nreasoning loops"]
RISKS --> LEAK["🔓 Data Leakage\nAgent exposes\nsensitive data"]
RISKS --> RUNAWAY["💸 Economic Runaway\nAgent consumes\nexcessive budget"]
RISKS --> CREEP["📏 Autonomy Creep\nAgent exceeds\nintended scope"]
HALL --> MIT_H["Mitigate: RAG grounding\nOutput validation"]
MISUSE --> MIT_T["Mitigate: Tool contracts\nRate limiting"]
LOOP --> MIT_L["Mitigate: Step limits\nTimeout + kill switch"]
LEAK --> MIT_D["Mitigate: Access control\nOutput filtering"]
RUNAWAY --> MIT_E["Mitigate: Cost ceilings\nBudget alerts"]
CREEP --> MIT_A["Mitigate: Scope constraints\nHuman oversight"]
style RISKS stroke:#8e44ad
style HALL stroke:#c0392b
style MISUSE stroke:#c0392b
style LOOP stroke:#c0392b
style LEAK stroke:#c0392b
style RUNAWAY stroke:#c0392b
style CREEP stroke:#c0392b
Risk and mitigation matrix:
| Risk | What it means | Mitigation |
|---|---|---|
| Hallucination | Agent produces incorrect information | Grounding (RAG), output validation |
| Tool misuse | Agent calls tools in unexpected ways | Tool contracts, rate limiting |
| Infinite loops | Agent stuck in reasoning loops | Step limits, timeout, kill switch |
| Data leakage | Agent exposes sensitive data | Access control, output filtering |
| Economic runaway | Agent consumes excessive inference budget | Cost ceilings, budget alerts |
| Autonomy creep | Agent takes actions beyond its mandate | Scope constraints, human oversight |
Governance framework — five pillars: Scope — define what the agent can and cannot do. Contracts — define what tools the agent can call and with what constraints. Escalation — define when the agent must ask for human help. Kill switches — define how to stop the agent immediately. Audit — define how agent decisions are logged and reviewed.
Agent governance = scope + contracts + escalation + kill switches + audit — design all five before production.
Try it yourself — The governance check
Which of the five governance pillars are implemented for your agents?
| Pillar | Implemented? | Gap |
|---|---|---|
| Scope | ||
| Contracts | ||
| Escalation | ||
| Kill switches | ||
| Audit |
If any pillar is missing, your agent isn't governed. It's autonomous.
7. Where to start — Identifying automation opportunities and sequencing the shift
Knowing that agentic systems are possible isn't the same as knowing where to begin. Teams either try to automate everything at once (and fail) or wait for a perfect strategy (and never start).
The shift to agentic systems is a journey, not a jump. Start with low-risk, high-value opportunities. Learn. Then expand.
A practical starting framework: Map the automation opportunity landscape — which processes are repetitive, rule-based, and high-volume? Assess agent readiness — does the process have clear inputs, outputs, and success criteria? Classify by risk and value — high-value/low-risk first; high-risk last. Sequence the shift — scripts → rules → agents; start simple, add autonomy incrementally. Measure and learn — track outcomes, not just deployment; adjust based on evidence.
flowchart TD
MAP["🗺️ Map Opportunity\nIdentify repetitive,\nrule-based processes"] --> ASSESS["📊 Assess Readiness\nClear inputs/outputs?\nMeasurable success criteria?"]
ASSESS --> CLASSIFY["🏷️ Classify\nHigh value / Low risk\n= Start here"]
CLASSIFY --> SEQUENCE["📅 Sequence\nScripts → Rules → Agents\nIncremental autonomy"]
SEQUENCE --> MEASURE["📏 Measure\nTrack outcomes\nLearn and adjust"]
Opportunity classification matrix:
| Opportunity | Value | Risk | Complexity | Start here? |
|---|---|---|---|---|
| Report generation | Medium | Low | Low | ✅ First |
| Customer email triage | High | Low | Medium | ✅ First |
| Code review suggestions | High | Medium | Medium | Second wave |
| Incident response | High | High | High | Later |
| Strategic planning | Very high | Very high | Very high | Last |
Sequencing strategy: Phase 1: Observe — agents watch and suggest (human decides). Phase 2: Assist — agents draft, human approves. Phase 3: Automate — agents act, human monitors. Phase 4: Autonomise — agents act, human intervenes only on exceptions.
Key readiness criteria: Clear inputs and outputs — the agent knows what to do and what "done" looks like. Measurable success criteria — you can tell if the agent did a good job. Low cost of failure — mistakes are recoverable, not catastrophic. Available data — the agent has access to what it needs. Human oversight possible — someone can monitor and intervene.
Don't start with the most complex use case. Start with the one that teaches you the most with the least risk.
Try it yourself — The opportunity map
List three automation opportunities in your organisation:
| Opportunity | Value | Risk | Complexity | Phase to start |
|---|---|---|---|---|
Start with the highest value, lowest risk, lowest complexity.
8. Orchestration tools and frameworks — LangGraph, CrewAI, and how to choose
The agent framework landscape is fragmented — LangGraph, CrewAI, AutoGen, Semantic Kernel, Haystack, and many more. Choosing the wrong framework leads to architectural lock-in, missing capabilities, or unnecessary complexity.
Frameworks differ in their strengths — choose based on your architectural needs, not popularity:
flowchart TD
CHOOSE["🧰 Framework Selection"] --> STATE["📊 State Management\nDoes the agent need\nto remember across steps?"]
CHOOSE --> TOOLS_F["🔧 Tool Integration\nHow many tools\ndoes the agent need?"]
CHOOSE --> MULTI_F["👥 Multi-Agent\nDo agents need\nto collaborate?"]
CHOOSE --> OBS_F["🔭 Observability\nCan you trace\nwhat the agent did?"]
STATE --> LG["LangGraph\nStateful graphs\nBest for complex workflows"]
TOOLS_F --> LG
MULTI_F --> CREW["CrewAI\nMulti-agent teams\nBest for specialised agents"]
MULTI_F --> AG["AutoGen\nAgent conversations\nBest for dialogue"]
OBS_F --> LG
Framework comparison:
| Framework | What it does | Best for |
|---|---|---|
| LangGraph | Stateful agent orchestration with graphs | Complex workflows, stateful agents |
| CrewAI | Multi-agent collaboration | Teams of specialised agents |
| AutoGen | Multi-agent conversation | Agent-to-agent dialogue |
| Semantic Kernel | Microsoft agent framework | .NET ecosystems |
| Haystack | Pipeline-based AI orchestration | Search and RAG pipelines |
Selection criteria:
| Criterion | Question | Favour |
|---|---|---|
| State management | Does the agent need to remember across steps? | LangGraph |
| Tool integration | How many tools does the agent need? | LangGraph, Haystack |
| Multi-agent | Do agents need to collaborate? | CrewAI, AutoGen |
| Observability | Can you trace what the agent did? | LangGraph |
| Ecosystem | What is your tech stack? | Semantic Kernel (.NET), LangGraph (Python) |
Choose orchestration by state management needs, tool integration, and observability — not by hype.
Try it yourself — The framework check
For your agentic use case:
| Criterion | Your need | Framework it favours |
|---|---|---|
| State management | ||
| Tool integration | ||
| Multi-agent | ||
| Observability | ||
| Ecosystem |
If you're choosing based on popularity rather than needs, you're making a mistake.
9. Guardrails and agent evaluation — How to test, constrain, and monitor agent behaviour
Agents in production need constraints — not just safety constraints, but scope, cost, compliance, and quality constraints. Without guardrails, agents can produce harmful outputs, exceed budgets, violate regulations, or degrade in quality without detection.
Guardrails constrain agent behaviour; evaluation tests it before deployment:
flowchart TD
GUARD["🧪 Guardrails & Evaluation"] --> CONSTRAIN["🔒 Guardrails\nConstrain agent behaviour\nin production"]
GUARD --> EVAL["📊 Evaluation\nTest agent behaviour\nbefore deployment"]
CONSTRAIN --> SAFETY["Safety\nPrevent harmful outputs\nOutput filters"]
CONSTRAIN --> SCOPE["Scope\nPrevent out-of-scope actions\nTool allowlists"]
CONSTRAIN --> COST_G["Cost\nPrevent excessive spending\nBudget ceilings"]
CONSTRAIN --> COMPLY["Compliance\nRegulatory adherence\nOutput validation"]
EVAL --> TASK["Task completion\nDoes agent achieve goal?"]
EVAL --> ACC["Accuracy\nAre outputs correct?"]
EVAL --> ROBUST["Robustness\nDoes agent handle errors?"]
EVAL --> COST_E["Cost\nHow much per task?"]
Guardrail types:
| Guardrail type | What it constrains | Implementation |
|---|---|---|
| Safety | Prevents harmful outputs | Output filters, content classifiers |
| Scope | Prevents out-of-scope actions | Tool allowlists, action constraints |
| Cost | Prevents excessive spending | Budget ceilings, per-request limits |
| Compliance | Ensures regulatory adherence | Output validation, audit logging |
| Quality | Ensures output quality | Evaluation pipelines, human review |
Evaluation types:
| Evaluation type | What it tests | When to run |
|---|---|---|
| Task completion | Does the agent achieve the goal? | Pre-deployment + continuous |
| Accuracy | Are the outputs correct? | Pre-deployment + continuous |
| Safety | Does the agent produce harmful outputs? | Pre-deployment |
| Tool use | Does the agent call tools correctly? | Pre-deployment |
| Robustness | Does the agent handle errors gracefully? | Pre-deployment |
| Cost | How much does each task cost? | Pre-deployment + continuous |
Guardrails constrain in production; evaluation tests before deployment — both are required, neither is optional.
Try it yourself — The guardrail check
Which guardrails are implemented for your agents?
| Guardrail type | Implemented? | Gap |
|---|---|---|
| Safety | ||
| Scope | ||
| Cost | ||
| Compliance | ||
| Quality |
If any guardrail is missing, your agent isn't production-ready.
10. Observability for agentic systems — Tracing reasoning chains, tool calls, and failure modes
Traditional observability (logs, metrics, traces) is designed for request-response systems. Agentic systems produce reasoning chains, tool calls, token consumption, and multi-step decisions — none of which traditional observability captures.
Agent observability requires new signals beyond traditional APM:
flowchart TD
OBS["🔭 Agent Observability"] --> REASON["🧠 Reasoning Chain\nWhat steps did the agent\nplan and why?"]
OBS --> TOOLS_O["🔧 Tool Calls\nWhat tools were called\nwith what inputs/results?"]
OBS --> TOKENS["🪙 Token Usage\nHow many tokens consumed\nper step and total?"]
OBS --> DECISIONS["🔀 Decisions\nWhat did the agent decide\nat each branching point?"]
OBS --> ERRORS_O["❌ Errors\nWhat failed and why?\nRetries? Escalations?"]
OBS --> COST_TR["💰 Cost Tracking\nInference cost\nper task and trend"]
REASON --> DASH["📊 Dashboard\nAgent health · Cost trends\nError rates · Token usage"]
TOOLS_O --> DASH
TOKENS --> DASH
DECISIONS --> DASH
ERRORS_O --> DASH
COST_TR --> DASH
What to observe in agentic systems:
| What to observe | Why it matters | Implementation |
|---|---|---|
| Reasoning chain | Understand agent decision process | Chain-of-thought logging |
| Tool calls | Audit what the agent did to the world | Tool call traces with I/O |
| Token usage | Cost management and optimisation | Per-step token metering |
| Latency | Performance and user experience | Step-level timing |
| Errors | Failure detection and debugging | Error classification and tracing |
| Decisions | Audit trail for governance | Decision point logging |
Observability architecture for agents: Trace capture — record reasoning chain, tool calls, decisions. LangSmith, Langfuse, custom tracing. Token metering — track per-step and total token consumption. Model provider APIs, custom metering. Error tracking — classify and trace failures, retries, escalations. Sentry, custom error tracking. Cost tracking — calculate inference cost per task. Token × price model, budget dashboards. Dashboard — agent health, cost trends, error rates. Grafana, custom dashboards. Alerting — anomaly detection, budget alerts. Alert manager, webhook notifications.
Observe reasoning, not just requests — agent observability is fundamentally different from service observability.
Try it yourself — The observability check
What can you observe about your agents right now?
| Signal | Observable? | How |
|---|---|---|
| Reasoning chain | ||
| Tool calls | ||
| Token usage | ||
| Cost per task | ||
| Error rates |
If you can't answer the first two, you're flying blind.
11. Economic guardrails and inference budgets — Designing financial kill switches
Agents caught in expensive reasoning loops, using wrong models for simple tasks, or making redundant tool calls can consume inference budgets at alarming speed. Without economic guardrails, an agent can spend thousands of pounds per hour without anyone noticing until the bill arrives.
Economic guardrails must be designed into the architecture from the start — not added after the first budget overrun:
flowchart TD
ECON["💰 Economic Guardrails"] --> PER_TASK["🎯 Per-Task Budget\nMaximum cost\nper agent task"]
ECON --> PER_HOUR["⏰ Per-Hour Budget\nMaximum cost\nper hour"]
ECON --> KILL["🛑 Kill Switch\nStop agent when\nbudget exceeded"]
ECON --> ROUTE["🔀 Model Routing\nCheaper models\nfor simple tasks"]
ECON --> CACHE["📦 Caching\nCache repeated\nreasoning patterns"]
PER_TASK --> SCENARIOS["Runaway Scenarios"]
PER_HOUR --> SCENARIOS
KILL --> SCENARIOS
SCENARIOS --> LOOP["Infinite loop: £1,000+/hr\n→ Step limits + timeout"]
SCENARIOS --> WRONG["Wrong model: 10x cost\n→ Model routing"]
SCENARIOS --> REPEAT["Redundant calls: waste\n→ Caching + deduplication"]
SCENARIOS --> UNBOUND["No ceiling: unbounded\n→ Hard budget limits"]
Economic guardrail types:
| Guardrail | What it does | Implementation |
|---|---|---|
| Per-task budget | Maximum cost per agent task | Token limit + cost calculation |
| Per-hour budget | Maximum cost per hour | Rate limiting on inference |
| Kill switch | Stop agent when budget exceeded | Automatic shutdown |
| Model routing | Use cheaper models for simple tasks | Task complexity classifier |
| Caching | Cache repeated reasoning patterns | Semantic cache for common queries |
Runaway scenario risk model:
| Scenario | Potential cost | Mitigation |
|---|---|---|
| Infinite reasoning loop | £1,000+/hour | Step limits + timeout |
| Wrong model selection | 10x cost for simple task | Model routing |
| Redundant tool calls | Repeated API waste | Caching + deduplication |
| No budget ceiling | Unbounded spending | Hard budget limits |
Economic guardrails are as important as safety guardrails — agents can spend money as fast as they can reason.
Try it yourself — The economic check
What economic guardrails are in place for your agents?
| Guardrail | Implemented? | Gap |
|---|---|---|
| Per-task budget | ||
| Per-hour budget | ||
| Kill switch | ||
| Model routing | ||
| Caching |
If you don't have a kill switch, you don't have economic guardrails. You have a budget waiting to be blown.
Putting it all together
Here's the complete picture in one diagram. This is the mental model worth internalising.
flowchart TD
PROBLEM["🔄 Automation Evolution\nScripts → Rules → Workflows → Agents"] --> AGENT["🤖 Agentic Architecture\nPlanning + Tools + Memory + Orchestration"]
AGENT --> PROTOCOLS["🔌 Protocols\nMCP for tools\nA2A for agents"]
AGENT --> OVERSIGHT["👁️ Human Oversight\nApproval checkpoints\nEscalation paths"]
AGENT --> GOVERN["🛡️ Governance\nScope + Contracts\nKill switches + Audit"]
PROTOCOLS --> RESULT["✅ Controlled Autonomy\nAgents that plan and act\nwith guardrails, observability,\nand economic controls"]
OVERSIGHT --> RESULT
GOVERN --> RESULT
The foundation:
Agents plan, act, and use tools — the architecture challenge shifts from integration to orchestration. Design for agents the way you design for services — with contracts, boundaries, and observability. Human oversight must be designed in, not assumed. Approval checkpoints, escalation paths, and kill switches are architectural components, not afterthoughts. Economic guardrails are as important as safety guardrails. Agents caught in expensive reasoning loops are a financial risk. Design cost ceilings and kill switches from the start. Design for controlled autonomy — agents that plan and act with guardrails, observability, and economic controls built into the architecture.
Cheat Sheet — All the key terms
| Concept | One-Line Memory | Key Action |
|---|---|---|
| Automation evolution | Scripts → Rules → Workflows → Agents | Match architecture to maturity stage |
| Agentic systems | Plans, acts, uses tools, remembers | Design for all four capabilities |
| Agent patterns | Single, multi-agent, orchestrated | Start orchestrated, evolve upward |
| MCP | Agent-to-tool protocol | Expose tools via MCP servers |
| A2A | Agent-to-agent protocol | Design agent boundaries |
| Human-in-the-loop | Oversight designed in | Approval checkpoints per risk tier |
| Governance | Scope + contracts + escalation + kill switches + audit | Implement as code, not policy |
| Orchestration | Stateful workflow management | LangGraph, CrewAI, or custom |
| Guardrails | Constrain scope, safety, cost, compliance | Implement before production |
| Observability | Observe reasoning, not just requests | Trace chains, meter tokens |
| Economic guardrails | Cost ceilings, kill switches | Design in, not add after |
How to know if this landed
You'll know this has landed when someone stops treating agents like scripts and starts treating them as autonomous systems that need orchestration, not just integration. Can explain the four stages of automation evolution and their architectural implications. Agent architecture includes all four capabilities — planning, tool use, memory, orchestration. Agent integration uses standardised protocols — MCP for tools, A2A for inter-agent communication. Human-in-the-loop checkpoints are designed for each risk tier — approval, review, escalation, audit. Governance is implemented as code — scope, contracts, escalation, kill switches, audit. Guardrails are in place before production — safety, scope, cost, compliance, quality. And economic guardrails prevent runaway spending — per-task budgets, per-hour limits, kill switches.
What changes when the mental model clicks
I've run this session with a financial services company where manual customer support took 48 hours average response time. No automation — every response was human-written. Previous chatbot project failed — produced incorrect financial advice. The gap at the start is usually not about understanding agents — it's about not designing for controlled autonomy.
What changes after this session:
Teams stop treating agents like scripts and start treating them as autonomous systems that need orchestration. The agent capability test — "planning, tool use, memory, orchestration" — is always the moment things click. People stop treating guardrails as afterthoughts and start treating them as architectural components. Their results get better. They stop deploying agents without economic controls when the real problem was that they hadn't designed kill switches.
The opportunity mapping exercise tends to immediately change how teams think about their automation journey. They start sequencing correctly — observe, assist, automate, autonomise. Their success rates go up. They stop trying to autonomise complex tasks when the real problem was that they skipped Phase 1.
Book a Workshop
Ready to design agentic architectures with guardrails, observability, and economic controls?
or
1.5-day workshop includes automation opportunity map — identify where agents can add value in your context, agent architecture design — single, multi-agent, or orchestrated workflow, MCP/A2A integration planning — how to make your systems agent-accessible, human-in-the-loop design — approval checkpoints for your workflows, guardrail design — safety, scope, cost, and compliance constraints, economic guardrail design — inference budgets and kill switches, and automation opportunity map + agent architecture blueprint + MCP/A2A integration guide + Agentic Risk & Cost Framework.