An agent that can write to business systems needs more than a model and a list of tools. It needs an action layer with rules: one place where tools are defined and versioned, checks that run before anything changes, a human who validates every write, protection against duplicate execution, a record that lets any decision be replayed, and an identity that never exceeds the requesting user’s rights. This guide describes that layer using the Model Context Protocol (MCP).
Why agents need an action layer
Reading is low risk; writing is not. If an agent calls business APIs directly, each integration decides on its own what the agent may do, how it is authorised and what gets logged. The result is behaviour that cannot be reviewed in one place and mistakes that cannot be replayed. An action layer puts all of that in one service: the agent proposes, and the layer decides.
One MCP action server
MCP is an open protocol for exposing tools to AI models. Serving all agent actions through a single MCP action server gives agents one uniform interface and gives the organisation one place to add controls. The server, not the agent, holds the credentials for downstream systems and decides whether a call may proceed.
Versioned tool manifests
Each tool is described by a manifest: its name and purpose, its input and output schemas, whether it reads or writes, and which checks apply. Version the manifests. When a tool changes, agents and evaluations pin to a version, so a behaviour change is a deliberate release rather than a side effect, and old decisions can be interpreted against the manifest that was in force when they were made.
Human validation on every write
Any tool that changes state requires a person to approve the concrete action, meaning the exact parameters and not a summary, before it runs. Reads run without approval.
This is slower than full autonomy by design. It keeps a person accountable for each change and gives the agent a safe way to be wrong: a rejected proposal costs a click, not an incident.
Idempotency and preconditions
Networks retry and users double-click. Give every write an idempotency key so that executing it twice has the effect of executing it once. Attach preconditions, the state the action assumes (for example, “the record is still in draft”), and have the server check them at execution time. A precondition failure means the world changed between proposal and approval, and the right response is to re-propose, not to force the write.
A replayable decision log
Record every proposal, approval, rejection and execution in an append-only log: who or what proposed it, the tool manifest version, the inputs, the checks that ran and the outcome. Append-only means entries are never edited; corrections are new entries.
For audit and retention requirements, export the log to write-once (WORM) storage such as S3 Object Lock in compliance mode, so that not even administrators can alter history while the retention period runs. With this log, any decision can be replayed and explained after the fact.
Identity: inherit the user’s permissions
The agent should hold no privileges of its own beyond those of the person it acts for. With OAuth2 Token Exchange, the platform exchanges the user’s token for a scoped token for the downstream call, so the downstream system sees, and enforces, the user’s rights. Workloads themselves use short-lived, per-service cloud identities rather than shared secrets. The rule is simple: the AI can do what the user can do, never more.
In practice
On the ENSO platform, I specified agentic actions through a single MCP action server with versioned tool manifests, human validation on every write, idempotency and precondition checks, and an append-only decision log that makes every AI decision replayable, with a WORM export to S3 Object Lock. The AI inherits the user’s permissions through OAuth2 Token Exchange (Keycloak, OIDC) and IRSA workload identities. The full architecture is in the ENSO case study.
Trade-offs and limits
Human validation on every write limits throughput and is a poor fit for high-volume, low-risk automation. You can later relax it for specific tools where the risk is low and the manifest says so.
An action layer is another service to build and keep available. And the log is only as useful as the discipline around it: define retention, access and export before you need them.