Systems Work · No. 19

Enterprise Agent Fabric

Rajesh Ranjan Mahapatra

A layered estate of foundation, domain and process agents that lets a large regulated enterprise assemble governed agentic systems from certified parts instead of building each one from scratch.

© 2026 Rajesh Ranjan Mahapatra. 6 min read

Enterprise Agent FabricAll Systems Work

Enterprise Agent Fabric

A layered estate of foundation, domain and process agents that lets a large regulated enterprise assemble governed agentic systems from certified parts instead of building each one from scratch.

Challenge

A large regulated enterprise set out to run agentic AI at portfolio scale: dozens of use cases across credit, financial crime, servicing and operations, not a handful of pilots.

Architectural move

The estate is layered by how general the work is.

Control boundary

Agents move through a certification lifecycle the way an enterprise already manages models: certified, monitored, re-certified, retired.

Outcome

Teams I worked with took the estate through build and assurance at a large regulated enterprise, and it carries a broad portfolio of agentic use cases built by many teams.

FIG.00 // SYSTEM MAPSTORE / RECORDGATE / HUMANAGENTDETERMINISTICSIGNAL / DATAGOVGovernance planeRegistry andsigned identityCertificationlifecycleAllow-listedtopologyEstate killswitchL3 · PROCESSProcess agentsDecision memopreparationPeriodiccustomer reviewL2 · DOMAINDomain agentsEligibilityObligationsRestrictedpartiesConductL1 · FOUNDATIONFoundation agentsExtractionEntityresolutionSummarisationValidation andauditSHAREDShared servicesTiered memoryEvaluationGuardrailsBASEHuman oversight gateEveryconsequentialoutcome gated bypeopleVISIBLECOMPOSESCOMPOSESSERVESEXITS THROUGHSYS/EAFB · FIG.00 · SCHEMATIC · NOT TO SCALE
FIG.00 // SYSTEM MAPSIGNAL / DATADETERMINISTICAGENTGATE / HUMANSTORE / RECORDGOVGovernance planeRegistry and signed identityCertification lifecycleAllow-listed topologyEstate kill switchL3 · PROCESSProcess agentsDecision memo preparationPeriodic customer reviewL2 · DOMAINDomain agentsEligibilityObligationsRestricted partiesConductL1 · FOUNDATIONFoundation agentsExtractionEntity resolutionSummarisationValidation and auditSHAREDShared servicesTiered memoryEvaluationGuardrailsBASEHuman oversight gateEvery consequential outcome gatedby peopleVISIBLECOMPOSESCOMPOSESSERVESEXITS THROUGHSYS/EAFB · FIG.00 · SCHEMATIC
FIG.00 System map. Agents assembled from certified parts: three layers under one governance plane, with people gating every outcome.

The problem

FIG.01 // THE PROBLEMREJECTED PATHGATESIGNAL / DATAPORTFOLIODozens of use casescredit, financial crime,servicing, operationsDEFAULT PATHEvery team builds itsownagents, prompts, retrievaland controlsFAIL · 01Cost multipliesFAIL · 02Quality varies by teamREGULATORNobody can answerhow many agents, what each may touch, whocertified themSYS/EAFB · FIG.01 · SCHEMATIC · NOT TO SCALE
FIG.01 // THE PROBLEMSIGNAL / DATAGATEREJECTED PATHPORTFOLIODozens of use casescredit, financial crime, servicing, operationsDEFAULT PATHEvery team builds its ownagents, prompts, retrieval and controlsFAIL · 01Cost multipliesFAIL · 02Quality varies by teamREGULATORNobody can answerhow many agents, what each may touch,who certified themSYS/EAFB · FIG.01 · SCHEMATIC
FIG.01 The problem. The familiar path fails predictably; the premise was agents assembled from certified parts.

A large regulated enterprise set out to run agentic AI at portfolio scale: dozens of use cases across credit, financial crime, servicing and operations, not a handful of pilots. Each new team was about to build its own agents, its own prompts, its own retrieval and its own controls. That path is familiar and it fails predictably. Cost multiplies, quality varies by team, and nobody can answer the question a regulator eventually asks: how many agents do you run, what may each one touch, and who certified them?

