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.

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.

Why do AI agent retries duplicate work in enterprise systems?

Because a retry is only safe if the receiving system can recognise a repeat, and many enterprise interfaces cannot. When a call times out after the target has already committed but before the response arrives, the agent sees a failure and tries again — and the target, having no way to know it is the same instruction, does the work twice. Agents make this worse than ordinary integrations because they retry eagerly and can reword the same intent, so simple duplicate detection misses it. The fix is an idempotency key the target honours, or a check-before-write, decided before the agent is allowed to write at all.

How AI Agents Fit Into Existing Enterprise Systems

The pitch is that an agent slots into your organisation like a new joiner: give it access, point it at the work, let it get on with it. The pitch is wrong in an instructive way. A new joiner arrives into a structure that already knows how to contain them — a role with defined authorisations, an approval chain above them, a manager accountable for their output, and a probation period during which nobody hands them the payment run. An agent arrives with none of that unless you design it, and the default in most landscapes is not "restricted" but "whatever the credentials we gave it can reach."

So the practical question is not whether to use agents. It is where an agent sits relative to the systems that already run the business, and what has to be true before it is allowed to sit somewhere more powerful. This is the applied half of the argument that enterprise AI is an architecture problem.

Four placements, not one

Almost every agent design I have seen resolves to one of four positions relative to the existing landscape. They form a ladder, and the rungs differ enormously in what they demand.

Placement	What it does	Blast radius
Read-only beside	Reads, analyses, drafts; a human acts	A wrong answer someone acts on
Propose & queue	Prepares an action; a named person approves	A bad proposal that passes a tired reviewer
Scoped write	Writes a defined class of objects, under its own ID	Wrong data in a system of record, at volume
Orchestrator	Coordinates steps across several systems	Partial completion across systems, mid-chain

The mistake is not picking the wrong rung. It is not picking at all — connecting an agent to whatever credentials were available and discovering its placement afterwards, from the audit log.

Read-only beside the systems

The agent reads across systems and produces something a human uses: a summary, a comparison, a flagged exception list, a draft. It changes nothing.

This placement is underrated, because a great deal of enterprise pain is not "the action was hard" but "assembling the picture took three days." It is also where the risk is genuinely lower — though not zero, and the way it is not zero surprises people. A read-only agent can still read data nobody intended to expose to it. Point one at a document store or a shared drive and it will happily surface a salary schedule, an unannounced deal, or a personal file to whoever asks, because the agent has no concept of "you can technically open this but you shouldn't." The permission model of most enterprise content was designed on the assumption that a human would have to know where to look. An agent removes that assumption entirely.

So even at the safest rung, the design work is real: scope what it can see, not just what it can do, and check that scope against the question "who is asking?" rather than only "what did we connect?"

Propose and queue

The agent prepares the work and a named human approves it. Everything the agent produces lands in a queue with the proposal, the reasoning, and the evidence it used.

This is the placement I reach for most, because it maps onto a control structure the enterprise already has. Four-eyes approval, maker-checker, release strategies — these exist in finance systems precisely because someone once acted alone and it went badly. An agent as the maker and a person as the checker fits an established shape rather than fighting it, and it keeps the decision with the human while the execution goes to the machine.

Its characteristic failure is rubber-stamping. If the queue is long, the proposals are usually right, and the approve button is one click, approval degrades into acknowledgement within weeks. That is a design problem, not a discipline problem, and it has design answers: surface what changed rather than the whole object, make the agent state its confidence and its evidence, sample-audit approved items against what actually happened, and watch approval time as a metric — when median review time collapses, the control has quietly stopped existing.

Scoped write, under its own identity

The agent writes directly, for a defined class of actions, under an identity that belongs to it alone.

Two things make this survivable. The first is scope enforced where it counts: the agent's authorisations in the target system permit exactly the objects it needs and nothing adjacent. A prompt that says "only update draft records" is not a control. An authorisation that only permits draft records is. The second is that the identity is its own, so every action attributes to it and the trail is legible — and so that revoking it stops the agent without stopping four other integrations sharing the same technical user.

An agent's blast radius is not what it usually does — it is the worst thing its credentials permit on the day its judgement is wrong.

The concrete failure I would design against first is duplication. An agent that can post, retrying against a target that cannot recognise a repeat, will eventually do the same thing twice: a timeout after the target committed, a retry, two records. Agents make this sharper than ordinary interfaces because they retry eagerly and can reword the same intent, so naive duplicate checks slide right past it. Before a write placement is allowed, the target has to honour an idempotency key or the agent has to check before it writes — and somebody has to have tested that by actually forcing a timeout, not by reading the documentation.

Orchestrating across systems

The agent coordinates a sequence spanning several systems: read here, decide, write there, trigger something else, confirm.

This is where the value is, and it is also where enterprise integration has always been hardest, for a reason that has nothing to do with AI: there is no transaction spanning your ERP, your bank, and the third system. Step two succeeds, step three fails, and you are left in a state no single system considers invalid but the business does. Every landscape I have worked in had scars from exactly this, and the answers are the old ones — compensating actions, a saga-style unwind, a reconciliation that catches half-finished chains, and an explicit decision about what "partially done" means for each sequence.

An agent does not make this easier. It makes partial completion more likely, because it will attempt more sequences per day than any human process did, and it will attempt them at times when nobody is watching. An orchestrating agent without a defined unwind is not an automation; it is a generator of states your support team has never seen.

Earning the next rung

Placements should move up on evidence, not on enthusiasm. The criteria I would hold to before promoting an agent one rung:

Its outputs have been measured, not admired. A held-out set of real cases, scored — the same discipline as evaluation and regression testing — so "it's been good" is a number rather than an impression.
The scope exists in the target system. The authorisations are cut, tested, and confirmed to block what they claim to block. Verified by trying, not by reading the role definition.
Idempotency and reversal are proven. You have forced a duplicate and watched it be rejected, and you know how a wrong action gets undone.
The observability is in place first. Logging, sampling and alerting exist before the write does, because you cannot supervise what you cannot see and after an incident is a poor time to start.
Someone is named. A person accountable for the agent's output, who would be accountable if a human had done it.

Fail any one of these and the agent stays where it is. That is not caution for its own sake; it is the same gate a change of this consequence would face in any well-run intake and delivery process, applied to a component that happens to be probabilistic.

What I would decide

Choose the placement deliberately and write it down, because an unchosen placement defaults to whatever access was convenient. Start read-only and scope what the agent can see as carefully as what it can do. Use propose-and-queue for anything consequential — it fits the four-eyes control the organisation already runs on — and then watch the approval step for the moment it turns into a rubber stamp. Grant a scoped write only under a dedicated identity, only where the target is idempotent, and only where you can undo a bad day. Treat orchestration as the hardest rung, not the obvious next one, and define what happens when a chain stops halfway. The agent's capability is rarely the constraint. Its placement is, and that is the part you control.