The Action Layer
External grounding gets information into your agent. The action layer sends instructions out. This is where agents stop being observers and start doing things — writing to databases, sending messages, triggering workflows, updating CRMs. The Model Context Protocol is the standard that makes this possible.
What This Flow Does
Flow #3 is where agents call MCP tools to take real-world actions. Not reading data, not generating text — actually changing the state of external systems.
An agent that can reason and retrieve information is useful. An agent that can act on what it knows is transformative. The action layer is the boundary between analysis and execution. When an agent writes a row to a database, sends a Slack message, updates a CRM record, or triggers a deployment pipeline, it's operating in this flow.
MCP provides the standardised protocol for connecting to any external service. Each MCP server exposes a set of tools — discrete actions the agent can invoke with structured parameters. The agent doesn't need to know how Salesforce's API works, or how your internal ticketing system is built. It just needs to know what tools are available and what parameters they accept. The MCP server handles the translation.
In practice, I wire up MCP servers for the specific systems a client's agents need to interact with. That might be a handful of servers for a focused use case, or dozens for an agent that operates across an entire business stack. The protocol makes it possible to add new capabilities without rewriting the agent itself.
Information In vs Actions Out
Both this flow and external grounding use MCP servers. The distinction between them matters more than most people realise.
Flow #2 — External Grounding
Direction: Information flows in
The agent reads from the world. It searches the web, queries a database, fetches live data from an API. The external system is unchanged. If the agent gets bad information, the damage is contained — you get a poor output, but nothing in the real world has been altered.
Risk profile: Low. Bad reads produce bad outputs, not bad consequences.
Flow #3 — MCP Action Layer
Direction: Actions flow out
The agent writes to the world. It creates records, sends messages, modifies data, triggers processes. The external system is changed. If the agent takes a wrong action, the consequences are real — a message has been sent, a record has been modified, a workflow has been kicked off.
Risk profile: High. Bad writes produce real-world consequences that may be difficult or impossible to reverse.
This asymmetry is fundamental to how I design agentic systems. Reading and writing both use MCP servers, but they demand different levels of caution, different approval workflows, and different monitoring strategies. Treating them the same is one of the most common mistakes I see in early-stage agent deployments.
Human-in-the-Loop
Because actions have consequences, this is the flow where approval gates matter most.
Not every action needs human approval. Logging a record to an internal database is low-stakes. Sending an email to a client on behalf of your CEO is not. The skill is in calibrating the approval threshold — making the agent fast where speed matters and careful where caution matters.
In practice, I implement tiered approval systems. Low-risk write operations — internal logging, draft creation, staging environment updates — run autonomously. Medium-risk operations — sending messages, updating records — get flagged for review with a sensible timeout. High-risk operations — financial transactions, public communications, data deletions — require explicit human approval before execution.
The MCP action layer is where safety intersects most visibly with functionality. Every other flow can afford to be mostly autonomous. This one can't — at least not until you've built enough observability and safety infrastructure (flows #4 and #5) to trust the agent's judgement. And even then, the highest-stakes actions should always have a human in the loop. That's not a limitation of the technology. It's good system design.
What This Flow Doesn't Solve
You can take actions. But how do you know they were correct?
The action layer gives your agent the ability to do things. It doesn't tell you whether those things were done well. An agent can update a hundred CRM records in a minute — but were the updates accurate? It can send a dozen follow-up emails — but were they appropriate? It can trigger a data pipeline — but did the pipeline produce the right output?
These are observability questions. Knowing what happened, measuring whether it met expectations, tracking costs and error rates, building audit trails — all of that belongs to Flow #4: Observability. The action layer is the muscle. Observability is the nervous system that tells you whether the muscle did what the brain intended.
Until you have observability in place, every action your agent takes is a black box. You know it did something. You don't know if it did the right thing. That gap is where the next flow picks up.
Go Deeper
MCP is both a building block and the backbone of this flow. For a detailed breakdown of the protocol itself — how servers work, what the primitives are, how I deploy them — see the building block page.
Ready to give your agents the ability to act?
I design MCP action layers with the right balance of autonomy and human oversight — so your agents can do real work safely.