I designed the architecture for a reusable agent estate, and teams I worked with took it through build and into live use. The premise was simple: agents should be assembled from certified parts, not written from scratch every time.

Why it was hard

FIG.02 // WHY IT WAS HARDREJECTED PATHGATE / HUMANMODELSIGNAL / DATASERVICESame thing tomorrowchange management, accesscontrol and code review assumedeterminismMODEL RISKKnow it, prove it, own itevidence per agent or the estatefails assuranceAGENTDrifts without a codechangemodel, prompt, retrievedcontext, accumulated memory→ CONTROLS CATCH THISCONTROLS MISS THIS ←REUSE MADE IT HARDERHZ · 01Defects travela credit skill picked up by financialcrimeHZ · 02Poisoned memorya bad write surfaces in another flowweeks laterHZ · 03Accountable humanfor consequential outcomesSYS/EAFB · FIG.02 · SCHEMATIC · NOT TO SCALE
FIG.02 // WHY IT WAS HARDSIGNAL / DATAMODELGATE / HUMANREJECTED PATHSERVICESame thing tomorrowchange management, access control and codereview assume determinism↑ CONTROLS CATCH THISMODEL RISKKnow it, prove it, own itevidence per agent or the estate failsassurance↓ CONTROLS MISS THISAGENTDrifts without a code changemodel, prompt, retrieved context,accumulated memoryREUSE MADE IT HARDERHZ · 01Defects travela credit skill picked up by financial crimeHZ · 02Poisoned memorya bad write surfaces in another flow weekslaterHZ · 03Accountable humanfor consequential outcomesSYS/EAFB · FIG.02 · SCHEMATIC
FIG.02 Why it was hard. Existing controls assume determinism, so none catch the failure modes that matter for agents.

Agents are not services. A service does the same thing tomorrow that it did today. An agent's behaviour depends on a model, a prompt, retrieved context and accumulated memory, and any of those can drift without a code change. The controls an enterprise already trusts, change management, access control and code review, all assume determinism, so none of them catch the failure modes that matter here.

Reuse made this harder, not easier. A summarisation skill written for credit gets picked up by financial crime, and now a defect travels. Shared memory is the same story: it is the most valuable thing to share and the most dangerous, because a poisoned write in one flow can surface as a wrong decision in another weeks later.

Underneath everything sat model risk requirements. Financial regulators expect an enterprise to know what a system does, prove it keeps doing it, and show that a human stays accountable for consequential outcomes. An estate that could not produce that evidence per agent would not survive assurance.

Key decisions

FIG.03 // KEY DECISIONSREJECTED PATHSTORE / RECORDGATEMODELDETERMINISTICSIGNAL / DATAD · 01Layer by generalityFoundation: reusehighestDomain: enterpriselogicProcess: end-to-endflowsD · 02Versioned contractInputs, outputs, toolpermissionsMemory rightsAccuracy baseline andcost profileD · 03Signed identityCentral registryScoped capabilitytokensRights live in thecredentialD · 04Cheapest capablemodelNumeric acceptance barSmall models for volumeReasoning models forjudgmentD · 05One-way authorityGenerative steps mayescalateNever overwrite adeterministic verdictSYS/EAFB · FIG.03 · SCHEMATIC · NOT TO SCALE
FIG.03 // KEY DECISIONSSIGNAL / DATADETERMINISTICMODELGATESTORE / RECORDREJECTED PATHD · 01Layer by generalityFoundation: reuse highestDomain: enterprise logicProcess: end-to-end flowsD · 02Versioned contractInputs, outputs, tool permissionsMemory rightsAccuracy baseline and cost profileD · 03Signed identityCentral registryScoped capability tokensRights live in the credentialD · 04Cheapest capable modelNumeric acceptance barSmall models for volumeReasoning models for judgmentD · 05One-way authorityGenerative steps may escalateNever overwrite a deterministicverdictSYS/EAFB · FIG.03 · SCHEMATIC
FIG.03 Key decisions. No amount of fluent reasoning talks past a rule.

The estate is layered by how general the work is. Foundation agents carry common skills: extraction, entity resolution, summarisation, validation and audit. Domain agents carry enterprise logic: eligibility, obligations, restricted parties, conduct. Process agents run end-to-end flows such as decision memo preparation or periodic customer review. Reuse is highest at the foundation layer and falls as you move up, which is exactly the shape you want.

