A finite agent does not act by representing every possible transition, continuously processing an unlimited instruction stream, or reasoning from a distant goal directly to microscopic control signals.
It acts through an organized hierarchy.
Physical and computational components realize primitive functions.
Interfaces expose selected functions as invocable operators.
Controllers and learned policies stabilize recurring compositions into skills.
The feasible composition closure of these operators and skills determines which outcomes the configured agent can reliably realize.
Goals create inverse reachability problems:
given current configuration
+
desired target condition
->
find an executable composition that reaches the target
Because direct interaction is local and agent capacity is finite, a useful architecture does not transmit the entire trajectory at once. It resolves the global target into successive context-sensitive chunks that are small enough to interpret, verify, and execute from the current configuration.
Navigation systems, drone autopilots, humanoid control stacks, operating systems, language-guided action, and institutional procedures all exhibit this structure:
global target
->
route or plan
->
locally relevant subgoal
->
executable operator instance
->
control realization
->
observation
->
updated resolution
The central claim is:
Capability is the stable availability of successful composition realizations, while practical guidance is the repeated resolution of a global target into locally executable chunks under changing context.
This document develops that claim as a standalone framework.
A finite agent may receive a target such as:
reach Munich
grasp the cup
clean the room
compile the program
deliver the package
obtain legal approval
The target rarely specifies every intermediate transition.
A navigation destination does not contain every steering correction.
A request to grasp a cup does not contain every joint torque.
A software requirement does not contain every machine instruction.
A legal objective does not contain every filing, review, signature, and registry transition.
Yet agents often act successfully because they inherit organized structures that connect high-level targets to lower-level realizations.
These structures include:
maps
policies
controllers
skills
instruction sets
interfaces
resolvers
registries
procedures
routing systems
learned models
persistent infrastructure
The central problem is therefore not merely:
Which actions exist?
It is:
Which actions are available to this configured agent?
Which invocations are currently executable?
Which compositions reach the target?
Which references and meanings resolve?
Which local chunk should be exposed next?
How should execution be monitored and replanned?
The framework distinguishes four objects that are often collapsed.
An operator is an invocable transition schema.
[ u(a):c\to\mathcal B(c',z) ]
where:
a = invocation arguments
c = current configuration
c' = resulting configuration
z = observation or output
B = deterministic, nondeterministic, probabilistic, or strategic behavior model
A skill is a stabilized reusable realization of a behavior family, often implemented by a controller or policy.
[ s(o_t)\mapsto a_t ]
where observations are converted into actions over time.
An operational capability is the stable availability of a class of successful realizations under a declared region of conditions.
A task specifies a desired target condition or outcome.
[ \tau=(g,\Theta) ]
where:
g = target predicate
Theta = task constraints, tolerance, horizon, or quality conditions
Thus:
operator
=
reusable transition contract
skill
=
stabilized behavioral realization
capability
=
supported class of successful realizations
task
=
requested target condition
Executability is relative to a configured agent.
Let:
[ c=(x,k,b,r,\alpha,e,t) ]
where:
x = external or target-system state
k = represented knowledge state
b = body or hardware configuration
r = resource state
α = authority and access state
e = environment
t = temporal context
The same abstract operator may be executable in one configuration and unavailable in another.
Examples include:
a grasping skill with a damaged gripper
a route with a closed road
an API call with expired credentials
a program with insufficient memory
a human instruction in an unknown language
a legal procedure outside the relevant jurisdiction
Therefore:
Capability is not a property of an abstract action name alone. It is a relation among an agent, its organization, its current configuration, an environment, and a target class.
A component may implement a primitive transformation:
[ f_i:X_i\to Y_i ]
Examples include:
camera
:
light pattern
->
image data
motor
:
electrical command
->
torque
radio
:
encoded data
->
transmitted signal
parser
:
text
->
structured representation
memory cell
:
write signal
->
retained bit state
The component may support a physical function without exposing it as an independently invocable operator.
A battery supplies voltage, but the system may not expose:
GENERATE_VOLTAGE()
as a public action.
The distinction is:
realized physical function
versus
invocable operator
An operator normally requires a stable access path, invocation language, contract, and realization.
Let:
{f_1,\dots,f_m} ]
be the primitive function set realized by the components.
Let:
{u_1,\dots,u_n} ]
be the primitive operator set exposed through usable control interfaces.
In general:
[ \mathcal U_0 \not\equiv \mathcal F_0 ]
because some functions are:
not directly controlled
not separately addressable
not semantically exposed
not safe to invoke
not stable enough to promise
used only as internal infrastructure
Conversely, one exposed operator may depend on many primitive functions.
For example:
[ \operatorname{CaptureImage} ]
may require:
sensor activation
clock synchronization
exposure control
memory allocation
signal conversion
image encoding
error detection
Thus:
The public operator set is a curated projection of the underlying functional organization.
An operator inventory lists available names.
An operator system also specifies how the operators can interact.
Let:
( \mathcal U, \circ, \parallel, \Gamma, \mathcal C, \mathcal R ) ]
where:
U = operator set
∘ = sequential composition relation
∥ = parallel or concurrent composition relation
Γ = typing, role, and interface environment
C = state, resource, authority, temporal, and embodiment constraints
R = resolver and access infrastructure
Two systems may contain the same nominal operator names while supporting different capabilities because their composition rules, implementations, resources, or resolver structures differ.
Therefore:
operator inventory
!=
operator system
and:
same parts
!=
same practical capability
A controller coordinates lower-level transitions over time.
For a grasping controller:
[ \pi_{\text{grasp}}: o_t\to a_t ]
the internal realization may repeatedly combine:
object tracking
pose estimation
trajectory correction
joint control
collision avoidance
force sensing
gripper closure
slip compensation
Externally, the system may expose one higher-level operator:
[ \operatorname{Grasp}(object) ]
The controller compresses a large internal interaction sequence into a stable interface.
Thus:
[ u_1\circ u_2\circ\cdots\circ u_k \rightsquigarrow s ]
where (s) is a promoted composite skill.
The promoted skill is not identical to one fixed sequence. It may contain feedback, branching, retries, and adaptation.
A skill can be modeled as a controlled composition schema:
[ s: \mathcal O\times C \to \mathcal B(C\times Z) ]
where:
O = observation histories
C = configurations
Z = outputs or execution observations
A skill differs from a one-time trace.
One trajectory:
reach
->
align
->
close gripper
is an execution token.
A skill is the maintained organization capable of producing suitable trajectories across an admissible region.
Therefore:
successful trace
!=
skill
skill implementation
!=
capability in every context
skill available
!=
particular invocation executable
The word capability has at least two important technical meanings.
The system can realize a class of outcomes.
[ \operatorname{OpCap}(A,g,c,H) ]
means agent (A) can realize target (g) from configuration (c) within horizon (H), under the declared reliability conditions.
The agent possesses a token, credential, role, or delegated right permitting selected operations.
[ \operatorname{AuthCap}(A,u,\sigma) ]
may represent authorization to invoke operator (u) within scope (\sigma).
The two interact but should not be confused.
An agent may:
physically know how to open a door
but lack permission
or:
possess authorization
but lack the physical means
Practical execution may require both:
[ \operatorname{OpCap} \land \operatorname{AuthCap} ]
Let:
[ \operatorname{Plans}(\mathfrak O,c,H) ]
be the set of composition structures constructible from operator system (\mathfrak O), starting from configuration (c), within horizon (H).
Let:
[ \operatorname{ExecPlans}(\mathfrak O,c,H) \subseteq \operatorname{Plans}(\mathfrak O,c,H) ]
be the subset satisfying:
typing
preconditions
embodiment constraints
resource constraints
authority constraints
temporal constraints
reference continuity
implementation availability
reliability thresholds
Then the operational capability set is:
\left{ g ;\middle|; \exists p\in \operatorname{ExecPlans}(\mathfrak O,c,H): p(c)\models g \right} ]
This gives the central construction:
\text{target effects generated by feasible operator composition} } ]
Capabilities therefore emerge from composition possibilities, but only from feasible and sufficiently stable composition possibilities.
A grammar may allow:
[ u_1\circ u_2 ]
while the composition remains physically impossible.
Possible failures include:
output type mismatch
semantic mismatch
missing reference
insufficient energy
occupied limb
expired permission
unavailable implementation
timing violation
unsafe intermediate state
excessive failure probability
Therefore:
[ \operatorname{SyntacticallyComposable} \not\Rightarrow \operatorname{Executable} ]
Capability requires a constrained closure:
[ \operatorname{Closure}_{\text{feasible}} ( \mathfrak O,c,H ) ]
rather than unrestricted formal composition.
A task does not normally prescribe every transition.
It declares a desired region:
{c\mid c\models g_\tau} ]
Examples include:
cup is held securely
vehicle is at destination
floor is sufficiently clean
program satisfies tests
application has approved status
The planning problem is:
[ \text{find }p ]
such that:
[ p(c_0)\in G_\tau ]
while satisfying the task constraints.
The selected plan is a composition schema.
Its execution produces an actual trace:
(c_0,u_1(a_1),c_1,\dots,u_n(a_n),c_n) ]
Thus:
task
->
target region
->
plan or policy
->
bound operator instances
->
execution trace
->
observed outcome
A useful three-level distinction is:
[ \operatorname{CanGraspCup} ]
This denotes a class of realizable interactions.
[ \operatorname{Approach} \circ \operatorname{Reach} \circ \operatorname{Align} \circ \operatorname{CloseGripper} ]
This denotes a reusable way to realize that class.
robot R grasps cup c7 at time t
This is one actual occurrence.
A capability is neither merely the schema nor merely the token.
It is the maintained availability of suitable schemas and realizations over a declared region.
The CPU analogy is useful.
A processor acts through:
instruction set
register file
memory
privilege state
devices
pipeline state
A human or robot acts through:
body
sensors
actuators
learned skills
working memory
tools
authority
environment
A processor cannot issue an instruction requiring unavailable registers, privilege, memory, or device state.
An embodied agent cannot execute an action requiring:
a third hand
an absent tool
unavailable balance
excess reach
more force than the body can generate
a language it cannot interpret
a permission it does not possess
The analogy is not exact.
Human and robotic action systems are:
continuous
adaptive
probabilistic
partly learned
dynamically recalibrated
tool-extendable
But the structural resemblance remains:
Action selection occurs relative to a finite embodied architecture and its current state, not against an unlimited abstract action vocabulary.
A human does not normally verbalize:
two arms available
left elbow range valid
right hand occupied
balance stable
visual target localized
grip aperture sufficient
before grasping an object.
These conditions are largely resolved by sensorimotor organization.
The agent behaves as if it maintains a changing executable frontier:
{ u(a) \mid c\vdash u(a)\operatorname{ executable} } ]
The frontier changes when:
the body moves
an object moves
a hand becomes occupied
fatigue increases
a tool is acquired
a permission is granted
an instruction is interpreted
This implicit constraint resolution is one reason ordinary action appears simpler than its underlying structure.
Suppose the system possesses the general operator:
[ \operatorname{Grasp}(x) ]
This does not imply that every invocation is executable.
For cup (c_7), execution may require:
[ \operatorname{Localized}(c_7,c) ]
[ \land \operatorname{ReachableByManipulator}(c_7,c) ]
[ \land \operatorname{CompatibleGrip}(c_7,c) ]
[ \land \operatorname{ManipulatorAvailable}(c) ]
[ \land \operatorname{SufficientForce}(c) ]
[ \land \operatorname{SafeTrajectoryExists}(c_7,c) ]
If the cup lies beyond arm reach, then:
[ \neg \operatorname{Executable} ( \operatorname{Grasp}(c_7),c ) ]
even though the general grasping skill remains part of the system.
Therefore:
[ \text{operator available} \not\Rightarrow \text{every parameterized instance executable} ]
The direct invocation may fail while the target remains reachable through composition.
For example:
[ \operatorname{WalkTo}(c_7) \circ \operatorname{Reach} \circ \operatorname{Grasp}(c_7) ]
or:
[ \operatorname{RetrieveTool} \circ \operatorname{UseReachTool}(c_7) ]
Thus:
[ \neg \operatorname{Executable} ( \operatorname{Grasp}(c_7),c ) ]
does not imply:
[ \neg \operatorname{OpCap} ( A,\operatorname{Held}(c_7),c,H ) ]
The important distinction is:
direct operator invocation
versus
goal reachability through composition
A forward problem asks:
[ u(c)=c' ]
Given an operator and a configuration, what transition follows?
A goal-directed problem asks:
[ \text{given }c_0\text{ and }g, \text{ find }p \text{ such that }p(c_0)\models g ]
This is an inverse problem because the desired outcome is given while the producing composition remains unknown.
It is not generally a mathematical inverse function.
There may be:
many valid plans
no valid plan
irreversible transitions
uncertain outcomes
unknown state
unknown operators
changing environments
strategic interference
A more precise name is:
inverse reachability search
or:
task-conditioned synthesis of an executable composition
An agent may search for:
a path through known states
a missing operator
a bridge between representations
a suitable tool
an interpretable instruction
a reference to the target
a permission or credential
a service implementation
a reusable policy
a maintained route
a cooperating agent
For example, failure to grasp a distant cup may be resolved by searching for:
a path closer to the cup
a reaching tool
another agent
a movable support
a different target cup
Therefore the inverse problem is not always:
[ \text{search over action sequences} ]
It may be:
[ \text{search over executable structures} ]
Physical interactions are usually locally mediated.
A hand affects nearby objects.
A wheel affects the surface at its contact region.
A network packet moves through adjacent links.
A legal filing enters through a recognized procedural interface.
A machine instruction modifies architecturally accessible state.
Let:
{ u(a) \mid u(a)\text{ is locally executable from }c } ]
be the current action neighborhood.
A bounded agent can select among this local frontier more easily than among all imaginable trajectories.
Locality reduces decision complexity because it limits which distinctions matter now.
Thus:
Global reachability is usually constructed from a succession of locally executable transitions.
The same environment presents different local neighborhoods to different agents.
A route segment may be available to:
a pedestrian
but not:
a car
A staircase may be available to:
a walking human
but not:
a wheeled robot
A narrow gap may be available to:
a small drone
but not:
a large vehicle
An API may be locally invocable by:
an authenticated service
but not:
an unauthenticated client
Therefore locality means:
[ \operatorname{Adjacent}_A(c,c') ]
relative to the configured agent and selected interaction mode.
A distant effect becomes locally invocable when infrastructure hides intermediate transitions behind a stable interface.
Examples include:
telephone call
web request
train journey
bank transfer
package delivery
database query
The user performs a local invocation.
A maintained system realizes the longer composition.
Thus:
physical locality
+
persistent infrastructure
->
extended effective adjacency
A phone does not eliminate distance.
It exposes a maintained communication route through a local interface.
A navigation system does not eliminate the road graph.
It exposes the next useful road transition through a local instruction.
Many action systems separate at least two scales.
Select a route, strategy, or sequence of subgoals connecting the current region to the target region.
Select a safe executable transition under current observations and constraints.
A simplified hierarchy is:
global target
->
route or task plan
->
local subgoal
->
trajectory
->
control action
->
actuator command
The global layer does not directly generate every microscopic control signal.
The local layer does not need to reconsider the entire global objective at every actuator update.
Each layer works with a representation appropriate to its horizon and bandwidth.
A drone control architecture commonly resembles:
mission target
->
global path planner
->
waypoint sequence
->
local trajectory planner
->
attitude and position controller
->
motor mixing
->
motor commands
The target might be:
[ g= \operatorname{AtLocation}(q_{\text{goal}}) ]
The global planner reasons over obstacles, maps, corridors, or waypoints.
The local planner adapts the route to current position, velocity, and newly observed hazards.
The low-level controller stabilizes attitude and motion.
No single layer needs the full detail of every other layer.
This resembles a compilation stack:
goal specification
->
intermediate representation
->
lower-level instructions
->
physical execution
A navigation system is not valuable merely because it contains a route.
Its crucial service is that it repeatedly exposes the next locally relevant instruction.
The user supplies the destination once:
[ g= \operatorname{AtDestination}(d) ]
The system may compute:
[ r=(e_1,e_2,\dots,e_n) ]
but it does not require the user to hold all route edges in working memory.
Instead it emits chunks such as:
continue for 1.2 km
take the second exit
turn left at the next intersection
destination is on the right
Each chunk is:
temporally relevant
spatially local
small enough to interpret
linked to observable landmarks
compatible with current mode
revisable when state changes
This is not merely route planning.
It is hierarchical resolution into executable guidance.
Let:
[ \chi ]
be a guidance chunk.
A useful chunk should satisfy:
[ \operatorname{Relevant}(\chi,c,g) ]
[ \land \operatorname{Interpretable}(\chi,A,c) ]
[ \land \operatorname{Bindable}(\chi,A,c) ]
[ \land \operatorname{Executable}(\chi,A,c) ]
[ \land \operatorname{Verifiable}(\chi,A,c) ]
A chunk may be represented as:
( h_u, h_{\text{args}}, P, Q, \omega ) ]
where:
hu = handle to the operator or skill
hargs = handles to arguments or local targets
P = relevant preconditions
Q = expected local completion condition
ω = observation or verification cue
The chunk need not expose the internal control trajectory.
It exposes enough structure for the receiving layer to resolve and execute the next step.
A bounded agent has finite:
attention
working memory
perceptual bandwidth
control bandwidth
update rate
interpretive capacity
Therefore practical guidance cannot require the agent to process an unbounded description at one moment.
Let:
[ B_A(c) ]
be the current processing budget of agent (A).
A chunk should satisfy:
[ L(\chi) \leq B_A(c) ]
where (L(\chi)) measures the information or distinction burden relevant to interpretation and execution.
This does not imply that the total route is short.
It implies that the route is delivered through a bounded sequence of locally consumable interfaces.
Thus:
large total trajectory
!=
large immediate instruction
A brittle architecture would transmit a complete fixed sequence:
[ u_1,u_2,\dots,u_n ]
and assume all future states remain as predicted.
A robust architecture repeatedly resolves the next chunk:
\rho(g,c_t,k_t) ]
The agent executes:
[ c_{t+1} \sim \llbracket \chi_t\rrbracket(c_t) ]
observes:
[ o_{t+1} ]
updates knowledge:
\operatorname{Update}(k_t,o_{t+1}) ]
and resolves again:
\rho(g,c_{t+1},k_{t+1}) ]
This yields:
resolve
->
execute
->
observe
->
update
->
resolve again
The architecture supports deviation, uncertainty, and replanning.
Only part of a long route needs to be committed at a time.
Let:
[ p_t^{(H)} ]
be a plan over a finite horizon (H) computed from the current state.
The system executes only an initial portion:
[ \operatorname{Prefix}_h ( p_t^{(H)} ) ]
where:
[ h < H ]
Then it replans from the resulting state.
This reduces dependence on distant predictions.
A navigation system may preserve the global destination while revising the local route after:
a missed turn
a road closure
traffic
new sensor information
changed preferences
resource depletion
Therefore:
Long-horizon coherence does not require long-horizon open-loop control.
A handle provides a compact entry point into retained organization.
Examples include:
Munich
the cup
open the door
call Alice
compile the project
submit the application
The handle does not contain the complete realization.
It depends on resolver infrastructure.
For destination (d):
[ h_d \overset{\rho_{\text{geo}}}{\longrightarrow} q_d ]
where (q_d) is a geographic target.
Then:
[ (c,q_d) \overset{\rho_{\text{route}}}{\longrightarrow} r ]
Then:
[ (c,r) \overset{\rho_{\text{guidance}}}{\longrightarrow} \chi ]
Then:
[ (c,\chi) \overset{\rho_{\text{control}}}{\longrightarrow} a ]
Thus one compact handle can activate a deep hierarchy of retained organization.
Consider:
grasp the cup
This utterance is not a complete motor program.
It depends on the receiver resolving:
the language
the verb
the intended operator
the object reference
the relevant cup
the current location
the usable hand
the grasp type
the trajectory
the completion condition
Language therefore often transmits:
operator handles
+
argument handles
+
goal constraints
rather than complete physical trajectories.
Its efficiency depends on shared resolver infrastructure:
vocabulary
grammar
world knowledge
perception
social context
learned skills
conventions
Suppose an agent receives the signal:
[ s=\text{a word meaning grasp in an unknown language} ]
If the agent cannot map the signal to an operator identity, then:
\operatorname{failure} ]
The agent may still physically possess a grasping skill.
But the communicated invocation is not executable through the current semantic interface.
Thus:
[ \text{physical skill} \not\Rightarrow \text{linguistically invocable skill} ]
Practical invocation requires a chain such as:
[ \text{signal} \to \text{recognized expression} \to \text{operator identity} \to \text{argument bindings} \to \text{admissible invocation} \to \text{control realization} ]
A failure at any bridge interrupts the action path.
In a narrow sense, a resolver maps a handle to a current locator:
[ \rho_{\text{ref}}: H\times C \to L \cup {\operatorname{failure}} ]
Examples include:
domain name
->
network location
legal identifier
->
registry record
object name
->
perceived object instance
In a broader action-theoretic sense, a resolver maps an underspecified target or handle into a more concrete structure usable by the next layer.
[ \rho_i: H_i\times C_i \to H_{i+1} \cup {\operatorname{failure}} ]
A hierarchy of resolvers progressively reduces ambiguity and increases executability.
A practical action stack may contain several resolver classes.
[ \text{signal} \to \text{recognized symbol sequence} ]
[ \text{symbol sequence} \to \text{structured expression} ]
[ \text{expression} \to \text{operator or target meaning} ]
[ \text{descriptive handle} \to \text{particular entity} ]
[ \text{operator identity} \to \text{available realization or service} ]
[ (\text{entity},c) \to \text{currently supported interactions} ]
[ (\text{goal},c) \to \text{subgoal or plan} ]
[ (\text{plan},c) \to \text{next executable chunk} ]
[ (\text{abstract action},b,c) \to \text{body-relative trajectory or controller} ]
[ (\text{trajectory},c) \to \text{actuator commands} ]
These need not be separate physical modules.
They identify distinct transformation obligations.
Let:
[ h_0=g ]
be a global target handle.
A resolver hierarchy produces:
[ h_0 \overset{\rho_0}{\longrightarrow} h_1 \overset{\rho_1}{\longrightarrow} h_2 \overset{\rho_2}{\longrightarrow} \cdots \overset{\rho_{n-1}}{\longrightarrow} u(a) ]
where each level adds distinctions required by the next.
For navigation:
city name
->
geographic destination
->
route
->
road segment
->
lane maneuver
->
steering and speed target
->
actuator control
For manipulation:
grasp the cup
->
resolve cup
->
resolve approach region
->
select hand
->
select grasp
->
generate trajectory
->
joint commands
For software:
build project
->
resolve project
->
dependency graph
->
build targets
->
compiler invocations
->
machine instructions
Each layer converts one compact handle into a lower-level, more executable handle.
Resolution does not merely replace names with locations.
It progressively establishes constraints.
Let:
[ \mathcal S_i ]
be the set of candidate meanings or realizations after resolver level (i).
A successful resolver narrows the candidate set:
[ \mathcal S_{i+1} \subseteq \mathcal S_i ]
while preserving at least one feasible realization.
The process ends when:
[ |\mathcal S_n| ]
is sufficiently small or structured for execution.
The objective is not necessarily to identify one microscopic trajectory in advance.
It is to produce enough specificity for the next responsible layer.
Thus:
Resolution should stop at the interface where responsibility can safely pass downward.
Agents routinely fill omitted information from context.
When a person hears:
pick up the cup
they may automatically infer:
the salient visible cup
the ordinary meaning of pick up
the nearest usable hand
a safe grasp region
a suitable force range
the expected completion state
Let:
[ \Gamma_c ]
be the active context, containing:
perceptual salience
conversation history
shared conventions
current task
body state
environmental structure
social expectations
Then the interpretation is:
[ \llbracket s\rrbracket_{\Gamma_c} ]
The same signal may resolve differently under another context.
Automatic context resolution compresses communication but introduces failure risks.
Resolver failure modes include:
unknown symbol
ambiguous operator
missing argument
ambiguous reference
stale location
unavailable implementation
wrong embodiment mapping
incompatible version
insufficient authority
unsafe local plan
semantic drift
incorrect contextual assumption
For example:
grasp the cup
may fail because:
no cup is visible
several cups are equally salient
the identified cup is outside reach
the agent lacks a grasping realization
the word grasp is not understood
the instruction conflicts with a safety rule
These failures occur at different layers and require different repairs.
Let:
[ \mathcal C_{\text{latent}}(c) ]
be target classes physically supported by the configured system.
Let:
[ \mathcal C_{\text{accessible}}(c,k,\mathcal R) ]
be target classes the agent can identify, invoke, and realize using knowledge (k) and resolver system (\mathcal R).
Then:
[ \mathcal C_{\text{accessible}} \subseteq \mathcal C_{\text{latent}} ]
A system may contain a useful program but lack its filename.
A robot may contain a grasp controller but fail to localize the cup.
A city may contain a service but expose no discoverable procedure.
A human may possess a relevant skill but fail to recognize its applicability.
Resolvers narrow the gap between latent and accessible capability.
A guidance system occupies an intermediate role.
It does not necessarily execute the action.
It resolves a larger target into an instruction suitable for another agent or controller.
Formally:
[ \rho_{\text{guide}}: (G,C,K,M) \to \Chi \cup {\operatorname{failure}} ]
where:
G = goal
C = current configuration
K = represented knowledge
M = selected mode or embodiment
Χ = guidance chunk space
A good guidance interface hides irrelevant internal complexity while preserving:
direction
timing
local preconditions
completion cues
critical warnings
recovery options
A chunk can be too coarse.
Example:
go to Munich
may be unusable for a driver without route knowledge.
A chunk can also be too fine.
Example:
rotate steering wheel by 0.4 degrees
wait 8 milliseconds
rotate by 0.1 degrees
may overload the human and conflict with the vehicle’s own control loops.
Let:
[ G(\chi,A,c) ]
measure suitability of chunk granularity.
Useful granularity balances:
interpretive burden
local autonomy
error detectability
update frequency
communication cost
state uncertainty
control stability
Thus:
The correct chunk is not the smallest physically possible command. It is the smallest useful instruction for the receiving layer.
A high-level command delegates more resolution to the receiver.
For example:
clean the room
requires the receiver to resolve:
what counts as clean
which region is the room
which objects may be moved
which tools are usable
which sequence is efficient
which hazards must be avoided
A lower-level instruction:
vacuum this marked floor region
delegates less.
A still lower-level instruction:
move forward 0.5 meters
delegates less again.
The depth at which instruction stops and autonomous resolution begins determines the division of labor between planner and executor.
Autonomy need not mean absence of external goals.
It can mean that the agent is responsible for resolving more levels between the given target and physical execution.
Let:
[ D_A ]
be the set of resolver layers assigned to agent (A).
A system with broader (D_A) can accept more abstract goals.
For example:
teleoperated manipulator
accepts direct motion commands
skill-based robot
accepts grasp commands
task-level robot
accepts object relocation goals
mission-level system
accepts broad outcome specifications
Thus:
Greater autonomy corresponds partly to a larger internally maintained resolution stack.
A policy converts current observations into actions without reconstructing the full decision problem each time.
[ \pi: O\to A ]
A map preserves spatial search structure.
A controller preserves stabilization structure.
A skill preserves behavioral search and training.
A procedure preserves institutional search.
A compiler preserves translation structure.
All of these reduce recurring inverse-problem cost.
They differ mainly in:
representation
scope
resolution depth
adaptivity
failure model
maintenance mechanism
Therefore persistent policies, maps, skills, and procedures are accumulated resolution infrastructure.
Suppose a recurring composition is:
[ p= u_1\circ u_2\circ\cdots\circ u_k ]
If it is repeatedly useful, sufficiently stable, and worth maintaining, it may be promoted to:
[ v=\operatorname{Promote}(p) ]
with a simpler public interface.
The promotion may hide:
internal sequencing
error recovery
resource reservation
reference management
control details
This creates hierarchical capability.
For example:
motor torque control
->
walking controller
->
navigate to waypoint
->
deliver package
Each promoted operator becomes a resolvable chunk for the level above.
Let:
[ \mathcal U^{(0)} ]
be the primitive exposed operator set.
Let:
[ \mathcal U^{(1)} ]
contain promoted skills composed from level (0).
More generally:
\operatorname{Promote} \left( \operatorname{Closure}_{\text{feasible}} ( \mathcal U^{(i)} ) \right) ]
The hierarchy may resemble:
actuator functions
->
control primitives
->
sensorimotor skills
->
task operators
->
mission operators
->
organizational services
Higher levels increase usable reach by compressing validated lower-level compositions.
A flat list such as:
walk
grasp
speak
navigate
pay
compile
does not expose:
preconditions
composition dependencies
resource conflicts
resolver requirements
failure boundaries
supported argument regions
remaining options
A capability structure should represent:
( V,E,\Lambda,\Omega ) ]
where:
V = relevant configuration or subgoal regions
E = operator-generated reachable transitions
Λ = labels containing contracts, costs, authority, and reliability
Ω = resolver, interface, and observation structure
This is not necessarily a literal geometric map.
It is an agent-relative organization of executable reachability.
The phrase capability geography is useful when emphasizing:
current location
target destination
mode-relative routes
local neighborhoods
barriers
bridges
maintained paths
replanning
The phrase capability topology is useful when emphasizing:
connectivity
composition
reachability
interfaces
equivalence
continuity
The phrase capability system is useful when emphasizing:
operators
controllers
resources
resolvers
implementations
execution
The formal core does not depend on choosing one metaphor.
The central object is agent-relative executable structure.
The navigation analogy captures more than route search.
It captures the full relation among:
global target
current location
selected mode
maintained infrastructure
map representation
route synthesis
local guidance
state observation
deviation detection
replanning
arrival verification
The user does not need to continuously solve the routing problem.
The route service preserves prior mapping, traffic, naming, and search infrastructure.
The user gives the destination once and receives a sequence of locally resolvable instructions.
Thus:
A useful capability system should not merely enumerate what could be done. It should maintain enough structured knowledge to resolve a target into the next executable interaction for the configured agent.
Drone control emphasizes the layered control architecture:
mission
->
path
->
trajectory
->
stabilization
->
actuation
Google Maps emphasizes the interface between global routing and a bounded human executor:
destination once
->
successive local instructions
The two analogies describe different portions of the same hierarchy.
Drone control shows downward realization.
Navigation guidance shows bounded communication and delegated local execution.
Together they suggest:
global coherence
+
hierarchical resolution
+
local closed-loop control
Human action often proceeds through nested abstractions.
For example:
make coffee
may resolve to:
go to kitchen
prepare machine
obtain cup
add water
add coffee
start brewing
serve
The subgoal:
obtain cup
may resolve to:
locate cup
approach cupboard
open door
reach
grasp
withdraw
The skill:
grasp
may resolve to:
select hand
shape fingers
move arm
correct trajectory
close grip
verify stability
The person usually does not represent all lower levels explicitly.
Different levels become conscious when:
the routine fails
the environment is unfamiliar
the body is impaired
the object is unusual
the instruction is ambiguous
This suggests that conscious deliberation often appears when automatic resolvers cannot produce a trustworthy next chunk.
A smartphone is not merely a bag of:
processor
battery
screen
camera
radio
storage
software
Its identity depends on an organization that exposes capabilities such as:
communication
application execution
internet access
media capture
navigation
persistent data management
A floor-cleaning robot is not merely:
wheels
motors
sensors
battery
software
Its organization may realize:
[ \operatorname{CleanFloorRegion} ]
through lower-level skills such as:
localize
avoid obstacle
move
collect debris
return to dock
Objects are not defined only by capability, but organized capability is a major operational basis for distinguishing systems from unassembled collections of parts.
A demonstration provides one or more trajectories:
[ \eta_1,\dots,\eta_n ]
Learning attempts to infer reusable structure:
[ {\eta_i} \to \pi ]
where (\pi) is a policy or controller.
For a humanoid, imitation also requires embodiment resolution:
[ \text{human motion} \to \text{robot-relative task representation} \to \text{robot-feasible control} ]
The resulting policy becomes a skill only when it generalizes sufficiently across an admissible region.
It contributes to operational capability only when:
the required body exists
the environment is compatible
the references resolve
the task is within the learned regime
the controller remains stable
Thus imitation learning can be understood as constructing new reusable resolver-compatible composition machinery.
A planner may select a chunk:
[ \chi_t ]
The executor may attempt it:
[ \operatorname{Execute}(\chi_t,c_t) ]
The observer may report:
[ o_{t+1} ]
These are distinct events.
The planner may choose a valid action that fails operationally.
The action may succeed while the observation is delayed or ambiguous.
The observation may indicate success incorrectly.
Therefore the loop should distinguish:
selected instruction
attempted realization
actual transition
observed transition
verified local completion
A robust guidance system supplies not only a command but also an expected completion predicate.
A system must know when to stop or advance.
For a navigation chunk:
turn left at the next intersection
completion may require resolving:
which intersection counts as next
whether the turn has occurred
whether the vehicle entered the intended road
For grasping:
grasp the cup
completion may require:
contact established
gripper closed
cup lifted
slip below threshold
Let:
[ Q_\chi(c,o) ]
be the local completion predicate.
A chunk is successfully discharged when:
[ Q_\chi(c',o')=1 ]
Without completion resolution, the system cannot reliably advance to the next chunk.
A global goal can remain persistently bound:
[ g_t=g ]
while local chunks change:
\rho(g,c_t,k_t) ]
The agent need not receive the full goal description at every low-level update.
The goal is retained as persistent context.
This resembles:
destination retained by navigation system
mission retained by autopilot
function call retained by runtime
task retained by working memory
transaction retained by workflow engine
Persistent goal binding reduces repeated communication.
An instruction is not executable independently of its context.
Let:
[ \llbracket s\rrbracket_c ]
denote the interpretation of signal (s) under configuration (c).
The same phrase:
open it
may denote different operator instances depending on:
conversation history
pointing gesture
visible objects
active application
current task
authority
physical location
Therefore:
signal
+
context
->
resolved invocation
The context is not optional decoration.
It supplies omitted bindings.
More context is not always better.
A resolver may be harmed by:
stale information
conflicting instructions
irrelevant detail
excess candidate references
semantic drift
overloaded working memory
obsolete route assumptions
The resolution problem includes selecting which context remains relevant.
Let:
[ \Pi_g(k) ]
be a goal-conditioned projection of knowledge state.
A resolver should operate on:
[ \Pi_g(k) ]
when the full knowledge state is too large or noisy.
Thus bounded agents require not only information acquisition but context curation.
The nearest action is not always the best action.
A local chunk should also be evaluated by the future frontier it preserves.
Let:
[ \mathcal U_{\mathrm{exec}}(c') ]
be the executable frontier after the chunk.
A useful local value may include:
C_{\text{risk}} + G_{\text{optionality}} ]
A route that is slightly longer may preserve:
more fuel
safer alternatives
better communication
more reliable infrastructure
lower chance of entrapment
Therefore locality reduces immediate decision scope, but global planning must still shape which local options are preferred.
The full architecture can be summarized as:
[ (g,c_t,k_t) \overset{\rho_{\text{plan}}}{\longrightarrow} p_t ]
[ (p_t,c_t,k_t) \overset{\rho_{\text{guide}}}{\longrightarrow} \chi_t ]
[ (\chi_t,c_t) \overset{\rho_{\text{embody}}}{\longrightarrow} a_t ]
[ (c_t,a_t) \overset{\operatorname{Execute}}{\longrightarrow} (c_{t+1},o_{t+1}) ]
[ (k_t,o_{t+1}) \overset{\operatorname{Update}}{\longrightarrow} k_{t+1} ]
then repeat.
The architecture is neither purely symbolic nor purely reactive.
It combines:
persistent global target
stored structural knowledge
local context
hierarchical resolution
closed-loop execution
The framework can be summarized as:
components realize primitive functions
->
selected functions are exposed as invocable operators
controllers and policies organize lower-level transitions
->
stable compositions become skills
operator systems include composition, constraints, interfaces, and resolvers
->
operator inventories alone do not determine capability
feasible composition closure
->
supported target classes
supported target classes under declared conditions
->
operational capability
tasks specify target regions
->
agents face inverse reachability problems
physical interaction and finite attention are local
->
only a bounded action frontier is immediately relevant
persistent maps, policies, skills, and infrastructure
->
large searches and trajectories can be reused
global target
+
current configuration
+
resolver hierarchy
->
next locally executable chunk
execution
+
observation
->
updated context and replanning
successive resolvable chunks
->
bounded agents can realize long trajectories without receiving the whole trajectory at once
Components realize functions; organized systems support capabilities.
Invocability requires a stable access path, signature, contract, and realization.
Composition rules, resources, embodiment, authority, interfaces, and resolvers determine practical reach.
A skill compresses lower-level control and feedback into a reusable higher-level interface.
Operational capability consists of target effects reachable through executable compositions under declared conditions.
The same environment and operator vocabulary yield different executable frontiers for different bodies, tools, resources, permissions, and knowledge states.
A general grasp skill does not make every object graspable from every configuration.
A missing direct edge may be replaced by a longer valid composition.
The target is given; the producing executable structure must be found.
The missing object is not always an action sequence.
Global outcomes are generally composed from locally executable transitions.
Adjacency depends on embodiment, tools, authority, and selected interaction mode.
A local interface can activate a maintained long-range composition.
Different layers require different horizons, representations, and update rates.
The whole route need not fit into the current instruction.
Its meaning, arguments, local conditions, and completion cues must fit the receiving layer.
Persistent goals can guide repeated local replanning.
Names, task labels, and destinations are entry points into resolver hierarchies rather than complete trajectories.
Shared context and learned resolver infrastructure fill omitted detail.
Physical capability does not guarantee semantic invocability.
Each resolver layer supplies distinctions required by the next layer.
The next layer should receive enough detail to act, but not unnecessary lower-level complexity.
An agent that can accept abstract goals maintains more of the goal-to-control stack internally.
They are accumulated resolution infrastructure.
Promotion creates hierarchical capability and reduces recurring coordination cost.
Missing references, interpretations, locators, or interfaces can hide physically supported outcomes.
Correct planning alone does not guarantee known success.
The system must resolve when a chunk has been successfully discharged.
Omitted arguments are often supplied by perceptual, linguistic, social, or operational context.
Irrelevant, stale, or conflicting information can reduce resolution quality.
Immediate progress should be balanced against risk, resources, and remaining options.
Useful action depends on organized transitions, resolvable handles, local execution, observation, and repeated updating.
What is the correct formal boundary
between a function, an operator, a controller, a skill, and a capability?
How should operational capability be measured
when success varies across environments and task distributions?
What reliability threshold converts
a possible composition into a stable capability?
How should a capability system represent
continuous embodiment constraints without enumerating every state?
What is the minimum resolver hierarchy
needed to convert a declared target into executable control?
When should planning return a complete route,
a subgoal, an operator instance, or only the next local chunk?
How should guidance granularity adapt
to the receiving agent's skill, attention, and uncertainty?
What information must a chunk expose
to remain independently verifiable?
How should resolver failures be localized
so that the system repairs the correct layer?
When should an ambiguous instruction trigger clarification
rather than autonomous contextual resolution?
How can systems distinguish
helpful implicit context from unsafe hidden assumptions?
How should global planners value
future optionality and recoverability?
When should a frequently executed route
be promoted into a persistent skill or higher-level operator?
How should capability maps represent
changing resources, body state, authority, and infrastructure?
Can capability topology be learned
from demonstrations, failed attempts, and observed interventions?
How should two agents compare capabilities
when their embodiments and interfaces differ?
What constitutes capability transfer
across different bodies or hardware architectures?
How can a system prove that a high-level skill
refines the contracts of its lower-level components?
How should semantic maintenance be budgeted
when language, interfaces, and implementations change?
Can human conscious deliberation be modeled
as escalation after automatic resolver failure?
How should organizational procedures be analyzed
as distributed resolver stacks across multiple agents?
What is the correct stopping rule
for inverse reachability search under finite time?
When does local replanning destroy global coherence,
and which invariants must persist across replans?
How should uncertainty be propagated
from global route selection to local execution guidance?
Can one formalism cover
navigation, manipulation, software execution, institutional action, and language-guided behavior
without erasing their important differences?
The design target is a framework in which:
components
are separated from the functions they realize
functions
are separated from exposed invocable operators
operators
are analyzed as part of constrained composition systems
controllers and learned policies
are represented as realizations of reusable skills
capability
is defined through feasible target-conditioned composition closure
tasks
are represented as target regions rather than complete trajectories
embodiment, resources, authority, and environment
remain explicit in executability
direct invocation failure
is separated from global target unreachability
goal-directed action
is treated as inverse reachability search
physical locality
is treated as the basis of immediate action
persistent infrastructure
is treated as extension of effective locality
global planning
is separated from local guidance and control
resolver hierarchies
progressively convert compact handles into executable instances
guidance chunks
are bounded, interpretable, executable, and verifiable
persistent goals
support repeated closed-loop replanning
maps, policies, skills, and procedures
are treated as retained solutions to recurring inverse problems
autonomy
is partly measured by the depth of internally maintained resolution
human action, robot control, navigation, computation, and institutions
can be compared through shared structural distinctions
without being reduced to identical mechanisms
A component does not by itself determine a capability.
A function does not automatically become an operator.
An operator name does not make every invocation executable.
A skill does not guarantee success in every configuration.
A possible composition does not establish a stable capability.
A target does not contain its own route.
A route does not need to be transmitted as one complete instruction.
A handle does not contain the organization it activates.
A global planner does not need to control every actuator directly.
A local controller does not need to solve the entire mission.
A bounded agent does not need an infinite stream of information.
It needs:
a persistent target
+
an agent-relative model of executable structure
+
maintained operators and skills
+
resolvable references
+
a hierarchy that converts global intent into local action
+
bounded guidance chunks
+
closed-loop observation and replanning
Therefore:
Capability is the stable availability of target-reaching composition realizations for a configured agent. Practical action consists in repeatedly resolving a retained global target into the next locally executable and verifiable chunk, executing it through the appropriate lower-level machinery, observing the result, and resolving again.
Long trajectories become manageable because they are not held or communicated as indivisible wholes.
They are traversed through organized, reusable, context-sensitive resolution.