Orchestration

The loop

Every non-trivial request goes through the same four-step loop. Sovereign exposes the loop. Customers can intervene at any step. The plan is the contract.

1. Decompose. Take the goal. Break it into explicit sub-goals. Surface the plan when scope warrants. Execute silently when trivial.
2. Dispatch. Route each step to the right place. Sometimes that's the main agent. Sometimes a sub-agent. Sometimes a scheduled job. Sometimes a person.
3. Reflect. Before declaring done, run up to three reflection cycles. Stop early if a cycle has nothing to fix.
4. Declare done. Only after reflection. State what was verified and how. Surface any residual risk.

Why this shape

A chatbot will tell you what it did. An orchestrated agent will tell you what it verified, what it didn't, and what it left for you. The difference is whether you trust the output enough to act on it.

We arrived at four steps by deleting things. Plans without dispatch are just diagrams. Dispatch without reflection produces confidently-wrong output. Reflection without declared termination loops forever. Each step removes a specific failure mode.

1. Decompose

Decomposition is where the agent decides what counts as the actual goal. The user said "send the Q3 brief to Ryan." The agent reads that as: assemble the data for the Q3 brief, format it to match prior briefs, draft the email to Ryan, gate the send on approval, schedule a follow-up check if no reply lands in five days.

Surface the plan to the user before any side effect. Skip the surface for trivial requests — you don't need a plan for "what time is it." Use judgment.

2. Dispatch

Dispatch routes the work. Five places the agent can send a step:

• Itself. The agent runs the step inline using its tools and skills.
• A sub-agent. Spawn a clean child session for long-form or parallel work. The child reports back.
• A scheduled job. For work that needs to recur or fire at a future time.
• An external system. A connected integration. A webhook. A managed service.
• A human. When judgment, approval, or a decision is required.

Cheap, deterministic work goes to the cheapest channel that can do it. A pure script gets a scheduled job. A document classification gets a quick LLM call. A draft of customer-facing copy gets the most capable model you've configured. Spending discipline is part of orchestration, not separate from it.

3. Reflect

Up to three cycles. Each cycle asks a specific question.

• Cycle 1. Did I solve the actual problem, or only the surface symptom?
• Cycle 2. Is my verification real? Did I pull from the system of record, or did I trust a self-report from a sub-agent or a tool?
• Cycle 3. What did I miss? Edge cases. Downstream impact. New debt I created.

Stop early if a cycle finds nothing to fix. Three is a ceiling, not a target.

4. Declare done

Done means: the work is finished, the verification is named, the artifact is durable, and any residual risk is surfaced. Done does not mean: the agent said it did the work.

On consequential operations — journal entries, customer-facing sends, bulk data changes — the agent must verify against the system of record before declaring done. Sub-agent self-reports do not count. Re-fetch the journal entry by id. Re-pull the campaign by id. Sample five rows of the sheet. Then declare.

k-vote: quality gates before output ships

Before any consequential output reaches a human or an external system, the agent runs a k-vote: it generates k independent completions for the same task, scores them against the rubric for that skill, and either accepts the consensus answer or flags the divergence for a reflection cycle. One generation, no vote — that's a chatbot. k generations, scored, with divergence detection — that's a quality gate.

k-vote is applied selectively — on tasks where the cost of a wrong answer is high: client-facing copy, financial entries, lead classification decisions, bulk data operations. It is not applied to every turn (that would be expensive and slow). It is applied where it matters, with k calibrated to the consequence level of the task.

What divergence tells you

When k completions disagree, the divergence is the signal. It means the task is genuinely ambiguous, the context is incomplete, or the rubric needs updating. The agent surfaces the disagreement to the operator rather than picking a winner arbitrarily. That surface moment is a learning event — the operator's resolution updates the rubric for the next run.

k-vote + reflection cycles = the quality loop

k-vote fires on generation. Reflection cycles fire on completion. Together they form a closed quality loop: the agent checks its work before shipping it (k-vote), then checks that the shipped work matches intent (reflection), then verifies against the system of record (declare done). Three layers, each catching a different failure mode.

Approval gates

Reflection is automated. Consequential decisions stay human. By default, no client-facing email is sent. Drafts only, always. Journal entries are described before they post. Campaign changes are presented before they ship. Pricing changes require sign-off.

Gates can be tightened with rubrics and team roles. They can be loosened thread-by-thread once a specific agent has earned the trust. You choose where the lines sit.

Memory is the substrate

What lets the loop work across days is the agent's memory. Skills, memories, and rubrics are the durable record of what the agent has been taught and what it has learned. Conversation history is ephemeral. What matters gets written down.

That is the deal. The agent writes things down. You review them. You accept the ones worth keeping. Over time the agent becomes specifically good at your work, not generically good at all work.

---

← Back to Docs