Every agent ships with a versioned contract: inputs, outputs, tool permissions, memory rights, an accuracy baseline and a cost profile. Every agent holds a signed identity in a central registry with scoped capability tokens, so what an agent may touch is a property of its credential, not its prompt.

Each skill runs on the cheapest capable model that clears a numeric acceptance bar. Small models carry the high-volume skills; reasoning models are reserved for the calls that genuinely need judgment.

Authority is one-way. A generative step can request escalation, but it can never overwrite a verdict issued by a deterministic control below it. No amount of fluent reasoning talks past a rule.

Architecture

FIG.04 // ARCHITECTUREREJECTED PATHGATEAGENTDETERMINISTICA · 01Agentsends a messageCH · 02Schema-validatedchannelinjection-screenedTOP · 03Allow-listedtopologya new edge is anarchitecture reviewA · 04AgentreceivesBLAST RADIUSComputable, written intothe designSYS/EAFB · FIG.04 · SCHEMATIC · NOT TO SCALE
FIG.04 // ARCHITECTUREDETERMINISTICAGENTGATEREJECTED PATHBLAST RADIUSComputable, written into the designA · 01Agentsends a messageCH · 02Schema-validated channelinjection-screenedTOP · 03Allow-listed topologya new edge is an architecture reviewA · 04AgentreceivesSYS/EAFB · FIG.04 · SCHEMATIC
FIG.04 Architecture. Agents never talk freely; when one is wrong, the set it can influence is a number in the design.

Three agent layers sit between a shared control plane on one side and a governance plane on the other. The registry and the tiered memory feed all three layers; guardrails and evaluation apply to all three; anything consequential exits through a human oversight gate.

Agents never talk freely. Every agent-to-agent message crosses a schema-validated, injection-screened channel on an allow-listed topology, and the topology itself is a governed artefact. Adding an edge between two agents is an architecture decision with a review, not a configuration change. The design goal is a computable blast radius: when one agent is compromised or simply wrong, the set of agents it can influence is a number written into the design, not a discovery made during an incident.

Trade-offs

FIG.05 // TRADE-OFFSREJECTED PATHGATEDETERMINISTIC▼ PAYSDESIGN CHOICE▲ BUYSThe first use case is taxedT-01Contracts and evaluation packsThe second and tenth assemblerather than buildCalibration, thresholds andescalationT-02Small modelsMuch lower costSlower integration,deliberatelyT-03Strict topologyA bounded blast radiusCentral controls risk abottleneckT-04Certification as lifecycleTeams move through, not queueSYS/EAFB · FIG.05 · SCHEMATIC · NOT TO SCALE
FIG.05 // TRADE-OFFSDETERMINISTICGATEREJECTED PATHT-01Contracts and evaluation packs▼ PAYSThe first usecase is taxed▲ BUYSThe second andtenth assemblerather thanbuildT-02Small models▼ PAYSCalibration,thresholds andescalation▲ BUYSMuch lower costT-03Strict topology▼ PAYSSlowerintegration,deliberately▲ BUYSA bounded blastradiusT-04Certification as lifecycle▼ PAYSCentral controlsrisk abottleneck▲ BUYSTeams movethrough, notqueueSYS/EAFB · FIG.05 · SCHEMATIC
FIG.05 Trade-offs. The bet that later use cases assemble rather than build paid off.

The estate taxes the first use case to subsidise every later one. Writing a contract, an accuracy baseline and an evaluation pack for a single agent feels like overhead when a one-off bot would ship faster. The bet is that the second and tenth use cases assemble rather than build, and that bet paid off.

Small models are cheaper but less forgiving: they need calibration, confidence thresholds and an escalation path to a stronger model, all of which is machinery a frontier-model-everywhere design avoids. The strict topology slows integration, deliberately. Central controls can become a bottleneck, which is why certification is designed as a lifecycle teams move through rather than a committee they queue for.

Governance

