Agents and the systems of record

An agent with no connection to a system of record is a conversational tool. An agent with unconstrained access to one is a risk nobody signed off. Almost all of the useful design lives between those two positions.

Read and write are not the same decision

Organisations grant agents read access readily and write access reluctantly, and that instinct is correct rather than merely cautious.

A read that returns the wrong record produces a wrong answer, which a person may catch. A write that touches the wrong record produces a change to the business, which may be discovered by a customer.

So the useful default is: broad, well-instrumented read access, and narrow write access that is enumerated explicitly and enforced at the point of action rather than requested in a prompt.

Why prompts are the wrong place for this boundary

A prompt is an instruction to a model. Models are persuadable, and an agent following a plan can arrive at an action that its instructions discouraged but did not prevent.

Enforcement belongs where the action occurs. If an agent must never write to the billing table, that constraint lives at the connection, so the answer to "could this have happened" is determinate. This is also what makes an audit meaningful: the record shows what was attempted, and the boundary shows what was possible.

Staleness is the failure nobody plans for

Systems of record change while an agent is working. A plan built at the start of a run can be acting on a record that moved thirty seconds later.

This produces a specific kind of damage: work that is internally consistent and externally wrong, which then has to be unpicked by a person who did not do it. Situation awareness in Oran 3.6 exists for this: keeping track of what has happened within a run and what changed underneath it, so a step is not repeated or applied to a record that has moved.

Identity matters more than access

An agent acting with a shared service account is untraceable in the place where traceability matters most. Six months later, "which agent changed this" has no answer.

Credentials resolving at runtime from an organisation-level vault, scoped per agent, fixes this at the root. The agent never holds a secret in clear text, revocation is one action, and every write in the audit trail carries the identity that made it.

The approval boundary

Some writes should not proceed without a person. Not all of them, or the agent is a suggestion box, but the ones where being wrong is expensive or hard to reverse.

Treating this as a property of specific actions rather than blanket review keeps it meaningful. A person who approves everything approves nothing, because attention does not survive repetition.

A sensible sequence

Start read-only against a system where retrieval is genuinely hard. Instrument what the agent reads and what it produces. Write evaluation criteria from real cases. Only then enumerate a small set of writes, enforce them at the connection, and put the expensive ones behind approval.

This is slower than connecting everything and seeing what happens. It is also the version where nothing has to be unpicked.

Next

The Agent Orchestration System pages cover policy enforcement, the credential vault and the audit trail. The developer documentation covers connection mechanics.