Prompting and orchestration solve different problems

Prompting matters. Clear goals, useful context, good instructions, output shaping, refinement, and verification make individual AI interactions better.

But real work often requires more than one interaction.

A report may need research, planning, drafting, review, fact checking, revision, approval, and final delivery. A technical project may need requirements, implementation, tests, verification, documentation, and a release decision. A ministry or administrative project may involve sensitive information, multiple reviewers, and decisions that must stay human.

One prompt can contribute to that work. It is not the entire work system.

Orchestration starts with purpose

Before assigning roles to AI, someone must decide what the work is for.

That human owner defines:

  • the desired outcome;
  • the boundaries;
  • what evidence matters;
  • which risks are unacceptable;
  • what may be delegated;
  • what requires review;
  • who can approve the final result.

If the purpose is unclear, adding more agents or tools can make the confusion move faster.

Give roles boundaries, not just names

An orchestration system may use different AI roles—for example, researcher, planner, drafter, reviewer, or verifier.

The useful part is not the label. The useful part is the boundary.

A bounded role should make clear:

  • what task it owns;
  • what inputs it may use;
  • what output it must produce;
  • what it must not decide;
  • when it should stop;
  • where the work goes next.

This makes the work reviewable.

Handoffs carry accountability

In ordinary teamwork, a poor handoff creates confusion. The same is true in AI-assisted work.

A good handoff should preserve what the next role needs to know:

  • the current artifact;
  • the purpose;
  • the evidence or sources used;
  • unresolved questions;
  • known risks;
  • acceptance criteria;
  • what has and has not been approved.

Without that information, each new AI step may reconstruct the task from incomplete context and introduce drift.

Verification should be designed into the workflow

A common mistake is to produce the whole deliverable and ask AI—or a person—to "check it" at the end.

That can help, but stronger workflows decide in advance where verification belongs.

Research claims may be checked before drafting. Calculations may be independently recomputed. A reviewer may compare the work against requirements. A human may examine unresolved contradictions before allowing the process to continue.

Verification becomes a structural part of the workflow rather than an afterthought.

Documentation is not bureaucracy when it preserves decisions

For complex AI-assisted work, documentation answers questions such as:

  • What was the AI asked to do?
  • Which artifact did the next role receive?
  • What source supported an important claim?
  • What changed during review?
  • What uncertainty remains?
  • Who approved the final action?

You do not need a massive record for every low-stakes task. The documentation should be proportional to the work. But if a decision matters, the evidence and approval should not vanish inside a chat window.

Escalation is a feature

A well-designed workflow knows when AI should stop and ask for human judgment.

Possible escalation triggers include:

  • conflicting evidence;
  • missing required information;
  • uncertainty above an accepted threshold;
  • a request outside the role's authority;
  • sensitive data;
  • a high-consequence decision;
  • a policy or values question;
  • an irreversible action.

An AI role that always produces an answer is not necessarily more useful than one that knows when the work is not ready to proceed.

Human approval closes the loop

Book 4's human-governed approach does not treat orchestration as a way to remove people from responsibility.

The future of responsible AI work is not simply "more autonomy." It is better structure around purpose, delegation, verification, documentation, escalation, and approval.

The human owner remains responsible for what the system is trying to accomplish and for the final decisions that properly belong to a person.

A simple orchestration pattern

You can practice orchestration even without specialized software:

  1. Owner: define the task, boundaries, evidence needs, and final approval criteria.
  2. Planner: break the work into stages and identify dependencies.
  3. Researcher: gather or organize source material within defined limits.
  4. Drafter: create the first deliverable from approved inputs.
  5. Reviewer/verifier: test the work against claims, requirements, and risks.
  6. Reviser: make bounded corrections with a clear change record.
  7. Human approver: decide whether the work is acceptable for real-world use.

The roles can be performed manually through separate prompts or implemented in more technical systems. The governance logic remains the important part.