Business Context Is a Living Operating Record

An illustrative invoice exception arrives because the purchase order total does not match the supplier invoice. Search can find the procurement policy, the contract, and an email approving a scope change. It still cannot tell the agent whether the approval was entered into the ERP, whether the remaining variance exceeds the finance threshold, or which owner must decide the exception today.

Those details are not background reading. They are the operating record of the case.

When an agent is expected to move work forward, business context has to include what the organization knows, what its systems currently show, who has authority, and how the case reached its present state.

A document can be relevant and still be operationally wrong

Retrieval systems usually optimize for relevance. An operating workflow needs additional tests.

The email approving the scope change may be relevant but insufficient because the sender lacked the required authority. A policy may be authoritative but expired. An ERP record may be current but incomplete because the amendment has not been entered. The supplier invoice may be accurate while still requiring a different approval route due to its amount.

The agent therefore needs attributes that ordinary text retrieval often treats as metadata:

• system of record;
• owner and delegated authority;
• effective date and version;
• current workflow status;
• relationship to the invoice, contract, and purchase order;
• access constraints; and
• events that changed the case.

This is why “more context” is a poor requirement. The workflow needs the smallest set of facts that can support the next decision, with enough provenance to challenge them.

Events explain the state that records alone cannot

Suppose the ERP shows a variance of 8 percent. That value describes the present state. The event history explains it: a project lead requested additional work, procurement approved the amendment, the contract team prepared new terms, and finance has not yet released the updated purchase order.

An agent that sees only the present value may classify the invoice as a supplier error. An agent that sees the event sequence can identify the incomplete internal handoff.

Activity traces can illuminate how work actually happens, but the implementation has difficult boundaries. Not every chat message is a business event. Not every repeated sequence is an approved process. Activity can reveal a pattern without granting that pattern authority.

For that reason, observed events and inferred relationships should remain distinguishable. The system should be able to say, “Finance approved amendment 4 in the contract system,” rather than silently infer approval from a meeting transcript.

Context needs a maintenance path

Living context can decay quickly. A connector stops syncing one object type. An owner changes roles. A policy is superseded but remains highly ranked because employees still open it. A workflow keeps an old approval limit in memory after finance publishes a new one.

The Coryntas integration approach treats a connection as part of the workflow contract: its inputs, outputs, permissions, side effects, errors, and returned evidence all matter. That makes context maintenance concrete. A stale source can be detected through timestamps. A missing owner can create an exception. A changed schema can fail a contract test instead of quietly dropping a field.

The tradeoff is operational overhead. Source authority must be assigned. Freshness expectations must be monitored. Exceptions need owners. Inferred relationships need correction paths. A living operating record is more useful than a document dump precisely because it requires more disciplined care.

The case should end with an updated record

When the invoice exception is resolved, the workflow should not leave its reasoning trapped in a chat transcript. The approved decision, evidence, system updates, and unresolved follow-ups should return to the systems that own them.

That closes the loop:

1. connected systems provide knowledge and live state;
2. the agent assembles the evidence required for the decision;
3. policy and human authority determine the permitted action; and
4. the resulting action updates the operating record.

The invoice exception workflow shows this distinction in a bounded business setting. The agent may prepare, reconcile, and complete permitted actions, while material exceptions still move to the accountable person.

Business context is trustworthy when it can explain both what is true now and how the work got there. That is what gives an agent enough understanding to do more than retrieve a document.