- Runs against
- The systems your agents need to reach
- Enforced in
- The tool layer, outside the model’s text
- You get
- Typed contracts and a permission model
A standard for access is not a control on it
An agent is only as useful as the systems it can reach. The Model Context Protocol has become the standard way to expose those systems, but standardising tool access is not the same as controlling it — MCP does not replace authorization.
The failure this produces is quiet. An MCP server gets treated as a trusted plugin rather than a production integration, the agent is handed the credentials of whoever deployed it, and a retry that should have been idempotent issues a second refund. None of that is a model problem, and no better model fixes any of it.
So we build the tool layer between your agents and your software: typed, versioned, permissioned, and safe to change.
What the work covers
- Tool contracts Typed inputs and outputs with explicit failure modes, so an agent gets a usable error rather than an ambiguous string.
- Versioning and deprecation Tools versioned so a change does not silently break every agent depending on them.
- Permissioning Authorization enforced in the tool layer, outside the model-generated text, with the agent inheriting no more authority than the user on whose behalf it acts.
- Retrieval and context Document and knowledge retrieval defined as a contract, with what is retained, why, and how it can be deleted made explicit — and not called memory, because that name hides all three questions.
- Idempotent, previewable side effects Keys and dry-runs on the actions that change something, so a retry cannot duplicate a refund, a deployment or a message.
- Server integration Connecting existing MCP servers where they fit, and building them where they do not — each treated as a production integration rather than a trusted plugin.
How the engagement runs
Four stages, each ending in something you keep. No weeks are attached: the length follows the number of systems in scope and how many of their actions cannot be undone.
- Stage 1 Capability map Every system an agent needs to reach, the authority each action requires, and — the column that matters — which actions cannot be reversed once taken. You get: a capability map with an authority and a reversibility column.
- Stage 2 Contracts Typed schemas for every tool, an error taxonomy an agent can act on, and a versioning policy that says what a breaking change is before anyone ships one. You get: tool contracts, an error taxonomy and a versioning policy.
- Stage 3 Build and connect Servers built or adopted, authorization enforced in the tool layer, and the irreversible actions given previews and idempotency keys. You get: the tool layer running, with permissions outside the model.
- Stage 4 The acceptance test A second agent handed a capability with no new integration work. That is the test we hold this to, and it either passes or the layer is not finished. You get: a demonstrated second consumer, or the list of what stopped it.
What you leave with
- The capability map — and a written answer to which actions are irreversible.
- Tool contracts — typed, versioned, with failure modes stated rather than discovered.
- A permission model — enforced in the tool layer, where the model cannot argue with it.
- A second consumer — the proof that the next agent is a configuration rather than a project.
The method, published
Layer 4 of the production agent stack sets out what a tool contract has to state — input schema, authorization scope, side effects, idempotency, timeout, error format, data classification, audit fields — and why a short, precise tool list beats a large catalogue.
The reason authorization cannot live in the prompt is the control plane and the execution plane: the model takes part in deciding, but it is not the security boundary, and retrieved documents, pages, tickets and tool results are untrusted data that may carry instructions aimed at it. What not to do names the two failures this engagement exists to prevent: calling retrieval memory, and handing agents unrestricted credentials.
Tell us which of your systems an agent can already write to, and whether a retry there is safe. The second answer is usually the interesting one.
Talk to usRelated services
Agent Production Readiness
Assess an agent system against the eight layers a production stack needs, and get a ranked plan to close the gaps.
Agent Evaluation and Cost per Task
Instrument what your agents actually complete, and what each completed task costs once retries and review are counted.
AI Governance and Data Boundaries
Model registry, routing policy and a hard data boundary, so regulated workloads can use AI and prove how.