Agentic AI Architecture: Building AI Systems That Can Actually Act

A chat assistant that gives a wrong answer wastes a user's time. An agent that takes a wrong action can refund the wrong customer, delete the wrong records or email confidential data to the wrong person. As organisations connect AI to real business processes, the architecture has to change to reflect that.

This post describes the architecture we use for agentic systems: AI that can actually act, safely.

#The core principle: models propose, systems dispose

The central design decision is to separate probabilistic reasoning from deterministic control.

• The model is excellent at understanding requests, planning and choosing among options. It is also fallible and can be manipulated.
• The system around it decides whether a proposed action is allowed, executes it reliably and records what happened.

flowchart TB
  U[User / event] --> O[Orchestrator]
  O --> M[Model: interpret & plan]
  M -->|proposed action| P{Policy engine<br/>identity, scope, limits}
  P -->|deny| O
  P -->|needs approval| H[Human approval]
  H -->|approved| X
  P -->|allow| X[Executor<br/>idempotent, retried, logged]
  X --> S[(Business systems<br/>via MCP / APIs)]
  X --> A[(Audit log)]
  X --> ST[(Durable task state)]
  ST --> O

#Building block 1: an explicit action layer

Rather than letting the model call business APIs directly, route every action through an action layer that:

• validates arguments against strict schemas,
• asks a policy engine whether the action is allowed for this user, agent and resource,
• requests human approval where policy requires it,
• executes with retries, timeouts and idempotency keys, and
• writes an audit record.

This is where most of the safety of an agentic system lives, and it is ordinary, testable code.

#Building block 2: identity and authorisation

Every action should answer: who is acting, on whose behalf, under what authority?

• Agents have their own identities, separate from human users.
• Actions carry both the agent identity and the delegating user's identity.
• Authorisation uses the user's permissions (the agent should never see or do more than the user could), further restricted by the agent's own scope.
• Policies are expressed as code and reviewed like code.

def authorise(action, agent, user, resource):
    if action.name not in agent.allowed_actions:
        return Decision.deny("action not in agent scope")
    if not user.can(action.permission, resource):
        return Decision.deny("user lacks permission")
    if action.name in HIGH_IMPACT and action.value > agent.approval_threshold:
        return Decision.require_approval(approver=resource.owner)
    return Decision.allow()

#Building block 3: durable state

Real tasks take minutes, hours or days, and involve waiting for approvals, other systems or people. Agents need durable task state outside the model's context:

• persist each step's inputs, outputs and status,
• resume after restarts or failures,
• avoid repeating side effects (idempotency), and
• support cancellation and timeouts.

Durable workflow engines, or a simple task table with careful state transitions, work well here. The model reads a compact view of state rather than an ever-growing transcript.

#Building block 4: integration through standard interfaces

Expose business capabilities through MCP servers or well-defined internal APIs rather than ad hoc connections. That gives you a catalogue of what agents can reach, versioned interfaces, and one place to apply credentials and logging.

#Building block 5: memory with provenance

Separate short-term context (this task), long-term memory (preferences, learned facts) and organisational knowledge (RAG over documents). Record where every memory came from, restrict who and what can write to it, and expire it. Memory written from untrusted inputs should never become standing instructions.

#Building block 6: evaluation and observability

• Trace every run: prompts, plans, proposed actions, policy decisions, executions and outcomes.
• Evaluate continuously with task-level test suites built from real cases, including adversarial ones.
• Monitor success rates, escalations, denials and cost, per agent and per workflow.

#Designing for failure

Assume the model will sometimes:

• misunderstand the request,
• choose the wrong tool or arguments,
• be manipulated by content it reads, or
• loop without progress.

Then make each of those failures cheap: schema validation and policy denials catch bad actions, approvals catch high-impact mistakes, budgets stop loops, idempotency makes retries safe, and audit logs make everything explainable afterwards.

#Organisational building blocks

Architecture is not only technical:

• Ownership: every agent has an accountable owner.
• Change control: prompts, tools, policies and models change through review and testing.
• Inventory: a registry of agents, their tools, identities and data access.
• Incident response: a plan for when an agent misbehaves, including how to disable it quickly.

#The bottom line

The difference between an AI that talks and an AI that acts is an architecture that treats actions with the seriousness they deserve. Keep the model in the role it is good at (understanding and planning), and surround it with deterministic policy, durable execution, standard integrations and full observability. That is how agentic AI becomes something you can connect to your business with confidence.

Our agentic AI security team designs agentic systems on this architecture, and our red teaming tests them adversarially before go-live.