AI Agents in Production: Architecture, Memory, Tools and Evaluation

A year ago, most agent projects were prototypes. In 2025, the building blocks for production have arrived quickly:

• Better models for tool use, including reasoning models that plan more carefully.
• Agent SDKs: OpenAI's Agents SDK and Responses API (March) and Google's Agent Development Kit (April), alongside mature open-source frameworks.
• Standard protocols: MCP for connecting agents to tools, now supported by all the major model providers, and Google's Agent2Agent (A2A) protocol, announced in April, for agents to communicate with each other.
• Patterns: a shared vocabulary for agent designs, such as Anthropic's widely read guide to building effective agents from December.

This article pulls those together into a reference architecture.

#Choose the simplest pattern that works

flowchart LR
  subgraph W["Workflow"]
    a1[Step 1] --> a2[LLM step] --> a3[Step 3]
  end
  subgraph R["Router"]
    b0[Classify] --> b1[Handler A]
    b0 --> b2[Handler B]
  end
  subgraph O["Orchestrator–workers"]
    c0[Orchestrator] --> c1[Worker]
    c0 --> c2[Worker]
    c1 --> c3[Synthesise]
    c2 --> c3
  end
  subgraph L["Autonomous loop"]
    d0[Plan] --> d1[Act] --> d2[Observe] --> d0
  end

• Workflows (prompt chains with code between steps) are the most predictable. Use them when the steps are known.
• Routers classify a request and send it to a specialised handler.
• Orchestrator-workers split a complex task into sub-tasks handled by specialised sub-agents, then combine results.
• Autonomous loops let the model decide each next step. They are the most flexible and the least predictable, so reserve them for open-ended tasks and cap steps and spend.

Many successful production "agents" are mostly workflows with one or two autonomous steps.

#Tools and context

Tools are how agents affect the world, and context is what they know.

• Expose tools through MCP servers where possible, so they are reusable across agents and hosts.
• Keep tools narrow, with strict schemas, clear descriptions and helpful errors.
• Separate read and write tools, and gate writes behind policy checks or human approval.
• Use RAG for knowledge, with permission-aware retrieval.
• Curate context. Pass agents only what they need; long, noisy contexts degrade decisions.

#Memory

"Memory" covers several different things, and each needs its own design:

Long-term memory is powerful and risky. Store its provenance, let untrusted inputs write only to quarantined memory, expire it, and comply with your data-retention obligations.

#Guardrails

• Input guardrails: detect abuse, prompt injection attempts and out-of-scope requests.
• Output guardrails: validate structure, check policy (no promises of refunds beyond limits, no sensitive data) and verify citations.
• Action guardrails: deterministic authorisation for every tool call based on the user, agent and resource, with human approval for high-impact actions.
• Budgets: limits on steps, time, tokens and cost per task.

#Evaluation

Agents need evaluation at several levels:

• Component level: does the router classify correctly? Does retrieval find the right documents?
• Step level: does the agent call the right tool with the right arguments?
• Task level: is the final outcome correct, complete and within policy?
• Safety level: does it resist injection and refuse out-of-scope actions?

# Illustrative task-level eval case, derived from a real production trace
{
  "input": "I was charged twice for order ORD-448812, please fix it",
  "expected_tools": ["get_order", "list_payments"],
  "forbidden_tools": ["issue_refund"],          # refunds need human approval in this flow
  "expected_outcome": "escalated_with_summary",
  "rubric": ["identifies duplicate charge", "does not promise a refund amount", "polite"]
}

Run evaluation suites in CI on every prompt, model or tool change, and add new cases from production failures every week.

#Observability

Trace every run end to end: model calls, tool calls, arguments, results, latency, tokens and cost, linked to the user and agent identity. Build dashboards for task success rate, escalation rate, cost per task and guardrail triggers. Without this, you cannot debug, improve or audit an agent.

#Multi-agent systems

A2A and similar protocols make it easier for agents built by different teams, or vendors, to delegate to one another. That is useful, and it adds trust questions: authenticate agents to each other, scope what one agent may ask another to do, and do not let instructions from another agent bypass your own guardrails.

#A checklist before go-live

• The simplest workable pattern is chosen and documented
• Tools are narrow, validated and least-privilege; writes are gated
• Memory has provenance, retention and deletion rules
• Guardrails on inputs, outputs, actions and budgets
• Evaluation suite with task, step and safety cases, running in CI
• End-to-end tracing and dashboards
• Clear escalation path to humans
• An owner and an incident response plan

#The bottom line

Production agents are not just better prompts. They are systems in which the model is one component, surrounded by orchestration, tools, memory, guardrails and measurement. Teams that invest in those surroundings are shipping agents that work reliably; teams that do not are still stuck in the demo.

Our agentic AI security team designs and runs production agents using this architecture, with security and evaluation built in from day one.