FIG.06 // GOVERNANCEREJECTED PATHSTORE / RECORDGATE / HUMANDETERMINISTICLC · 01CertifiedLC · 02Monitoreddrift sentinels on toolselectionLC · 03Re-certifiedLC · 04RetiredMETEREDAutonomy budget beforecheckpointSYS/EAFB · FIG.06 · SCHEMATIC · NOT TO SCALE
FIG.06 // GOVERNANCEDETERMINISTICGATE / HUMANSTORE / RECORDREJECTED PATHMETEREDAutonomy budget before checkpointLC · 01CertifiedLC · 02Monitoreddrift sentinels on tool selectionLC · 03Re-certifiedLC · 04RetiredSYS/EAFB · FIG.06 · SCHEMATIC
FIG.06 Governance. Agents are managed like models; a human stays in the loop on anything irreversible, and the kill switch is estate-wide.

Agents move through a certification lifecycle the way an enterprise already manages models: certified, monitored, re-certified, retired. Autonomy is metered, rather than only permitted; each step carries a budget of unsupervised actions before a mandatory checkpoint. A human stays in the loop on any decision that cannot be undone, every agent action lands in an audit trail, and a kill switch exists at the estate level, not per bot. Drift sentinels watch each agent's tool-selection distribution over time, because the earliest symptom of contaminated memory is not a wrong answer but a changed habit.

Outcome

FIG.07 // OUTCOMEDETERMINISTICSIGNAL / DATAFOUNDATION LAYEREverywhereREUSED ALMOST ACROSS THE PORTFOLIOHIGH-VOLUME WORKfrontier costSmall modelsA FRACTION OF FRONTIER-MODEL COSTARRIVES PREBUILT FOR A NEW USE CASEFoundation agentsDomain agents across related flowsGovernance evidenceSCALED BECAUSE GOVERNANCE EVIDENCE WAS A BY-PRODUCT OF THE DESIGNSYS/EAFB · FIG.07 · SCHEMATIC · NOT TO SCALE
FIG.07 // OUTCOMESIGNAL / DATADETERMINISTICFOUNDATION LAYEREverywhereREUSED ALMOST ACROSS THE PORTFOLIOHIGH-VOLUME WORKfrontier costSmall modelsA FRACTION OF FRONTIER-MODEL COSTARRIVES PREBUILT FOR A NEW USE CASEFoundation agentsDomain agents across related flowsGovernance evidenceSCALED BECAUSE GOVERNANCE EVIDENCEWAS A BY-PRODUCT OF THE DESIGNSYS/EAFB · FIG.07 · SCHEMATIC
FIG.07 Outcome. A broad portfolio of use cases built by many teams on certified parts.

Teams I worked with took the estate through build and assurance at a large regulated enterprise, and it carries a broad portfolio of agentic use cases built by many teams. Most of what a new use case needs now arrives prebuilt: the foundation layer is reused almost everywhere, domain agents travel across related flows, and high-volume work runs on small models at a fraction of frontier-model cost. The programme scaled from proof of concept to production because the governance evidence was a by-product of the design rather than a document written afterwards.

What I learned

FIG.08 // WHAT I LEARNEDSTORE / RECORDGATEMODELAX-01Reuse is a governancepropertyNobody reuses an agent they cannottrust; trust needs a certificate.AX-02The registry is the productIdentity, permissions andcertification state in one place.AX-03Cheapest capable modelEnforced by bars, it ended morearguments than any benchmark.SYS/EAFB · FIG.08 · SCHEMATIC · NOT TO SCALE
FIG.08 // WHAT I LEARNEDMODELGATESTORE / RECORDAX-01Reuse is a governance propertyNobody reuses an agent they cannot trust;trust needs a certificate.AX-02The registry is the productIdentity, permissions and certification statein one place.AX-03Cheapest capable modelEnforced by bars, it ended more arguments thanany benchmark.SYS/EAFB · FIG.08 · SCHEMATIC
FIG.08 What I learned. Three lessons from the engagement.

Reuse is a governance property before it is an engineering one: nobody reuses an agent they cannot trust, and trust needs a certificate, not a demo. The registry turned out to be the real product; once identity, permissions and certification state lived in one place, everything else followed. And the discipline of the cheapest capable model, enforced by acceptance bars rather than taste, ended more arguments than any benchmark ever did.