Topic
Enterprise AI Systems: Architecture & Controls
Enterprise AI is an architecture problem long before it is a model problem. The interesting questions are where an agent sits relative to the systems of record, what it is allowed to write, which decisions it may take alone, how its work is logged and reviewed, and what happens on the day it is wrong.
This hub covers that layer: integration with the systems the business already runs on, enterprise data and state, controls and segregation of duties, human oversight boundaries, and the observability without which none of it can be trusted in production. Grounded in a career spent integrating systems that were not designed to talk to each other.
2 articles · ~14 min, in reading order
Why Enterprise AI Is an Architecture Problem
Enterprise AI stalls on architecture, not model quality: who owns the record, what the AI may write, under whose identity, and how it is logged and rolled back.
How AI Agents Fit Into Existing Enterprise Systems
The four placements an AI agent can take beside your existing systems — read-only, propose-and-queue, scoped write, orchestrator — and what each one demands.
Frequently asked questions
Why is enterprise AI an architecture problem rather than a model problem?
Because the model is the most replaceable component in the design and everything around it is not. Model quality decides whether a demo impresses; architecture decides whether the capability can run against systems that already hold the company's money, contracts and master data. The questions that actually gate a rollout are which system owns the data, what the AI is permitted to write and under whose identity, how its actions are logged and reconciled, how it behaves when a system it depends on is unavailable, and how a bad change is rolled back. None of those are answered by choosing a better model.
Full article →Where should an AI agent sit relative to the systems of record?
Alongside them, at the lowest placement that still delivers the value. There are four practical positions: read-only beside the systems, producing analysis a human acts on; propose-and-queue, where the agent drafts an action and a named person approves it; write-through under a narrowly scoped identity for a defined class of low-consequence actions; and orchestrator, coordinating steps across several systems. Each step up multiplies both the value and the blast radius, so the placement should be an explicit design decision with named criteria for moving up — never something a capability drifts into because it was already connected.
Full article →What has to be decided before an AI capability touches a system of record?
Four things, explicitly and in writing. First, ownership: which system holds the authoritative version of the data, and whether the AI is reading a master or a copy. Second, write scope: exactly which objects it may create or change, and which it may only read. Third, identity: the account the write happens under, so the action attributes to something a person is accountable for rather than to a shared technical user. Fourth, reversal: how a wrong action is detected and undone. If any of the four is undecided, the capability is not ready to write.
Full article →What access should an AI agent be granted in an enterprise system?
The narrowest set that lets it do the one job it was built for, enforced by the target system's own authorisation model rather than by instructions in a prompt. In practice that means a dedicated identity per agent and purpose, an explicit list of objects it may read and a shorter list it may change, and no combination of rights that lets the same identity both create and approve. Access granted for convenience during a pilot is the access it will still hold in production, so scope it as if it were permanent, because it usually is.
Full article →How should AI actions be logged in an enterprise landscape?
Well enough that someone can reconstruct a specific action months later without your help. In practice that means recording what was requested, what the AI proposed, what it actually did, which identity it used, which downstream system accepted it, and which version of the prompt and model produced the result. The test is not whether a log exists but whether it answers the question an auditor or a controller will actually ask — why did this record change, on whose authority, and can you show me the same decision made twice the same way.
Full article →Follow the build → — one practical finance-systems pattern, product decision or build lesson every two weeks.