4. Handoff & Route

Once the plan, authority, constraints, and proof requirements are defined, AG Arch has to decide who or what should perform the work.

That may be:

• a particular agent;
• a specialist;
• a model;
• a tool;
• a service;
• another execution environment.

This stage is about transferring governed work to an appropriate capability without losing the rules established earlier.

Handoff is more than passing a task description

In ordinary automation, a handoff can be as simple as:

“Agent B, do this.”

For governed autonomous work, that is not enough.

The receiving capability needs to understand not only the task, but also the important context around it:

• what outcome is required;
• what scope applies;
• what authority exists;
• what constraints must remain intact;
• what proof is expected;
• when it must stop rather than continue.

AG Arch therefore treats a handoff as a transfer of a governed mandate, not merely a message.

The work may move, but its boundaries should move with it.

Routing chooses capability for the work

Different capabilities are good at different things.

One agent may be better suited to planning.

Another may specialize in code changes.

Another may inspect infrastructure.

A particular tool may be the only appropriate way to perform one operation.

AG Arch therefore needs a routing layer that can match the work to a suitable capability.

The important point is that routing should be based on the needs of the work, rather than simply using whatever agent happens to be available.

That can include factors such as:

• the kind of task;
• required skills;
• available tools;
• execution environment;
• authority boundaries;
• specialist knowledge;
• safety requirements.

Routing does not grant new authority

This is one of the most important rules in the stage.

Suppose the original work is authorized to modify one application.

AG Arch routes part of that work to a more capable specialist.

That specialist does not gain permission to modify a second application simply because it has the technical capability to do so.

Routing changes who performs the work.

It does not automatically change what the work is allowed to do.

The receiving capability remains inside the governed mandate established earlier.

The best capability may change during the work

The first capability selected does not always have to finish everything.

During execution it may become clear that:

• another specialist is required;
• a different tool is more appropriate;
• the current capability cannot safely continue;
• part of the work should be delegated;
• the task should return to planning instead.

AG Arch therefore allows work to move between capabilities.

But each transition should remain traceable.

The system should be able to answer:

What was handed off?

Why was it handed off?

Who received it?

What authority and constraints followed it?

What happened next?

A handoff should not erase accountability

Multi-agent systems can become difficult to understand when one agent delegates to another, which delegates again, and the original task disappears into a chain of internal messages.

AG Arch should avoid that.

A handoff needs enough identity and traceability to connect later actions and evidence back to the governed work that caused them.

This is especially important when several specialists contribute to one final outcome.

The question should never become:

“Which agent said it was done?”

The important question remains:

“Can the resulting work still be traced back to the original intent, authority, success criteria, and evidence requirements?”

Handoff can also mean “do not continue here”

Routing is not always a decision to proceed with another agent.

The correct outcome can also be:

• return the work for replanning;
• pause because required authority is missing;
• stop because no suitable capability exists;
• fail safely rather than improvise.

That is important because routing should not become a mechanism for bypassing governance.

If one capability is not allowed to perform an action, simply finding another capability that technically can perform it does not solve the authority problem.

Example — changing a system configuration

Continuing the same example:

AG Arch has already established:

• the intended outcome;
• current reality;
• success criteria;
• the plan;
• allowed scope;
• constraints;
• required proof.

Now the work needs an execution capability.

Suppose one agent is strong at planning and repository analysis, while another specialist is equipped to perform infrastructure configuration changes.

AG Arch may route the execution step to the infrastructure specialist.

The handoff should carry the important mandate:

• change only the relevant configuration;
• operate only in the authorized environment;
• preserve unrelated settings;
• respect the defined stop conditions;
• return the evidence required for later verification.

The infrastructure specialist receives the capability to perform the work, but not permission to redefine the outcome or expand the scope.

If it discovers that the required change actually belongs to another system outside its authority, it should not simply continue there.

The work must be routed back through the appropriate governance path.

What this stage gives to the next one

At the end of Handoff & Route, AG Arch has selected an appropriate capability and transferred the governed work without losing its:

intent;

scope;

authority;

constraints;

and

proof requirements.

The next stage is where that capability actually performs the authorized work.

That is 5. Execute.