Governed Agent Factory one build line for every agent
A repeatable build line for agents: PEVG contracts, evidence in the shape of a BOE Declaration, and gate records G1 to G5 for every agent, ready for second-line review.
The problem it answers
Teams build agents one at a time, each governed differently, and iSystematic's Governed Agent Factory gives every agent the same build line and the same records.
What it does
The factory is a repeatable build line. Every agent is built from declared PEVG contracts and a PARA registry entry, produces evidence in the shape of a BOE Declaration, and carries gate records G1 to G5 under the Five-Gate Deployment Model™, ready for second-line review.
Every team builds on one paved road, with delivery guardrails and trust tiers. An agent gains authority only after it passes a benchmark on its task, and someone who did not build it validates it.
Routing, execution and delivery evidence are joined for each request, so any agent's action can be reconstructed on demand.
The open repository
The open repository holds skills and the PEVG package, so an engineering team can start from the same contracts the factory uses before it works with us.
Built from
It is built from the PEVG package, the five gates and two catalogue patterns.
| Id | Name | What it brings |
|---|---|---|
| PEVG package | The PEVG package in the open repository | Declared contracts used for every agent |
| Five-Gate | Five-Gate Deployment Model™ | Five gate records, G1 to G5, kept for every agent |
| P11 | Keep a Workflow Receipt | Every run records inputs, source dates, approval, result and failures |
| P12 | Review and Retire | Every agent has an owner, a review date and a kill switch; unused agents are retired |
What it is built on
Five parts of the framework corpus decide how every agent is built and released, and each leaves a record the client keeps.
| Framework | In this solution | Client keeps |
|---|---|---|
| PEVG and PARA | Every agent built from declared contracts and a registry entry | Contracts; registry entries |
| Golden Path (OP-1) and Policy-Bounded Agentic Delivery (OP-2) | One paved road for every team, with delivery guardrails and trust tiers | The golden path; trust-tier register |
| Benchmark Before Authority (OP-4) | An agent gains authority only after it passes a benchmark on the task | Benchmark records |
| Five-Gate Deployment Model™ and MESA MRM Framework™ | Five gate records per agent; validation by someone who did not build it | Gate records; validation reports |
| Event identity (Pattern Language) | Routing, execution and delivery evidence joined per request | Reconstruction on demand |
Five parts apply to every build and are not repeated here: decision rights, the five gate records, a BOE Declaration per control, a vendor assessment for every vendor, and incident response. How we build sets out all of them.
Where a Sharia board binds
Where a Sharia board's authority binds the organisation, the factory also applies the Sharia AI Compliance Framework (SACF)™, and the client keeps dual-validation records and vendor screening attestations.
About the Sharia AI Compliance Framework (SACF)™: No Sharia Supervisory Board has reviewed or endorsed this framework. It is an engineering proposal offered for scholarly and institutional review.
Maxim in the factory
Maxim, iSystematic's Claude Code plugin, brings three things to the factory: skills that name the framework they apply, confidence tags with a four-line rubric (basis, gap, mitigation, next), and decision records treated as contracts the build must keep true.
Maxim runs on Claude today; editions for other assistants follow later, platform by platform. A factory on another model uses the same method without Maxim until that platform's edition is released, and each build states which Maxim features it relies on.
The evidence it leaves behind
Every agent leaves records the client keeps.
- Five gate records for each agent
- PEVG contracts and a PARA registry entry for each agent
- The golden path and a trust-tier register
- Benchmark records
- Validation reports
- Reconstruction of any request on demand
Typical buyer
The typical buyer is a chief technology officer or an AI centre of excellence.
Status
Proposed, as of 9 October 2026. A solution becomes Piloting or Released only after a documented pilot, and no result is shown for it before then.
How to start
Most engineering teams start with the open repository and the specifications, then run a six-week Pilot of the factory on one agent.
Where to go next
Engineering teams
For CTOs and AI leads: iSystematic builds agents on one governed line, each with declared contracts and five gate records, ready for second-line review.
Read more →AgentOps
AgentOps from iSystematic: monthly monitoring, evaluation re-runs, vendor and model change checks, a monthly note, and retirement of agents nobody uses.
Read more →Front Door Agent
The Front Door Agent gives an organisation one front door across email, web chat, WhatsApp and forms, built on ARIA by Simplification.io, with people approving.
Read more →Capabilities
The six capabilities behind iSystematic's solutions: agentic automation, MCP integration, knowledge and retrieval, conversation, AgentOps and enablement.
Read more →How we build
How iSystematic builds: every solution uses the same deposited frameworks. See what each part decides, what the client keeps, and each specification's DOI.
Read more →Conformance is self-declared; no regulator endorses this work.
Start with a Pilot
Six weeks, one solution live for one team, measured against a baseline taken before it starts.