Your Blueprint · the enterprise stack
Your systems don’t talk. Your agents can’t act in them.
An opinionated pattern for building enterprise software that stays malleable, evolves with the business, can act on its own, and carries observability and compliance from the first line. It assumes you already run most of what is on it. The whole drawing is below; scroll, and it is read the way an engineer reads a drawing — detail by detail, each one answering a problem you will recognise.
The enterprise stack · reference architecture
The sheet
The pattern comes before your systems.
This is the reference architecture at rest: four lanes, the connections each lane is permitted to make, and one control plane that every connection crosses. The dashed slots are the point — nothing on this sheet belongs to any one company yet. The drawing is the pattern, and what makes it yours is what fills it.
Your systems
Then what you run fills the slots.
The Software Review places what you already run onto the pattern: the systems of record in their lane, each keeping its tag — bought, twenty years old, already yours — and the canonical store beneath them. The surfaces fill the top: workspaces for the people on your payroll, portals for the customers, suppliers and partners you trade with. Nothing is replaced to earn its place. Each system keeps its slot, and every connection it already had now has one place to cross.
Detail 01 · the control plane
“Nothing talks to anything, and every integration is its own project.”
Systems that do not talk begin to.
Every line on the sheet crosses the control plane. An integration is published there once, as an operation, and consumed by any workspace, portal or agent that is entitled to it, so the connection count stops growing with the square of your systems. The plane holds the three things an integration platform was never asked to hold: an identity on every call, authority limits with approval gates, and one audit trail for people and software alike.
Detail 02 · agents that act
“The agents can describe the business, but none of them can act in it.”
Agents act across your systems, through one plane.
The agents stand beside the workspaces and the portals, as a third client of the same operations. The red line is the claim: every action an agent takes crosses the control plane, which decides whether that agent may take it before a system is touched, and records that it did after. Beneath the agents sit the two things that make them employable — the runtime that holds their state and tools, and the domain model that tells them what a customer, an order and an approval actually are.
Detail 03 · two kinds of agents
“Every product you run now ships its own agent, and none of them see the others.”
The agents you already own keep their jobs.
The small agent inside the service desk is the one that product shipped this year. It is good inside its own box and blind beyond it, so the drawing leaves it exactly there, and lets it reach your other systems only as a client of the control plane. The agents built for you live in their own box, on the runtime and the domain model, because their work crosses systems no vendor can see. Inside one product, use the agent it came with; across products, build in the agents box.
Detail 04 · the surfaces
“Every new surface is a fresh project, with its own login, its own integration and its own release train.”
Workspaces and portals are clients, not stacks.
The work lane holds two kinds of surface standing as peers on the same operations: workspaces for the people inside — operations, finance, service — and portals for the people outside — customers, suppliers, auditors. A new surface is a new client of endpoints that already exist, with identity and entitlements already decided. It is a front end, not a stack.
Detail 05 · one record
“Five systems hold the customer, and no two of them agree.”
One canonical record, instead of five copies.
The store at the bottom holds the canonical record: one shape for the facts that must agree across systems — the customer, the order, the balance. It is derived from the systems of record above it, not copied into a sixth system by hand, so when two systems disagree the drawing says which one is right and where the correction flows. An agent that answers with a number cites this record, and the citation can be checked.
Detail 06 · bought and built
“Every roadmap stalls on the same sentence: the core system would have to be replaced first.”
Bought, aged and built share the same lanes.
The systems lane is deliberately mixed, because every real company's is. The bought systems keep their vendors' shape, the twenty-year-old core keeps its data and its scars, the integration layer you already pay for keeps the transport, and the surfaces above them are built to the work that makes you different. The pattern asks none of them to become the others, and any box can be swapped later without the rest relearning who it was.
The sheet, complete
One pattern, any cloud, and a revision number.
This is the whole sheet: your systems and your data at the bottom, your people at the top, and one control plane between them deciding authority and keeping the record. It carries no product names, which is what lets it hold on any cloud, and a revision number, because it is meant to change as the business does. Below, one agent action is followed end to end, with what is checked and what is written down at every step.
One agent action, end to end
Control and an audit trail are easy to draw and hard to check. So here is one action all the way through, with what gets checked and what gets recorded at each step. Read it against your own controls and you will see which of the six you could already evidence.
- 01
A trigger arrives
An email lands, an event fires, or someone asks in a workspace. The agent that picks it up is a named principal with its own credential.
Written downThe trigger, its source, the agent identity, and the credential presented. - 02
It resolves against the domain model
Which customer, which order, and what state that thing is in, before any tool is called. An agent that plans before it resolves is planning against a guess.
Written downThe objects resolved to, and the version of the model read. - 03
The data's class decides what enters the prompt
Not the agent. Each field carries a classification: what may be sent to a model, what is masked, and what travels as a reference the control plane can resolve later instead of as a value.
Written downWhich fields were sent, which were masked, and under which classification. - 04
It plans and picks its tools
From the catalogue it was granted, and nothing else. The plan is written to the runtime's state store, so the run survives a restart.
Written downThe plan, the model and its version, the prompt, and the tools selected. - 05
The control plane checks each call, and stops at the limit
Is this identity allowed this operation, on this record, up to this amount, right now? Over the limit it stops, hands the decision to a named business owner with the evidence attached, and waits.
Written downAllowed or refused and against which rule. Then who was asked, what they saw, what they decided, and how long it sat. - 06
The write lands, and the trace comes back
Through the control plane, never around it. There is no second path with its own auth, which is the only reason the trail can claim to be complete.
Written downBefore and after, how this one reverses or that it does not, and the whole trace exported and retained to policy.
Who did this, on what authority, and can you prove it. That question has a one-query answer because the check and the write happen in the same place.
What each layer is worth
- People and access
- An agent never acts on a borrowed session, so every action has a name against it, including the ones software took.
- Where the work happens
- The people doing the work stop being the integration layer between six systems. And because the domain model and the control plane are built once, the second agent costs materially less than the first.
- The control plane
- One place to enforce means one audit trail, and observability arrives as a property of the architecture instead of a project per system. It is also the place to be honest about what cannot be taken back: a posted document reverses into a second document, and a closed period or a released order takes nothing back at all. Those operations sit behind an approval before the call, not an undo after it.
- What you already run
- The core that cannot be replaced stops being the reason nothing else can change.
What it assumes you already have
This is less new software than the drawing suggests. Four assumptions it makes about an organisation of this size, and what each one means for scope.
- You already own an integration platform
- Organisations of this size run an iPaaS, an ESB or API management, and it works. It stays, and it keeps doing transport, mapping and retries. What the control plane adds on top is the decision about whether a caller may perform an operation, and a tool surface agents can call. Most of it is configuration of something you already pay for, which is also why the cloud overlay pins an API gateway, not a bespoke runtime.
- Most of what you run is subscribed
- Three dozen applications the business depends on, each holding a slice of a process, each reached by API, each with rate limits and per-seat pricing. Agents are clients like any other, so throughput is a commercial question as much as a technical one. Price it before the pilot. This is also the reason the drawing never puts an agent inside a product you do not control.
- The domain model is scoped to one workflow
- Order, shipment, invoice: the objects one workflow touches, their states, and who may move them. That is weeks, and it is enough for the first two agents. It is not master data management, and the fastest way to kill this is to let it become a governance programme that has to finish before anything ships.
- It runs on the team you have
- Steady state is one more application on a rota a platform team already keeps. What is genuinely new is small and ongoing: reviewing what agents escalated, and re-running evals when a model or a prompt changes. Budget for that from the start, because it does not show up in a pilot and it does not go away.
Where to start
The order matters more than the drawing does. Build it in this sequence and each step pays for the next one.
- The first 90 days
- One workflow, end to end. The domain model for the objects it touches, the policy layer in front of two or three systems, and one agent doing the highest-volume, lowest-judgment step in it. It goes to production, with real users, on real data. A pilot that never leaves a sandbox proves nothing about your controls, which are the thing being tested.
- The two quarters after
- The second and third agents on the same workflow, then the second workflow. This is where the pattern either earns its cost or does not: the domain model and the control plane already exist, so the second agent should be materially cheaper than the first. If it is not, something in the first 90 days was built as a one-off, and it is much cheaper to find that out now.
- Steady state
- Agents become ordinary software on an ordinary release train, and new ones ship without a business case each time. The work that remains is reviewing escalations, re-running evals when a model changes, and extending the domain model as new workflows arrive.
Where this goes wrong
Five ways it gets built badly, including the two where the honest answer is to build nothing.
- Starting with the agents
- An agent without the domain model is a demo. It can talk about the business and it cannot act in it, and the second demo is worse than the first because everyone has now seen the trick. The domain model and the control plane come first, with the first agent live against them in the same quarter so the sequencing costs no momentum.
- Building what the vendor already ships
- Most of what you run is bought, and every one of those vendors shipped an agent this year. Inside a single product, theirs will usually be better than anything built here, and it is included. Build where the work crosses systems the vendor cannot see, and where the judgment is specific to your business. Everywhere else, buy it and connect it through the same policy layer.
- Letting an agent have a second path
- The nightly batch and the SFTP drop can stay where they are, because a person signed them off years ago and nothing about them is autonomous. An agent is different. A pilot in a hurry gives one a direct connection with its own credentials, and from that day the audit trail is no longer complete without anyone having decided it should not be. If an agent genuinely needs a second path, it goes on the drawing before it goes in production.
- Trusting what an agent reads
- A document, a ticket or a supplier email is untrusted input, and an agent that treats content as instruction can be steered by anyone who can write into a field it reads. The limit has to live in the catalogue, not in the prompt, so that nothing an agent reads can widen what it may do. Prompts are not a security boundary.
- Funding an agent for work a query answers
- If the work is deterministic and someone can write the rule down, write the rule down. Cheaper, faster, easier to defend. Agents earn their cost where the input is unstructured, the judgment is real, or the exceptions are the problem.
Hold it against what you already run, and mark the layers that exist, the ones that half exist, and the ones that don't.
Five days, complimentary. You keep the Blueprint either way.