Reality Interfaces

The lifecycle does not operate in isolation.

To understand what is true before execution and what became true afterwards, AG Arch needs reliable access to the systems where real state actually lives.

That is the role of Reality Interfaces.

A Reality Interface is the connection between AG Arch and an external system whose state matters to the work.

That system might be:

• a code repository;
• a database;
• a cloud or infrastructure platform;
• an application;
• an API;
• a monitoring system;
• a business system;
• another authoritative source.

The purpose is not to copy the whole outside world into AG Arch.

It is to give governed autonomous work a reliable way to read and interact with relevant reality.

Real systems remain authoritative

AG Arch should not become a second source of truth for systems that already own their state.

If a database owns a customer record, the database remains authoritative.

If a cloud platform determines which service version is actually running, that platform remains authoritative.

If Git contains the current repository state, AG Arch should not replace that state with an internal assumption.

Reality Interfaces allow AG Arch to reach those systems while leaving ownership of the underlying state where it belongs.

This is important because duplicated truth eventually drifts.

AG Arch therefore works around existing systems rather than trying to replace them.

Reality Interfaces support both ends of the lifecycle

Reality Interfaces are important at several points, but two are especially important.

At the beginning of the lifecycle they help establish Current Reality:

What is true before we act?

After execution they support Observe & Prove:

What is true now that the action has happened?

The same system may therefore be consulted before and after execution.

For example, AG Arch may read a configuration before a change, then read the authoritative configuration again afterwards to establish whether the intended state actually exists.

This gives the lifecycle a connection to reality on both sides of the action.

An agent's memory is not a Reality Interface

An agent may remember information from earlier reasoning or from a previous interaction.

That can be useful context.

But remembered information is not automatically current truth.

Suppose an agent previously observed:

Service version 4.2 is running.

If another deployment happens later, that statement may no longer be true.

A Reality Interface allows the system to ask the authoritative environment again.

That distinction prevents stale context from silently becoming execution truth.

Different systems expose reality differently

There is no single universal interface for every kind of work.

A repository exposes different information from a database.

A monitoring system exposes different information from an infrastructure platform.

An API may expose only a narrow part of the state owned by a larger system.

AG Arch therefore does not require every system to look the same.

Instead, Reality Interfaces provide a controlled way to translate the relevant external state into information that the governed lifecycle can use.

The underlying system remains itself.

AG Arch needs only the portion of reality required for the work.

Reading reality and changing reality are different capabilities

Some interfaces may only be needed to observe state.

Others may also provide ways to change it.

Those should not be confused.

Being able to read a production database does not automatically mean the agent should be allowed to modify it.

Being able to inspect infrastructure does not automatically grant deployment authority.

Reality access and execution authority remain separate.

This preserves the principle introduced earlier:

capability is not authority.

A Reality Interface may expose what is possible technically, while the governed mandate determines what the work is actually allowed to do.

Reality needs to be current enough for the decision

External state changes.

Because of that, the value of an observation depends partly on when it was made.

A configuration observed yesterday may not describe the system today.

A health signal recorded before deployment cannot prove that the service remained healthy afterwards.

AG Arch therefore needs to keep the relationship between an observation and the moment in the lifecycle where it was used.

The goal is not to continuously copy every change from every connected system.

It is to make sure important decisions are based on sufficiently current reality.

Multiple systems may describe different parts of the same outcome

Sometimes no single source can prove the whole result.

For example, a repository might show what configuration was committed.

An infrastructure platform might show what version was deployed.

A running service might expose its actual active configuration.

A monitoring system might show whether that service is healthy.

These are not necessarily competing sources of truth.

They may each be authoritative for a different part of the outcome.

AG Arch can use several Reality Interfaces together to build a more complete picture of what actually happened.

Conflicting observations should remain visible

External systems do not always agree.

Suppose Git shows the new configuration, but the running service still reports the old value.

AG Arch should not hide that discrepancy by choosing whichever source makes the task look successful.

The disagreement itself is important information.

It may mean:

• deployment has not completed;
• the wrong environment was changed;
• caching is involved;
• another system overwrote the change;
• the model's assumptions were incomplete.

Reality Interfaces therefore help expose contradictions that autonomous reasoning must then resolve.

Reality Interfaces are not the same as execution tools

The same underlying integration may technically support both reading and writing, but the concepts are different.

A Reality Interface answers questions about the state of the outside world.

An execution capability performs an authorized action on that world.

Keeping those roles conceptually separate makes it easier to reason about:

• what we know;
• where that knowledge came from;
• what we are allowed to change;
• what actually changed afterwards.

Example — changing a system configuration

Continuing the same example:

AG Arch needs to change a configuration used by a running service.

Several Reality Interfaces may be involved.

Before execution:

• the configuration source shows the current value;
• the runtime environment shows which version is active;
• the monitoring system shows the current health state.

After execution:

• the configuration source shows whether the new value exists;
• the running service shows whether it is actually using that value;
• monitoring shows whether the service remains healthy.

AG Arch does not replace any of those systems.

It uses them to establish the reality required by the lifecycle.

If the configuration source says the change exists but the running service still reports the previous value, that contradiction becomes part of the evidence.

The system now knows that the intended outcome is not yet proven.

How Reality Interfaces support AG Arch

Reality Interfaces provide the connection between autonomous reasoning and the world it is reasoning about.

They allow AG Arch to:

ground work in current state;

observe what changed;

collect evidence from authoritative systems;

and

detect when reality no longer matches the plan.

Without them, an autonomous system can reason about what it believes happened.

With them, AG Arch can reason about what the relevant systems actually show.

The next supporting system explains how that reality is combined with the human decisions that define what autonomous work is allowed to pursue: