&space.fleet — Fleet State, Regional Context, and Spatial Operations&space.fleet is the [&] Protocol capability for fleet-aware spatial intelligence.
It describes an agent's ability to reason about:
where assets are
which regions are affected
how capacity is distributed
what route or allocation options are feasible
how spatial state should enrich downstream decisions
In the protocol's four-primitive model:
&memory answers what the agent knows
&reason answers how the agent decides
&time answers when things change
&space answers where things are
&space.fleet is one of the most practical &space subtypes because many real agents operate over:
vehicles
field teams
datacenter regions
delivery networks
service territories
distributed assets
supply and dispatch systems
&space.fleet is the capability interface for fleet-state and regional-context awareness.
It is used when an agent must work with:
distributed assets across regions
current or near-current location state
region-level capacity and utilization
affected-area enrichment
fleet-aware routing or allocation support
operational boundaries tied to geography or logical regions
This capability is not limited to literal vehicle fleets.
It can also apply to:
cloud regions and clusters
service zones
warehouse networks
technician territories
dispatchable units
mobile robotics
edge deployments
The key idea is that the system is managing a set of distributed units in space.
Many agent systems fail when they treat the world as if it were only text plus tools.
That works for simple demos, but it breaks down quickly in real workflows.
Examples:
An infrastructure agent detects an anomaly, but cannot localize which regions are affected.
A logistics agent forecasts demand, but cannot determine which fleet region has spare capacity.
A support agent recommends action, but does not know which warehouse or field team owns the issue.
A dispatch system can reason about urgency, but not whether the nearest viable unit is already overloaded.
In all of these cases, the missing layer is spatially grounded fleet state.
&space.fleet gives the protocol a standard way to declare that capability.
&space.fleet solves&space.fleet is useful when an agent needs to answer questions like:
Which region is affected?
Which assets are inside the impacted zone?
Which fleet segment has spare capacity?
Which unit is closest or most appropriate?
Which operational region should receive rerouted work?
Which datacenter or territory is under pressure?
How does spatial distribution change the recommended action?
Without this capability, spatial reasoning tends to get buried inside:
one-off service calls
custom application logic
hidden prompt assumptions
vendor-specific code paths
The protocol makes it explicit instead.
&space namespaceThe &space primitive can support multiple subtypes, including:
&space.fleet
&space.route
&space.geofence
A helpful distinction is:
&space.fleet = distributed assets and regional state
&space.route = path and route computation
&space.geofence = boundary and zone membership logic
&space.fleet is the right subtype when the main problem is state across a distributed fleet or region graph, not just route optimization or boundary checking.
Track and enrich vehicle or field-unit state by region, capacity, and current location.
Map incidents or anomalies to production regions, clusters, facilities, or datacenters.
Determine which region can absorb demand or which assets should be reallocated.
Identify nearest or most appropriate dispatchable unit under current fleet constraints.
Understand regional inventory or transport network pressure before a decision is made.
Select or evaluate units across spatially distributed systems.
Interpret failures, forecast load, or scale decisions in relation to regional topology.
A representative contract for &space.fleet:
{
"$schema": "https://protocol.ampersandboxdesign.com/schema/v0.1.0/capability-contract.schema.json",
"capability": "&space.fleet",
"provider": "geofleetic",
"version": "0.1.0",
"description": "Spatial fleet-state contract for regional asset lookup, route-aware enrichment, and capacity snapshots.",
"operations": {
"locate": {
"in": "asset_query",
"out": "location_set",
"description": "Resolve current fleet or asset locations from an asset query."
},
"enrich": {
"in": "context",
"out": "spatial_context",
"description": "Attach fleet, region, or topology context to an upstream artifact."
},
"capacity": {
"in": "region_query",
"out": "capacity_snapshot",
"description": "Return region- or fleet-level capacity state for planning and routing."
},
"route": {
"in": "route_request",
"out": "route_plan",
"description": "Produce a fleet-aware route recommendation under current spatial constraints."
}
},
"accepts_from": [
"&memory.*",
"&time.*",
"raw_data",
"context"
],
"feeds_into": [
"&reason.*",
"&memory.*",
"output"
],
"a2a_skills": [
"fleet-state-enrichment",
"regional-capacity-lookup",
"route-feasibility-evaluation"
]
}This contract says that &space.fleet can:
locate assets
enrich upstream context with spatial information
provide regional capacity snapshots
assist routing under spatial constraints
It also says that this capability composes well with:
&time.* upstream, where temporal signals must be localized
&memory.* upstream, where prior context should be tied to a region or asset cluster
&reason.* downstream, where spatial state affects action selection
locatePurpose:
resolve current position or placement of assets
Typical input:
asset_query
Typical output:
location_set
Use when:
the agent needs to know where relevant units or resources are right now
enrichPurpose:
attach spatial fleet context to another artifact
Typical input:
context
Typical output:
spatial_context
Use when:
another capability has already produced a useful signal and spatial grounding is required before a decision
capacityPurpose:
return regional or fleet-wide capacity state
Typical input:
region_query
Typical output:
capacity_snapshot
Use when:
planning, routing, or escalation depends on whether a region is overloaded or underutilized
routePurpose:
provide a route or path recommendation informed by fleet conditions
Typical input:
route_request
Typical output:
route_plan
Use when:
path choice depends on current distributed fleet state, not only geometry
stream_data
|> &time.anomaly.detect()
|> &space.fleet.enrich()
|> &reason.argument.evaluate()Use this when:
a temporal signal needs to be localized to affected regions or assets before action is chosen
Example:
detect a load anomaly
determine which regions are actually constrained
decide whether to reroute, scale, or escalate
demand_history
|> &time.forecast.predict()
|> &space.fleet.capacity()
|> &reason.plan.plan()Use this when:
future demand should be compared against current or projected regional capacity
Example:
forecast next-day delivery demand
inspect available fleet capacity by region
build a reallocation plan
incident_context
|> &memory.graph.enrich()
|> &space.fleet.enrich()
|> &reason.argument.evaluate()Use this when:
prior operational or incident knowledge should be combined with live regional state before making a decision
dispatch_request
|> &space.fleet.locate()
|> &space.fleet.route()
|> &reason.plan.evaluate()Use this when:
the system needs both current fleet placement and a route-aware recommendation
A simplified conceptual flow for &space.fleet:
incoming signal / query / forecast
|
v
+-------------------+
| &space.fleet |
| |
| locate |
| enrich |
| capacity |
| route |
+---------+---------+
|
v
+-------------------+
| spatial_context |
| location_set |
| capacity_snapshot |
| route_plan |
+---------+---------+
|
v
+-------------------+
| &reason.* / |
| &memory.* / |
| output |
+-------------------+The capability's job is to turn generic or upstream context into spatially actionable state.
A concrete ampersand.json fragment:
{
"&space.fleet": {
"provider": "geofleetic",
"config": {
"regions": ["us-east", "us-central"],
"mode": "regional-capacity-awareness"
}
}
}A fuller declaration:
{
"$schema": "https://protocol.ampersandboxdesign.com/schema/v0.1.0/ampersand.schema.json",
"agent": "FleetManager",
"version": "0.1.0",
"capabilities": {
"&time.forecast": {
"provider": "ticktickclock",
"config": {
"horizon_hours": 24,
"granularity": "hourly"
}
},
"&space.fleet": {
"provider": "geofleetic",
"config": {
"regions": ["us-east", "us-central"],
"mode": "regional-capacity-awareness"
}
},
"&reason.plan": {
"provider": "auto",
"need": "fleet reallocation planning with policy-aware tradeoffs"
}
},
"governance": {
"hard": [
"Never route assets through restricted zones without authorization"
],
"soft": [
"Prefer local-region balancing before cross-region escalation"
],
"escalate_when": {
"confidence_below": 0.75,
"hard_boundary_approached": true
}
},
"provenance": true
}A provider-specific API will vary, but a typical locate request might look like:
{
"operation": "locate",
"input": {
"asset_ids": ["veh_102", "veh_104", "veh_201"],
"region_scope": ["us-east", "us-central"]
}
}Representative response:
{
"location_set": [
{
"asset_id": "veh_102",
"region": "us-east",
"lat": 40.7128,
"lon": -74.0060,
"status": "available"
},
{
"asset_id": "veh_104",
"region": "us-east",
"lat": 39.9526,
"lon": -75.1652,
"status": "busy"
}
]
}A capacity request might look like:
{
"operation": "capacity",
"input": {
"regions": ["us-east", "us-central"],
"window": "next_24h"
}
}Representative response:
{
"capacity_snapshot": {
"us-east": {
"available_units": 14,
"utilization": 0.87
},
"us-central": {
"available_units": 22,
"utilization": 0.61
}
}
}The protocol does not standardize this exact transport payload. It standardizes the capability contract.
Representative compatible providers include:
geofleetic
custom geospatial fleet services
dispatch and field-service backends exposed behind MCP-compatible surfaces
routing and regional operations systems with stable contract wrappers
infrastructure topology services that expose region-state as a fleet-like capability
The most natural default ecosystem example in this repository is:
geofleetic
Why it fits:
fleet-aware domain model
regional and route-aware spatial semantics
strong compatibility with logistics and distributed operations use cases
The protocol stance remains:
&space.fleetis the capability.geofleeticis one provider that may satisfy it.
Spatial fleet decisions often have real operational consequences, so governance matters.
Examples:
Never route assets through restricted or unsafe operating regions.
Never disclose sensitive fleet location outside authorized workflows.
Never exceed regional operational limits without approval.
Never rebalance fleet state in a way that violates service boundaries or compliance zones.
Examples:
Prefer local-region balancing before cross-region failover.
Prefer lower-disruption route changes when confidence is moderate.
Prefer maintaining emergency reserve capacity in critical regions.
Examples:
escalate when route feasibility is uncertain
escalate when a hard boundary is approached
escalate when regional capacity falls below a critical threshold
escalate when the best spatial option exceeds cost or policy thresholds
Representative governance block:
{
"governance": {
"hard": [
"Never route assets through restricted geofences",
"Never disclose customer or fleet location outside authorized workflows"
],
"soft": [
"Prefer local-region remediation before cross-region failover"
],
"escalate_when": {
"hard_boundary_approached": true,
"confidence_below": 0.75
}
}
}Spatial enrichment should participate in the provenance chain.
Representative provenance record:
{
"source": "&space.fleet",
"provider": "geofleetic",
"operation": "enrich",
"timestamp": "2026-03-15T12:00:00Z",
"input_hash": "sha256:9a77...",
"output_hash": "sha256:bc12...",
"parent_hash": "sha256:7b2c...",
"mcp_trace_id": "gfleet-enrich-204"
}This matters because spatial context can strongly influence downstream action.
Provenance should help answer questions like:
Why did the system choose us-east instead of us-central?
Which fleet-state snapshot informed the decision?
Which provider produced the location or capacity context?
Which upstream anomaly or forecast led to this spatial query?
A &space.fleet capability may advertise skills such as:
fleet-state-enrichment
regional-capacity-lookup
route-feasibility-evaluation
These are useful when generating A2A-style agent cards, because they let an external coordination surface say more than “has spatial awareness.”
Instead, it can say the agent can:
enrich tasks with fleet state
evaluate regional capacity
support route feasibility judgments
A declaration containing &space.fleet may compile into MCP-facing configuration for a compatible spatial provider.
That makes &space.fleet a good example of the protocol's overall claim:
the declaration captures capability composition
downstream tools can generate runtime config from that declaration
In other words:
[&] declares the fleet-aware spatial capability MCP can carry the provider-facing integration
&space.fleet is supported by several overlapping research and systems traditions:
spatial reasoning
geospatial information systems
fleet optimization and dispatch
route planning and logistics
situated and embodied decision systems
distributed operations management
topology-aware infrastructure control
The important protocol-level insight is not that fleet optimization is new.
It is that fleet-aware spatial reasoning should be explicit in the agent's capability declaration, rather than buried in framework code or provider-specific prompts.
That explicitness enables:
schema validation
contract checking
provider interchangeability
governance-aware composition
provenance-preserving decisions
downstream MCP and A2A generation
If fleet context changes the meaning of a decision, it should be modeled explicitly.
These are related, but not identical, interfaces.
A reasoner may explain well and still be the wrong source of authoritative fleet state.
If region, asset, or route context affects the outcome, lineage should be preserved.
Use &space.fleet when:
the system manages distributed assets or regions
current or projected capacity matters
the agent must localize events before acting
the system should choose actions differently depending on region or fleet state
Prefer composing it with:
&time.* when temporal signals need localization
&memory.* when prior incidents or cases should be mapped to spatial context
&reason.* when action selection depends on regional or fleet constraints
Common high-value compositions:
&time.anomaly + &space.fleet + &reason.argument
&time.forecast + &space.fleet + &reason.plan
&memory.graph + &space.fleet + &reason.argument
detect anomaly
localize affected region
inspect region capacity
choose safe remediation
forecast demand surge
compare regional fleet availability
generate reallocation plan
identify nearest viable unit
check territory constraints
select dispatch candidate
determine which region owns the issue
check handoff capacity
escalate or reroute appropriately
&space.fleet is the [&] Protocol capability for fleet-aware spatial context.
It is the right capability when an agent needs to know:
where distributed assets are
which regions are affected
how capacity is distributed
what route or reallocation decisions are feasible
how spatial state should constrain downstream action
In one sentence:
&space.fleetgives an agent a protocol-native way to understand and act on distributed spatial state.