Solutions · Orchestration
Orchestration of agents and durable processes
Deep dive
An isolated agent can resolve a task. An orchestrated system carries the work through to the result.
On one page
Systems that coordinate agents, software, tools and people through processes that must preserve state, wait, recover and continue to a verifiable result.
- 01Important work usually lasts longer than an answer. An agent can summarise a document, query a database, prepare a proposal or invoke a tool.
- 02A multi-agent architecture adds value when specialisation outweighs coordination. Multi-agent coordination is useful when specialisation, parallelism or independent review outweigh its cost.
- 04Designing the level of autonomy per action. “Autonomous” should not be a global property of the system.
Important work usually lasts longer than an answer
An agent can summarise a document, query a database, prepare a proposal or invoke a tool. But many processes do not end at that step.
The work continues when it is necessary to:
- gather additional information;
- decide between several paths;
- consult different systems;
- wait for an authorisation or an event;
- execute an action;
- respond to a failure;
- resume later;
- check the effect in another system;
- preserve whatever remains pending.
We build architectures that coordinate that journey and maintain a single responsibility for the complete case.
A multi-agent architecture adds value when specialisation outweighs coordination
Multi-agent coordination is useful when specialisation, parallelism or independent review outweigh its cost.
An operation additionally needs:
- a representation of the objective;
- a persistent state;
- tools with contracts and permissions;
- deterministic software for rules and transactions;
- authority policies;
- memory with provenance and retention;
- events, deadlines and recovery;
- designed human intervention;
- evaluation of the path;
- a result signal.
Agents occupy a place within that architecture. They do not replace the rest.
Distributing responsibility without fragmenting the result
Agents
They interpret context, formulate hypotheses, break down work or choose among permitted actions. Their freedom is limited by tools, policies and escalation criteria.
Deterministic software
It applies rules, calculations, validations and transactions that must be reproducible. It also protects invariants that must not depend on a model’s response.
Tools
They connect the reasoning with real data and actions. Every tool declares inputs, outputs, effects, identity, errors and permissions.
Durable workflows
They persist the process, receive events, wait, retry, compensate and resume. They maintain the continuity an agent session cannot guarantee.
People
They contribute context, judgement, negotiation and authority. They can validate an inference, decide a trade-off, approve, correct, stop or redesign a rule.
Orchestration
It preserves the objective and coordinates the transitions. It determines who holds the next responsibility and prevents a component from declaring the work finished merely because it completed its own part.
Designing the level of autonomy per action
“Autonomous” should not be a global property of the system.
A single operation may contain actions at different levels:
- querying without authorisation;
- preparing a proposal;
- recommending a path;
- executing reversible changes within limits;
- requesting authorisation for a sensitive action;
- prohibiting certain tools or effects;
- stopping in the face of contradictory information;
- escalating an unforeseen exception.
This granularity makes it possible to widen the scope where the evidence justifies it and to keep control where the cost of an error demands it.
Preserving state through the real time of the process
A process may last seconds, weeks or months. The design must represent time as part of the work:
- events that have not yet occurred;
- information promised and not received;
- pending authorisations;
- deadlines and expiries;
- dependencies between tasks;
- permitted retries;
- actions that cannot be repeated;
- version changes during the process;
- owners who change;
- questions that remain open.
Persisting the state prevents a person or an agent from having to rebuild the history every time the process resumes.
Recovering without hiding what happened
Failures are part of the operation: an API does not respond, an event arrives twice, a model returns an invalid output, an authorisation expires or an action completes technically without producing the expected effect.
We design routes to:
- validate before acting;
- retry only when it is safe;
- avoid duplicates;
- compensate when an inverse action exists;
- preserve a consistent state;
- escalate with context;
- leave the case explicitly open when it cannot be resolved;
- explain what happened and what remains to be done.
Recovery preserves the evidence of the failure and turns it into information for operating and improving.
Human in the loop without turning the person into an error queue
Human intervention must respond to a specific reason:
- information is missing that only a person can supply;
- an inference needs domain validation;
- there is a trade-off between objectives;
- the action requires authority;
- the situation is new or high-impact;
- the system needs correction or stopping.
The case must arrive with context, an alternative, evidence and consequences. The waiting time, the correction rate and the recurrence of the same handover must also be measured. If a person always resolves the same exception, perhaps the system should learn a rule; if they always approve without reviewing, perhaps the control is badly designed.
Memory with a purpose and a forgetting policy
Preserving context is essential, but storing everything indefinitely is not.
The architecture must distinguish:
- facts of the case;
- decisions and authorisations;
- transient context;
- reusable validated knowledge;
- pending hypotheses;
- sensitive information;
- data subject to expiry or deletion.
Every memory needs a purpose, provenance, access, version and retention. The ability to forget in a controlled way is part of a responsible memory.
Evaluating the complete path
An agent evaluation can measure whether it chose a tool or produced a correct answer. An operational evaluation must add:
- was the result completed?;
- did the state stay consistent?;
- did it recover after a failure?;
- was the action idempotent?;
- did the person receive a useful handover?;
- did the system abstain when it should have?;
- can it be explained why it followed that path?;
- are the cost and the time reasonable?;
- what consequences appeared afterwards?;
- which part should be optimised or redesigned?
The object of the evaluation is not only the model. It is the complete operation.
Where it can be applied
Business operations
Requests and processes that cross ERP, documents, approvals, incidents and auxiliary systems.
Research and knowledge
Specialised agents that search, compare, structure, question and review evidence while preserving questions and provenance.
Reporting and content production
Coordination of data, verification, structure, drafting, review, voice, subtitles and publication.
Complex projects and software development
Work distributed between people and agents, with decisions, dependencies, reviews and resumable execution.
SuperPythagoras is our line of work for this case: it treats people and bots as participants in the same working system and gives them roles, delivery contracts, ordered handovers and review. SecondOpinion adds an independent perspective on every change with consequences, formulated by someone who did not write it, and leaves evidence of what was built and why.
Physical laboratory operations
Coordination between perception, state estimation, planning, control, safety and verification in defined machines and environments.
Orchestrating in order to be able to optimise
When the system preserves states, decisions, times, exceptions and results, it becomes possible to learn where the real complexity lies.
Optimisation can modify:
- the distribution between rules, models, agents and people;
- the order and parallelism of tasks;
- the authorisation or escalation thresholds;
- the selection of tools or models;
- the information prepared for a decision;
- the deadlines, priorities and assignments;
- the way a failure is recovered;
- the level of autonomy of an action.
Orchestration is the structure that makes it possible to observe the work as a system and improve it while preserving responsibility for the complete result.
Where this explanation continues
This page explains durable operations from the client’s problem: what work must be preserved, for how long, with what authority and towards what result.
The technical capability — agents, typed tools, graphs and paths, bounded memory, durable workflows, multi-agent systems, model routing, budgets, stopping criteria and path evaluation — lives in Agents and orchestration.
The general framework of the complete operation lives in Operational intelligence.
What the system must preserve
- 01ObjectiveWhat complete result is being pursued and what conditions allow it to be declared complete, partial or unresolved.
- 02StateWhat is known, what was decided, what was executed, what is pending and who holds the next responsibility.
- 03FunctionsWhat belongs to rules, software, models, agents, optimisation, tools and people.
- 04AuthorityWhich actions are permitted, which require authorisation and who may correct or stop.
- 05Time and eventsHow waits, deadlines, external events, retries and resumptions are handled.
- 06Memory and provenanceWhat context must be preserved, where it comes from and what information must be forgotten or expire.
- 07Result and improvementWhat signal demonstrates the effect and what traces make it possible to evaluate and optimise the path.
Result
An operational architecture that maintains a single view of the case and coordinates reasoning, execution, waits, people and verification.
The level of autonomy can vary by action and evolve with the evidence: from preparing work and recommending, through to executing within defined policies and limits.
When an isolated agent stops being enough
- 01when the work must continue after the conversation
- 02when several applications, agents or teams take part
- 03when some actions are irreversible or need authorisation
- 04when the process waits for events or information for hours or days
- 05when a failure requires the state to be recovered without repeating effects
- 06when the context must be maintained without forwarding it by hand
- 07when the system must explain why it chose a particular path
- 08when the result must be verified in a system different from the one that executed the action
The system from the inside
Maturity · Evaluation- How it is organised
- The process is modelled as a set of states, transitions, tools, policies and roles. Agents interpret and choose within limits; deterministic software executes rules and transactions; the workflow persists, waits and recovers; and people intervene with explicit functions and authority.
- What can be examined
- A complete execution can be examined, along with the state before and after each transition, the available tools, the authorisation policies, the memory preserved, a human intervention, a failure with its recovery and the signal used to close the case.
- How it is checked
- We evaluate complete paths and not only answers: completion, state consistency, recoverability, idempotency, decision quality, percentage and usefulness of escalations, waiting times, cost, traceability and verified effect. We also simulate unavailable tools, duplicated events, contradictory context and changes of model.
Conditions and limits
Orchestration does not correct an ambiguous definition of the result or a non-existent organisational policy. Agents still depend on the quality of their tools, context and evaluation. High-impact actions need permissions, limits and a capacity for intervention proportionate to the risk.