5. Execute

At this point, AG Arch has established the intent, current reality, success criteria, plan, authority, constraints, proof requirements, and the capability that will perform the work.

Now the system can act.

Execute is the stage where the governed plan becomes a real change in the outside world.

That may mean:

• changing code;
• updating configuration;
• calling an API;
• modifying infrastructure;
• creating or updating data;
• publishing something;
• invoking another system;
• performing another authorized action.

But execution in AG Arch is not simply “let the agent do whatever it thinks is necessary.”

It is controlled action inside the mandate established by the previous stages.

Execution happens inside boundaries

The executing capability receives room to reason and act, but that freedom exists inside defined limits.

Those limits include:

• the intended scope;
• granted authority;
• applicable constraints;
• stop conditions;
• required proof.

The agent may choose between different valid ways of accomplishing the work without requiring a person to specify every individual step.

But it should not silently change what the task means.

If the mandate is to update one configuration setting, execution should not expand into an unrelated redesign simply because the agent believes that would be better.

Autonomy exists inside the governed boundary.

The plan guides execution, but reality still matters

Execution does not mean blindly following the original plan.

The environment may have changed since the plan was created.

A dependency may no longer be available.

A previous action may have produced an unexpected state.

Another process may have changed the same system.

The executing capability therefore needs to remain aware of current conditions.

If the new situation still fits within the existing authority and constraints, it may be possible to adapt and continue.

If continuing would require changing the mandate, exceeding authority, or violating an important condition, execution should stop and move into the appropriate recovery path.

A good autonomous system does not become less governed when something unexpected happens.

That is when governance matters most.

Controlled action is not the same as rigid action

“Controlled” does not mean that every action must have been written down in advance.

That would turn AG Arch into a traditional workflow engine rather than an autonomous execution system.

Instead, control comes from knowing:

what outcome is being pursued;

what the capability is allowed to do;

what it must not do;

and

what conditions require it to stop.

Within those boundaries, the agent can still reason, select tools, adjust its approach, and perform multiple actions.

The goal is not to remove agent judgment.

The goal is to prevent that judgment from silently becoming unlimited authority.

Execution may contain many actions

A single governed task can require more than one operation.

For example, changing a service configuration may involve:

1. reading the current configuration; 2. preparing a modification; 3. validating the proposed change; 4. writing the new value; 5. restarting or reloading the service; 6. checking the immediate response.

These actions may all belong to one execution stage.

AG Arch does not need to treat every tool call as a separate lifecycle.

What matters is that the actions remain connected to the same governed work and that the system can trace what happened.

Side effects matter

Some actions only inspect reality.

Others change reality.

That distinction is important.

Reading a configuration file and changing that configuration file are not equivalent operations. Neither are preparing a deployment and publishing it to production.

Actions that create external effects can require stronger controls because they may affect real systems, users, data, or infrastructure.

AG Arch therefore needs to preserve the authority boundary around side-effecting actions rather than assuming that access to a tool is sufficient permission to use every capability it provides.

Execution should leave a trace

If autonomous work changes a real system, it should be possible to reconstruct what happened.

That does not mean recording every internal reasoning token.

It means preserving meaningful execution facts such as:

• which governed work caused the action;
• which capability performed it;
• which relevant action occurred;
• what system or resource was affected;
• what execution state followed.

This trace later helps connect the action to observation and evidence.

Without it, multi-step autonomous work quickly becomes difficult to audit.

A successful action is still not a successful outcome

This is the most important distinction in the Execute stage.

A tool may return:

Success.

A command may exit with code `0`.

An API may return `200 OK`.

A deployment may finish without reporting an error.

Those facts tell us something about the action.

They do not necessarily prove the outcome.

The new configuration may not actually be active.

The application may fail after deployment.

The API may have changed the wrong resource.

The system may appear healthy immediately and fail moments later.

AG Arch therefore does not end the lifecycle when execution reports success.

Action ≠ outcome.

Execution produces a changed or attempted state.

The next stages determine what actually happened.

Failure during execution does not always mean the whole task is finished

An individual action can fail while the governed work still has a valid path forward.

For example:

• one tool may be temporarily unavailable;
• one execution method may fail while another authorized method exists;
• a transient problem may permit a bounded retry;
• another capability may be better suited to continue.

If the alternative remains inside the existing mandate, the system may be able to recover autonomously.

But execution should not turn failure into permission to ignore the original boundaries.

A failed method does not authorize an unsafe one.

Example — changing a system configuration

Continuing the same example:

AG Arch has routed the governed work to a capability authorized to change the configuration.

The capability reads the current state and confirms that the assumptions required for execution still hold.

It then:

1. applies the approved configuration change; 2. performs any authorized reload or restart needed for the change to take effect; 3. records the relevant execution result.

Suppose the tool reports:

Configuration updated successfully.

That is useful information.

But AG Arch does not yet declare the task complete.

The command proves that the configuration operation was accepted.

It does not prove that:

• the running service is actually using the new value;
• the service is healthy;
• unrelated settings remained unchanged;
• the intended outcome has been achieved.

Those questions belong to the next stage.

What this stage gives to the next one

At the end of Execute, one or more controlled actions have taken place in the real environment.

AG Arch now has to determine:

What actually changed?

What state exists now?

What evidence can be collected?

and

Does reality support the result we intended to achieve?

That is the purpose of 6. Observe & Prove.