Every governance pitch a regulated team hears arrives with a hidden tax: rebuild your agents on our platform. Move them onto our runtime, adopt our framework, let us host the thing that already works. The agent your team spent two quarters tuning becomes a migration project — and migration is where pilots go to die. The control you were promised is real; the cost of getting there is a second engineering effort nobody budgeted for.
There is a different principle, and it is the one MakerChecker is built on: wrap, do not migrate. You do not move your agent. You put a checkpoint in front of it. Your existing framework keeps executing the work; MakerChecker decides whether the work is allowed, and records that decision in a form an auditor can verify. Start where your agents already are.
The hidden cost of "move to our platform"
A migration is not a feature toggle. It is re-implementing prompts, re-wiring tool integrations, re-testing every path your validation team already signed off, and re-earning the trust of whoever approved the pilot. In a regulated shop, that last part is the expensive one, because it means re-validating a system that was finally working.
It also creates a new dependency. The moment your agent only runs inside a vendor's runtime, that vendor is on the critical path of a process your regulator holds you responsible for. If they have an outage, you have an outage. If they change a default, your control posture changes with it. For a QA, pharmacovigilance, or AML lead, that is the opposite of being in control.
The wrap-not-migrate principle removes the tax. Governance becomes an addition, not a rewrite. Your agent does not learn a new home. It learns that one of its actions now passes through a gate.
What a proxy session actually does
The mechanism is a proxy session — a session your agent opens with MakerChecker that sits between the agent's intent and the tool it wants to call. A proxy here means an intermediary: the agent does not call the tool directly any more; it asks through the proxy, and the proxy answers before anything touches the real world.
Two things happen inside that session, and only two.
First, authorization. MakerChecker checks the requested action against the agent's role and its versioned grants. Capability is deny-by-default: only the specific skills that role was explicitly granted are open, and every grant carries a version and a record of who approved it. If the action is outside the role, the proxy refuses — and the refusal is itself logged.
Second, the evidentiary record. Whether the action is allowed, denied, or parked for a human signature, the proxy writes it to a hash-chained, Ed25519-signed ledger. Ed25519 is a digital-signature scheme; what matters for a non-engineer is the property it gives you: change one entry and the chain visibly breaks, and the resulting export can be verified offline by someone who does not trust the vendor and has no access to your systems.
Note what does not happen in the proxy session. MakerChecker does not run the tool. It does not host your agent. It does not see the model weights or own the integration. The actual work still executes inside your existing framework — LangChain, an MCP server, your own orchestration code. MakerChecker is the checkpoint and the witness, not the engine.
Two roles in one line: checkpoint and record
It helps to separate the two jobs a wrapper performs, because most tools do only one.
| Job | Question it answers | Without it |
|---|---|---|
| Checkpoint | Is this actor authorized to do this, right now? | The agent acts first, you find out later |
| Record | Can I prove what was allowed, and that the proof is intact? | You have logs you wrote, that you could have edited |
The checkpoint is enforcement: deny-by-default grants, structural segregation of duties — the same agent provably cannot be both maker and checker on one run — and n-of-m approval gates where the requester cannot sign off on its own request. The record is evidence: the tamper-evident, offline-verifiable export. A wrapper that does both, without owning the agent, is the whole point.
This is also where MakerChecker sits alongside the guardrail tools you may already run. A guardrail asks "is this content dangerous?" MakerChecker asks "is this actor authorized?" Both can be true at once, and the two are complementary: the guardrail inspects the payload, the proxy session inspects the authority. Wrapping does not displace your content filters; it adds the authorization and audit layer they were never designed to provide.
How wrapping actually lands in your stack
For a non-technical buyer, the relevant question is not the integration code — it is what changes operationally. The answer is: very little, and that is the feature.
- Your agent keeps running where it runs. No new runtime, no re-hosting. Self-hosted MakerChecker can run in your environment, including air-gapped, on Postgres you already operate.
- One integration point, not a rewrite. MakerChecker is MCP-native and ships a LangChain connector, so the wrap goes in at the boundary your agent already uses to reach tools. Teams on those stacks can read the specifics in governing LangChain agents and MCP-native agent governance.
- Your validation work is mostly preserved. Because the agent's behaviour is unchanged and only the authority boundary is added, you are validating one new control surface — not re-validating the whole agent.
The result is that the work to get governed is small and the work to stay governed is structural. You are not relying on the agent to behave; you have moved the limits out of the agent and into enforced, versioned policy that the agent cannot edit. The six primitives behind that — Agent, Role, Skill, Trigger, Flow, and Run/Audit — are laid out in how it works.
Why this is the path out of pilot
Most agents are stuck in pilot for one reason: nobody can prove they are under control. The instinct is to assume that proof requires rebuilding the agent on something governable. It does not. It requires putting a checkpoint and a witness in front of the agent you already have.
In April 2026 the US banking regulator scoped agentic AI out of its model-risk guidance, and the EU's high-risk obligations slipped well into 2027. No new supervisory template means no safe harbor — examiners and litigation discovery will still ask who authorized an action and demand a record that has not been altered. The predicate rules underneath, written for people doing these jobs, have not moved. Wrapping is how an agent you already trust starts answering those questions today.
Migration asks you to bet the working thing to get governance. Wrapping lets you keep the working thing and add the governance. For a regulated team trying to get from pilot to production, that is not a small difference. It is the whole difference.
See how it works, or book a demo to watch an agent get blocked from approving its own work — live, with no migration required.