Reroute

AG Arch uses Reroute when the governed work is still valid, but the current capability is not the right one to continue it.

The key distinction is:

the goal stays the same;

the mandate stays the same;

the capability changes.

Rerouting allows AG Arch to move work between agents, models, specialists, tools, or execution environments without redefining what the work is trying to achieve.

Why rerouting is needed

The capability selected earlier may become unsuitable for several reasons.

For example:

• it does not have the required specialist knowledge;
• it lacks access to a necessary tool;
• it cannot operate in the required environment;
• another capability is better suited to the newly discovered problem;
• the current capability fails while another authorized option exists;
• the next part of the task requires a different type of expertise.

AG Arch uses that information to select another suitable capability from the Capability Pool.

The work continues, but the executor changes.

Reroute preserves the governed mandate

Rerouting does not create a new task.

AG Arch carries the existing governed work into the new handoff, including:

• intent;
• current relevant context;
• success criteria;
• scope;
• mandate;
• constraints;
• proof requirements;
• relevant execution history and evidence.

The receiving capability therefore does not receive only:

“Continue this task.”

It receives enough governed context to understand what it is being asked to do and within which boundaries.

A more capable agent does not receive more authority

Suppose AG Arch reroutes work from a general-purpose agent to a specialist with much broader technical access.

The specialist may be capable of changing more systems.

That does not mean the mandate becomes broader.

If the work is authorized to modify only Service A, the new capability remains limited to Service A even if it can technically administer the entire environment.

Reroute changes:

who or what performs the work.

It does not change:

what the work is permitted to do.

If broader authority is actually required, AG Arch uses Re-authorize, not Reroute.

Rerouting can happen between different kinds of capabilities

The new destination does not have to be another AI agent.

AG Arch may reroute work between:

• general-purpose agents;
• specialist agents;
• different models;
• dedicated tools;
• services;
• execution environments;
• combinations of those capabilities.

For example, one agent may identify that an infrastructure problem exists but lack the execution environment needed to correct it.

AG Arch can hand the governed work to an infrastructure capability that has the appropriate tools.

The lifecycle remains the same even though the executor changes.

Reroute can also split work by specialization

A task may require several different capabilities.

AG Arch does not need to force one agent to perform every part.

For example:

• one capability may inspect application code;
• another may analyse infrastructure;
• another may perform the controlled change;
• another may collect verification evidence.

Those handoffs can all remain connected to the same governed outcome.

This allows AG Arch to use specialization without losing continuity.

AG Arch selects the next capability from the needs of the work

Rerouting is not simply:

“Try another agent.”

AG Arch already knows why the current capability cannot continue.

It can use that reason when selecting the replacement.

For example, the next capability may need:

• a particular skill;
• access to a particular environment;
• a particular tool;
• the ability to perform a specific side effect;
• the ability to generate the required evidence.

This turns rerouting into a capability-matching decision rather than a blind retry.

Reroute preserves traceability

When AG Arch changes capabilities, it records the transition as part of the task history.

The system can therefore retain:

• which capability originally handled the work;
• why it could not continue;
• which capability received it next;
• which mandate was transferred;
• what happened after the handoff.

This is important because a verified outcome may eventually depend on work performed by several different capabilities.

The final result should still remain connected to one governed lifecycle.

Reroute is different from Replan

These two paths can also overlap, but they solve different problems.

Suppose the planned action is correct, but the current agent cannot perform it.

AG Arch uses Reroute.

Suppose the current agent is fully capable, but evidence shows that the planned action itself is wrong.

AG Arch uses Replan.

In short:

Replan changes the route.

Reroute changes the capability travelling that route.

Sometimes both are needed: AG Arch may first revise the plan and then route the revised work to a different capability.

Reroute is different from Re-authorize

A capability problem is not an authority problem.

If the task is already permitted to perform an action but the current capability cannot do it, AG Arch can reroute.

If the capability can perform the action but the governed mandate does not permit it, AG Arch must re-authorize.

This keeps three different recovery questions separate:

Is the plan right? → Replan

Is the action authorized? → Re-authorize

Do we have the right capability? → Reroute

Example — changing a system configuration

Continuing the same example:

AG Arch has established that the running service needs an authorized reload before it can use the new configuration.

The existing mandate already permits that reload.

However, the capability that changed the configuration cannot control the service runtime.

The problem is therefore not the plan.

It is not Human Authority.

It is the capability.

AG Arch selects Reroute.

The governed work is handed to an infrastructure capability that can perform the reload.

The handoff retains:

• the intended outcome;
• the current configuration state;
• the existing mandate;
• the service-health constraint;
• the proof requirements.

The infrastructure capability performs the authorized action.

AG Arch then returns to observation and verification to determine whether the service now uses the approved configuration.

What Reroute changes

Reroute changes:

the capability responsible for the next part of the work.

It preserves:

the intent;

the governed mandate;

the success criteria;

and

the required proof.

If AG Arch cannot find any suitable capability that can continue safely and within the existing authority, rerouting is no longer sufficient.

The remaining recovery path is: