Capability Pool

AG Arch does not assume that one agent, model, or tool should perform every kind of work.

Different tasks require different capabilities.

A Capability Pool is the set of agents, models, specialists, tools, and execution systems that AG Arch can draw from when work needs to be performed.

The purpose is not simply to have many tools available.

The purpose is to make those capabilities identifiable, selectable, and routable so the system can choose an appropriate capability for a particular piece of governed work.

A capability is something the system can use

A capability may take many forms.

For example:

• a general-purpose reasoning model;
• a coding agent;
• an infrastructure specialist;
• a domain specialist;
• a browser or research tool;
• a repository tool;
• a deployment system;
• a validation tool;
• another external service.

These capabilities do not all need to work in the same way.

What matters is that AG Arch can understand enough about them to decide when they are appropriate.

The current AG Arch core already has a `SkillRegistry` whose purpose is to register capabilities for orchestrator selection and observability, as well as a catalog for specialist packs connected to that registry.

Capability is not a fixed agent identity

It is useful to think about the ability required by the work, rather than immediately asking which named agent should perform it.

For example, a task may require:

inspect infrastructure state and safely modify a service configuration.

The important requirement is the capability.

Today that capability might be provided by one specialist agent.

Later it might be provided by:

• another agent;
• a different model;
• a dedicated service;
• a combination of tools;
• a newer implementation.

The governed lifecycle should not need to be redesigned simply because the provider of the capability changes.

This is one reason AG Arch separates governance of the work from the capability used to perform it.

Capabilities can be specialized

A general-purpose agent can perform many tasks, but specialization can improve both reliability and control.

A specialist can carry:

• domain knowledge;
• task-specific procedures;
• appropriate tools;
• relevant validation methods;
• known boundaries for its kind of work.

For example, changing infrastructure and analysing marketing content may both involve autonomous reasoning, but they require very different expertise and tools.

AG Arch can therefore route work toward specialist capabilities instead of forcing every task through one universal agent.

Routing should match capability to need

The Capability Pool supports the Handoff & Route stage of the lifecycle.

When governed work is ready to be executed, AG Arch can consider what the work requires and select a suitable capability.

That selection may depend on factors such as:

• type of task;
• required specialist knowledge;
• available tools;
• environment;
• side effects involved;
• validation requirements;
• ability to produce the required evidence.

The question is not simply:

Which agent is available?

It is:

Which available capability is appropriate for this governed work?

More capable does not mean more authorized

A capability may technically be able to perform actions that the current work is not allowed to perform.

That does not expand the mandate.

A specialist capable of managing an entire cloud environment may receive a task whose mandate allows it to change only one service.

A coding agent may have access to an entire repository while the work concerns only one bounded change.

The Capability Pool describes what the system can potentially use.

The governed mandate still determines what it may actually do in this task.

This preserves the distinction:

Human Authority → Governed Mandate → Selected Capability → Autonomous Execution

One task may use several capabilities

Complex work does not necessarily belong to one agent from beginning to end.

For example:

• one capability may investigate the problem;
• another may plan the change;
• a specialist may execute it;
• another tool may verify the result.

AG Arch can coordinate those capabilities while keeping them connected to the same governed work.

This allows specialization without fragmenting the task into unrelated autonomous actions.

The intent, mandate, constraints, and proof requirements remain stable even when the executing capability changes.

Capabilities can be composed

Sometimes the required ability does not exist in a single component.

A useful execution capability may combine:

• a reasoning model;
• a specialist knowledge pack;
• one or more tools;
• access to a particular environment;
• a validation mechanism.

AG Arch can therefore treat capability as something that may be composed, rather than assuming every useful function has to exist as one standalone agent.

This makes the pool extensible.

New tools or specialists can be introduced without redefining the entire lifecycle.

The pool can expose capability gaps

Sometimes AG Arch may know what the work requires but have no suitable capability available.

That is important information.

The system should not respond by sending the task to an unsuitable agent and hoping for the best.

A capability gap may mean:

• the required specialist is unavailable;
• an appropriate tool is missing;
• the required environment cannot be reached;
• no available capability can produce the required proof.

That can trigger rerouting, replanning, or a safe stop.

The absence of a suitable capability is therefore part of governed decision-making.

Example — changing a system configuration

Continuing the same example:

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

The Capability Pool might contain:

• a general reasoning agent;
• a repository specialist;
• an infrastructure specialist;
• a deployment tool;
• a monitoring capability.

The work requires access to the service environment and the ability to modify its configuration safely.

AG Arch therefore routes the execution to the infrastructure capability rather than simply giving the task to whichever agent started the lifecycle.

That capability receives the governed mandate:

• change the relevant configuration;
• stay inside the authorized environment;
• preserve protected state;
• produce the evidence required for verification.

If the infrastructure specialist later needs repository analysis, that part of the work may be handed to another capability without changing the original mandate.

The work remains governed even as the capabilities performing it change.

How the Capability Pool supports AG Arch

The Capability Pool gives AG Arch a replaceable and extensible execution layer.

It allows the system to:

select capabilities based on the work;

use specialists where specialization matters;

combine agents, models, and tools when necessary;

change execution capability without changing governance;

and

recognize when the required capability does not exist.

Human Authority determines what may be done.

The governed mandate carries those boundaries.

The Capability Pool provides the means to do the work.

The final supporting system explains how all of those decisions, actions, handoffs, and evidence remain connected over time: