Why Business Agents Need a System-of-Record Boundary
Short answer#
A business agent can interpret context, plan a next step, and propose an action. It should not quietly become the place where business truth is created.
The system-of-record boundary is the separation between agent work and committed business state. The agent can help move work forward, while the business keeps explicit control over context, permissions, approvals, durable records, and recovery.
This boundary matters whenever an agent touches customer conversations, bookings, operations, financial actions, or internal decisions. A fluent answer is not the same thing as a committed outcome.
Reasoning can be flexible. Records cannot.#
Agents are useful because they can work across messy inputs: a conversation, a customer record, a policy document, and an operational objective. That flexibility is valuable during interpretation.
Durable business state has a different job. It must be scoped, attributable, retryable, auditable, and recoverable. If an agent writes directly to the underlying record, a mistake can become difficult to detect and harder to reverse.
The safer pattern is:
- bind the work to the right tenant, customer, conversation, and source evidence;
- expose only the tools permitted for that context;
- apply policy and approval requirements before side effects;
- record the result as a durable receipt;
- leave the backend and database responsible for business truth.
The boundary has five parts#
| Part | Question it answers | Why it matters |
|---|---|---|
| Context | What is this work about? | Prevents the agent from reasoning over an incomplete or wrong customer/workspace frame. |
| Scoped tools | What is the agent allowed to do? | Limits actions to the capabilities and permissions available for this task. |
| Human authority | Who decides when risk or ambiguity matters? | Keeps customer impact and policy exceptions visible to an owner. |
| Receipts | What actually happened? | Makes outcomes inspectable and gives operators a recovery handle. |
| System of record | Where does committed truth live? | Prevents model output from becoming an ungoverned source of business state. |
These are not separate layers that only matter to infrastructure teams. They shape the user experience. An operator should be able to see the context, the proposed action, the approval state, and the result without reconstructing the story from a chat transcript.
What this looks like in a real workflow#
Consider a customer question waiting in an operations queue. A bounded workflow can:
- read the waiting conversation and customer context;
- retrieve the relevant source evidence;
- draft an internal response;
- stop when a human decision is required;
- record that the draft was saved for review.
The workflow is still useful even when it does not send a customer message autonomously. In fact, the explicit non-action is part of the evidence: the operator can see that the draft was created, approval was required, and outbound sending remained disabled.
Mirai’s current public product story uses this kind of controlled proof. The homepage shows the governed operating loop and the Team Inbox boundary. The About page explains the product definition, and the FAQ states what is implemented, controlled, staged, or still directional.
Why approval is not the whole solution#
Adding an approval button is useful, but approval alone does not create a system-of-record boundary.
You also need to know:
- which tenant and records were in scope;
- which sources shaped the proposal;
- which tool or operation was selected;
- whether the request was a retry or a conflicting replay;
- what durable result was written;
- what outbound effect did or did not occur.
That is why governed agent infrastructure combines approval with tenant scope, policy checks, idempotency, audit, and backend-owned writes. The exact implementation varies by workflow, but the design principle is stable: agents may orchestrate work; the business system commits truth.
How to evaluate an agent before production#
Start with one workflow rather than a platform-wide promise. Ask five questions:
- What real queue, record, or task does the agent receive?
- What evidence must it retrieve before proposing work?
- Which actions are read-only, reversible, approval-gated, or prohibited?
- What receipt proves the outcome?
- What is the recovery path when the tool, policy, or source data fails?
Mirai’s developer documentation provides a staged evaluation path for Atlas. The first-request guide and safety and recovery guide are the right places to inspect the current contract and boundaries. Atlas REST and MCP surfaces should be treated according to their published maturity, not inferred to be generally available from a page or code sample.
The boundary is the product#
The point is not to make agents less capable. It is to make their capability usable inside a real operating environment.
An agent that can answer but cannot prove what it changed is difficult to trust. An agent that can act without clear scope is difficult to govern. An agent that can propose work, route risk to a human, and return a durable receipt can become part of the operating system without replacing it.
That is the problem Mirai is built to explore: put agents to work, while keeping the business in control.
Bring one real workflow
Map its context, tools, approval boundary, and system-of-record outcome in a guided evaluation.
Request a guided evaluation