How is an operation shared between agents, deterministic software and people without losing a single point of responsibility?

Why it matters

A process can share work out between several specialised agents, deterministic services, tools, applications and people. That specialisation improves clarity and makes it possible to use each capability where it is appropriate.

It also introduces a risk: that the result becomes fragmented. The research agent considers itself finished once it has delivered information; the tool, once it has accepted a call; the ERP, once it has recorded a change; and the person, once they have approved a proposal. Nobody necessarily keeps responsibility for checking that the complete effect took place.

In a distributed system, responsibility does not appear by adding components together. It has to be designed.

What we know so far

It helps to distinguish responsibility from execution.

Each component needs a contract covering:

• its function;
• inputs and outputs;
• the information and state it may modify;
• permissions and identity;
• errors and retry conditions;
• the evidence it has to produce;
• the criterion by which it is considered complete;
• the next party responsible.

Above those contracts, the process needs a single representation of the objective and of the state. The orchestrator does not have to take every decision, but it does have to keep:

• which result is being pursued;
• which parts were completed;
• which decisions and authorisations exist;
• which dependencies are still open;
• which signal confirms the effect;
• who has to intervene next.

Authority also has to be separated action by action. An agent can propose; a rule can validate; a person can authorise; a tool can execute; and the system can check. The organisational responsibility for allowing that journey cannot be delegated to the model.

What remains open

It remains open how to keep a single point of responsibility when the process crosses organisations with different policies and different systems of record.

Also how to reassign it when the topology of the system changes dynamically, a model is replaced, a new tool appears or an agent delegates part of the work to another.

And how to offer useful explanations without reconstructing a retrospective narrative that oversimplifies distributed decisions or turns the trace into a false sense of causality.