3. Plan & Govern

Once AG Arch understands the current situation and knows what a successful outcome should look like, it can decide how the work may proceed.

This stage combines two questions:

What is the plan?

and

Under what authority may that plan be carried out?

Those questions belong together. A plan without governance may describe useful actions but not whether they are permitted. Governance without a plan defines boundaries but not a route toward the intended outcome.

AG Arch therefore treats planning and governance as one connected stage.

The plan describes a route, not every movement

Autonomous systems are useful because they can decide how to perform work.

AG Arch does not require a person to prescribe every command, file change, API call, or reasoning step in advance. Instead, the plan establishes a bounded route from the current state toward the defined outcome.

It may identify:

• what needs to change;
• which systems or resources are involved;
• important dependencies;
• what needs to be checked before proceeding;
• when the work should stop or reconsider its path;
• what evidence will be needed when the work is complete.

The purpose of the plan is not to replace autonomous reasoning. It gives that reasoning a controlled context.

Capability is not authority

An agent may technically be capable of editing a repository, calling an API, changing infrastructure, publishing content, or modifying data.

But technical capability does not automatically mean permission.

Capability answers: “Can this system perform the action?”

Authority answers: “Is it allowed to perform this action here, for this purpose, under these conditions?”

This distinction is fundamental to AG Arch.

A powerful agent can remain useful without automatically receiving unrestricted control over every system it can access.

Authority can be bounded in advance

For routine work, AG Arch should not require a person to approve every individual action.

Instead, authority can be established before execution begins.

An agent may be authorized to modify configuration within one application, run validation, and prepare a deployment. That does not automatically authorize it to modify unrelated systems, delete production data, bypass safety controls, or change the architecture of the project.

Within the defined boundary, autonomy should continue.

Outside it, the system needs a different decision.

Constraints define the boundaries of valid execution

Authority says what the system may do.

Constraints describe conditions the work must continue to respect.

They may come from:

• task scope;
• security rules;
• technical architecture;
• organizational policy;
• environment state;
• safety requirements;
• dependencies;
• explicit limitations.

Some constraints are absolute:

Do not modify production data.

Others apply only under certain conditions:

Publishing is allowed only after the required verification succeeds.

The agent should not have to invent these boundaries while it is already acting. They should be part of the governed context from the start.

Different actions can require different levels of authority

Not every action carries the same risk.

Reading system state is different from deleting information. Preparing a change is different from publishing it. Running a reversible test is different from making an irreversible production decision.

A governed environment can therefore distinguish between actions that are:

• allowed;
• not allowed;
• allowed only when additional approval or authority exists.

This avoids two bad extremes: unrestricted autonomy on one side and constant human confirmation on the other.

Routine work should remain autonomous when its boundaries are already clear. Human authority should be reserved for decisions where it is genuinely required.

Stop conditions are part of the plan

A good plan also defines when continuing would be wrong.

Execution may need to stop if:

• current reality no longer matches an important assumption;
• a required system becomes unavailable;
• the next action falls outside granted authority;
• a safety condition is violated;
• required evidence cannot be produced;
• the work would need to expand beyond the agreed scope.

Stopping is not necessarily failure.

It may simply mean the system has reached a boundary and should move into an appropriate recovery path instead of improvising beyond its authority.

Proof requirements are decided before the result is known

The previous stage defined what success means.

Plan & Govern also establishes what proof will be required to support that conclusion.

Evidence should not be chosen only after the system sees the result.

If success means:

The approved configuration is active and the service remains healthy,

then the plan may require evidence of both:

• the configuration that is actually active;
• the health of the running service after the change.

A successful command alone would not satisfy those proof requirements.

This is what links planning to the later verification stages.

The plan can change, but not silently

Real systems change.

New information can appear, assumptions can become invalid, and a safer route may become necessary.

AG Arch must allow the system to adapt.

But there is a difference between adaptation and silent scope drift.

If the new route still fits inside the existing authority, constraints, and success criteria, the system may continue autonomously.

If it requires different authority, expands the scope, or invalidates an important condition, the governing state must change too.

The system should not quietly expand its own mandate simply because doing so would make the task easier.

Governance follows the work, not a particular agent

The same governed work may involve different agents, models, tools, or services.

Changing the capability performing the work should not automatically change:

• the intended outcome;
• the allowed scope;
• the constraints;
• the required proof.

Those boundaries belong to the work itself.

This is what later allows AG Arch to route execution to different capabilities without losing governance.

Example — changing a system configuration

Continuing the same example:

The intent is to make the running service use the approved configuration.

The current reality is known, and success has already been defined.

A simplified governed plan could be:

1. identify the authoritative configuration source; 2. determine the required change; 3. apply it through an authorized mechanism; 4. observe the resulting system state; 5. verify the active value and service health.

The agent may be allowed to:

• read the configuration;
• modify the relevant setting;
• run validation;
• restart the affected service if authorized.

But it may not be allowed to:

• change unrelated configuration;
• modify another environment;
• disable safety controls;
• make an unrelated architectural change.

The required proof may include:

• evidence of the active configuration after the change;
• evidence that the service remains healthy;
• confirmation that protected settings remain unchanged.

Suppose the agent discovers that completing the work would require modifying another production system outside the authorized scope.

The correct response is not:

“I can technically do that, so I will.”

The plan has reached its authority boundary.

AG Arch should route the work through the appropriate next decision rather than silently expanding the task.

What this stage gives to the next one

At the end of Plan & Govern, the system knows:

what route is planned;

what the work is allowed to do;

what boundaries must remain intact;

when execution must stop or reconsider;

and

what proof will ultimately be required.

The next question is:

Which capability should receive this governed work and carry it forward?

That is the purpose of 4. Handoff & Route.