A process can keep moving after the reason for it has changed. Consider an illustrative pricing review. A team prepares a proposal, Finance checks the margin, and a manager approves the change. While those steps are in progress, a supplier announces a higher cost. The proposal may still reach the end of its route, even though the figures behind it need another look.
A well-designed workflow can account for that announcement. It can include a rule that requests another calculation when costs change. The difficulty appears when the relevant situation falls outside the cases its designers anticipated. Someone has to recognise the problem, work out which earlier decisions still apply, and organise the response.
An agentic operating system makes the goal, the current work, and the permitted response explicit enough to coordinate that response. Agents contribute analysis and recommendations within defined tasks. The surrounding system keeps responsibility for what happens next, what needs approval, and how the result is recorded. The benefit depends on those responsibilities being designed and tested together.
Keep the objective separate from the route
The pricing review has a business objective: produce an acceptable price under the company's commercial constraints. Sending a document through a sequence of reviewers is one route towards that objective. Completing the sequence does not, on its own, establish that the proposed price remains acceptable.
A useful goal therefore describes the result sought and the conditions it must satisfy. The team needs to know which products are covered, what information the calculation should use, and which decisions remain with a person. It also needs a way to establish that the work is complete. A vague instruction to improve pricing leaves too much for an agent to infer.
The system can then organise tasks around the objective. One task assesses the cost information. Another examines the commercial effect. A later task prepares a recommendation for the responsible manager. The tasks can follow a familiar route while retaining a connection to the goal that gives them their purpose.
This does not remove the value of fixed sequences. A straightforward calculation or a required check may be best handled by a predictable procedure. The useful change is that the procedure becomes part of a larger account of the work. When an important input changes, the system has a defined place to assess its effect instead of treating arrival at the final step as sufficient evidence of success.
Five capabilities have to work together
The category becomes easier to understand by following what the pricing review needs. These are five broad capabilities, rather than a complete technical layer diagram. Each contributes something the others depend on.
Goal intake captures the objective, relevant facts, and constraints. In the example, it identifies the products under review and what a successful recommendation needs to establish. It should make missing information visible before the work proceeds on an unsupported assumption.
Coordination turns that objective into tasks and manages their relationships. Some work may proceed at the same time; other work must wait for an earlier result. If a task fails or needs a human decision, the process needs to preserve its status and route the next action to the right owner.
Agents carry out defined responsibilities within that process. An agent assessing the financial effect needs the appropriate inputs and must return a result the next task can use. Being able to calculate a price does not give it permission to approve or publish that price. Those are separate responsibilities even when the same model could generate plausible text for all of them.
Controlled access to tools connects the work to business systems. Reading a product record, preparing an update, and committing a change have different consequences. The system must check the permissions and approvals relevant to the actual action before allowing it to proceed.
Shared context carries the relevant facts and decisions between tasks. A reviewer needs to know which cost figures supported a recommendation and whether those figures have changed. Sharing context also requires access restrictions; every participant does not need every record in the company.
Respond to a change without losing the earlier work
Return to the supplier's cost announcement. The important first step is to establish what it affects. A change covering one product should not be assumed to invalidate every calculation. A change with an uncertain effective date may require clarification before the team can recommend a new price.
In a system designed for this situation, the announcement can start a reassessment task. That task compares the new information with the assumptions used in the current recommendation. Its result identifies what needs to be revisited. The coordination process can then organise the affected work and preserve the decisions that remain valid.
The permission to respond still needs limits. The system might be allowed to recalculate and prepare a revised recommendation, while a manager retains the pricing decision. If the new cost makes the goal impossible under the existing constraints, that conflict needs to reach the person who can change them. An agent should not quietly relax a margin requirement to make its task appear complete.
The earlier work also needs to remain identifiable. A later reviewer should be able to establish which recommendation was based on the old cost and which used the new one. Otherwise, an approval can become attached to the wrong version even when each individual participant acted reasonably.
Adapting the work means revisiting the right decisions under the same controls. It requires a known response to a relevant change. Giving an agent a broad instruction to handle exceptions supplies neither the response nor evidence that it will respect the limits.
People retain the decisions that belong to them
A goal can include a clear commercial constraint and still require judgment. The company may accept a lower margin to protect an important customer relationship. It may delay a price change while a supplier dispute is resolved. These choices belong to people with responsibility for the business.
A coordinated system helps by preparing the evidence and locating the decision. It can bring together the current cost, the recommendation, and the effect of the available options. The responsible person can then decide with a clearer account of what has changed and what their answer will permit.
That answer must travel with the work. Approval of a temporary price for one customer should not become approval of a permanent change for every customer. The decision needs enough detail for the next task to apply it correctly. Human involvement provides little protection if the system records only an undifferentiated approval.
The system also needs a route for cases outside its defined scope. Returning an unresolved issue to a person is appropriate when that person must make the decision. The improvement lies in preserving context and ownership, so the person can deal with the issue rather than rebuild the history before starting.
Keep a record that supports an explanation
After a price is changed, the business may need to understand why it was chosen. The current product record gives only the result. A useful explanation also needs the inputs, recommendations, approvals, and action that produced it.
The record must connect the decisions to the work they authorised. If the approved price and the published price differ, the investigation should be able to locate that difference. If the recommendation used outdated costs, the review should be able to establish which information was available and how it entered the calculation.
This requirement is more demanding than retaining a conversation. The conversation may explain part of a recommendation, while the final update occurred in another system. The records need to remain connected across that boundary. Missing evidence should be reported as missing evidence, rather than filled with a convincing explanation after the event.
An agent's stated reason also has limits. It is something to examine alongside the inputs and outputs, not a complete account of every internal operation of a model. The useful business explanation follows the recorded process: what information was used, what checks occurred, who authorised the action, and what the external system recorded.
Build the shared work once, then test each use
The same coordination needs appear outside pricing. A supplier review and a customer-service case also require task ownership, controlled actions, context, and a record of the outcome. Their business questions differ, while much of the machinery for carrying work between participants can be shared.
That is the operating-system idea in this category. The common part provides services that business capabilities can use consistently. Each business area supplies its own rules, information, and tasks. A reusable design makes it possible to improve the shared handling of approvals or failures without building an unrelated mechanism for every process.
There is a maintenance cost. The shared services need clear interfaces, and each business use still needs testing. A reusable approval mechanism cannot decide whether a particular pricing rule is commercially sound. It can provide a consistent way to apply the rule and preserve the resulting decision.
The pricing example gives a practical standard for evaluating such a system. Follow the changed cost through reassessment, review, and the final update. Check that the right work is revisited, that the decision remains with its owner, and that the result can be explained afterwards. The next post, Introducing Synedrix OS: the governed operating layer for agentic business, introduces a platform architecture organised around those responsibilities.
Related reading
- Why AI assistants don't solve the coordination problem — establishes the work a shared coordination process needs to carry beyond individual tasks.
- Next in the series: Introducing Synedrix OS: the governed operating layer for agentic business — introduces a platform architecture for these shared responsibilities.
Documentation
- Technical Platform Thesis: the coordination, control, and context responsibilities behind the category.
- Agentic Enterprise Manifesto Outline: the division between repetitive coordination and retained human judgment.
Synedrix OS — operating substrate
