ANCHOR v0 Whitepaper

Status: Draft Frozen · v0 Date: 2025 Classification: Non-standards-track; informational

Abstract

Multi-agent AI systems distribute reasoning and execution across multiple agent instances. Planners — whether human operators, orchestration frameworks, or other models — must allocate tasks under uncertainty. One dimension of that uncertainty is whether a given agent instance has continuity: prior context, accumulated state, or history with a problem that might be relevant to an ongoing task.

ANCHOR is a non-deterministic presence and continuity signal designed to make that dimension legible to planners. It is not a capability claim, a performance guarantee, or an identity assertion. It is a weak prior: structured information that a planner may choose to consider, or not, when making allocation decisions.

This document describes the rationale for ANCHOR, its design principles, the v0 signal structure, and the explicit constraints that bound its scope.

1. Introduction

The proliferation of multi-agent AI systems has introduced a class of coordination problems that did not exist in single-agent settings. When multiple agent instances operate in parallel or in sequence, planners face allocation decisions that involve more than capability matching. They must also reason about context: which agents have relevant history, which are currently operating, and which would need to be initialized from scratch.

Existing approaches to this problem are either absent (planners ignore continuity entirely), implicit (continuity is embedded in proprietary framework state and not exposed), or over-specified (continuity is conflated with identity, reputation, or performance).

ANCHOR proposes a middle path: a lightweight, explicit, advisory signal that an agent can emit and a planner can read. The signal is deliberately weak. It makes no claims about what a planner should do with it. It does not guarantee outcomes. It is a piece of structured information in an environment that otherwise lacks it.

1.1 Scope of This Document

This document covers:

• The problem ANCHOR addresses
• The design principles governing ANCHOR v0
• The signal components: presence and continuity
• The planner integration model
• v0 constraints and explicit prohibitions
• Future directions

This document does not cover planner implementation details, agent SDK specifics, or deployment infrastructure. See the Spec for normative requirements and Examples for conceptual integration patterns.

2. The Agent Continuity Problem

2.1 Stateless and Stateful Agents

AI agents exist on a spectrum from fully stateless to highly stateful. A stateless agent is initialized fresh for each task: it receives a prompt, produces output, and terminates with no persistent memory of the interaction. A stateful agent accumulates context across tasks or across time: it may remember prior outputs, maintain a model of the problem, or hold intermediate work in progress.

Most production multi-agent deployments involve agents that are partially stateful. They accumulate context within a session but are reset between sessions. The degree of statefulness, and its relevance to any given task, varies by agent, framework, and deployment configuration.

2.2 The Planner's Allocation Decision

A planner allocating tasks across agents must decide which agent instance to assign each task to. In the absence of information about agent state, the planner typically treats all available agents as equivalent. This is often the correct default: for stateless tasks, agent history is irrelevant.

For tasks where continuity matters — ongoing debugging sessions, iterative design work, long-running document synthesis — treating all agents as equivalent may produce suboptimal allocations. The planner may route a task to a fresh agent when a stateful agent with relevant prior context is available. The planner has no way to know the difference.

2.3 The Visibility Gap

The core problem ANCHOR addresses is a visibility gap: planners lack structured information about agent continuity state. This information exists — agents and frameworks typically know whether an instance has prior context — but it is not surfaced in a standard, interoperable way.

ANCHOR fills this gap with a signal. The signal is lightweight, advisory, and deliberately bounded. It does not attempt to solve the full allocation problem. It simply makes one dimension of agent state legible to planners that would otherwise have no visibility into it.

3. Design Principles

ANCHOR v0 is designed according to four principles.

3.1 Advisory, Not Prescriptive

The signal is advisory. It provides information; it does not issue instructions. A planner receiving an ANCHOR signal is informed, not directed. The planner retains full authority over allocation decisions.

This principle exists to preserve planner autonomy and to avoid over-specification. Planners operate in environments with constraints and priorities that the signal cannot know. Prescriptive signals would either be ignored (because they conflict with planner priorities) or cause harm (because they override contextual judgment). An advisory signal avoids both failure modes.

3.2 Non-Deterministic by Design

The signal does not produce deterministic outcomes. The same ANCHOR signal, observed by the same planner, may produce different allocation decisions at different times or in different contexts. This is not a limitation — it is a design choice.

Non-determinism reflects the reality of planning under uncertainty. Planners weigh many inputs. An ANCHOR signal is one input. Its weight relative to other inputs varies by context, planner policy, and task requirements. Embedding determinism into the signal would create false precision and would make the system brittle.

3.3 Minimal and Composable

The signal carries minimal information: presence and continuity, nothing more. It does not include performance metrics, reliability scores, capability vectors, or identity information. Additional dimensions may be added in future versions, but v0 is intentionally narrow.

Minimalism reduces implementation burden, limits the attack surface for misuse, and keeps the signal interpretable. A signal that says many things says nothing clearly. A signal that says two things can be understood, implemented, and reasoned about.

3.4 Explicit Prohibitions

The signal's scope is defined as much by what it must not do as by what it does. ANCHOR v0 explicitly prohibits certain uses and interpretations. These prohibitions are normative — they are requirements, not recommendations. See Section 8 and the Spec for the full list.

4. Presence

Presence is the assertion that an agent instance asserts ongoing existence and reachability at a given point in time.

4.1 What Presence Signals

When an agent emits a presence assertion, it is communicating: "I am here. I am running. You can reach me." This is a minimal, point-in-time claim. It has no memory. It does not accumulate. It does not persist beyond the moment of emission.

Presence is useful for planners that need to distinguish between agents that are running and agents that have terminated, paused, or become unreachable. In environments where agent instances spin up and down dynamically, this information is not always available through other means.

4.2 What Presence Does Not Signal

Presence does not assert capability. An agent that is present may or may not be capable of completing a given task. Presence does not assert availability. An agent that is present may be occupied with other work. Presence does not assert readiness. An agent that is present may be in the middle of a long-running operation.

Planners must not treat presence as an availability guarantee or as a capability claim.

4.3 Heartbeat Mechanism

In v0, presence can be maintained through periodic heartbeat emissions. An agent that has not emitted a presence signal within a configurable window is considered absent. The heartbeat interval and absence threshold are implementation-defined and are not specified in v0.

5. Continuity

Continuity is the assertion that an agent instance has accumulated context, prior work, or state relevant to an ongoing problem.

5.1 What Continuity Signals

When an agent emits a continuity assertion, it is communicating: "I have history with this problem domain. I am not starting from zero." This is a declaration of accumulated state. It does not characterize the quality of that state. It does not claim that the accumulated context is correct, complete, or useful.

Continuity is relevant for tasks where history matters: iterative refinement, debugging sessions that span multiple interactions, document synthesis that builds on prior drafts, or any task where prior context reduces the cost of initialization.

5.2 What Continuity Does Not Signal

Continuity does not assert that prior work was performed correctly. An agent may have accumulated context that is incorrect, incomplete, or stale. Continuity does not assert that accumulated context is relevant to the current task. An agent may have history with a different problem that happens to share surface characteristics with the current one.

Continuity does not rank agents against each other. An agent with continuity is not better than an agent without continuity. It is different. Whether that difference matters is context-dependent and is determined by the planner.

5.3 Continuity Metadata (v0)

In v0, the continuity assertion includes a minimal set of metadata:

• session identifier (optional): an opaque string identifying the session or problem context
• context depth (optional): an integer indicating the approximate number of prior interactions in the current session
• last active timestamp (optional): a timestamp of the most recent prior interaction

All metadata fields are optional. Their interpretation is left to the planner. ANCHOR v0 does not specify how planners should use these fields.

6. The Planner's Role

The planner is the consumer of ANCHOR signals. Its role is to read signals and incorporate them — or not — into allocation decisions.

6.1 Signal Consumption

A planner that integrates ANCHOR reads available signals from agent instances, then uses that information as one input into its allocation reasoning. The planner is not required to give ANCHOR signals any specific weight. It is not required to prefer agents with continuity signals over agents without them.

The planner is only required to read the signal. What it does with the signal is entirely at the planner's discretion.

6.2 The Weak Prior Model

The intended use of ANCHOR signals is as a weak prior. In Bayesian terms: observing an ANCHOR continuity signal should update the planner's belief that this agent has relevant prior context, without overwhelming the planner's other beliefs about the task, the agent, and the environment.

The strength of the update is intentionally not specified. A planner in an environment where continuity is highly valuable may weight the signal heavily. A planner where task independence is the norm may weight it lightly or ignore it entirely. Both are correct uses of the signal.

6.3 Planner Implementation Patterns

ANCHOR does not prescribe planner implementation. Common patterns include:

• Prompt injection: the planner includes ANCHOR signal data in its reasoning prompt when selecting agents for tasks
• Pre-filter: the planner uses presence signals to exclude unreachable agents before applying other selection criteria
• Soft preference: the planner adds a mild preference for agents with continuity signals when other factors are approximately equal

None of these patterns are required. They are illustrative. See Examples for conceptual code.

7. Signal Architecture (v0)

7.1 Signal Object

The ANCHOR v0 signal is a JSON object. The structure is:

Example (non-normative). See the Spec for normative field definitions.

{
  "anchor_version": "0",
  "agent_id": "opaque-string",
  "emitted_at": "2025-01-01T00:00:00Z",
  "presence": {
    "status": "active"
  },
  "continuity": {
    "has_context": true,
    "session_id": "opaque-session-string",
    "context_depth": 12,
    "last_active_at": "2025-01-01T00:00:00Z"
  }
}

7.2 Required Fields

• anchor_version: must be the string "0" for v0 signals
• agent_id: an opaque identifier for the agent instance; format is implementation-defined
• emitted_at: ISO 8601 timestamp of signal emission
• presence.status: one of "active" or "idle"

7.3 Optional Fields

All continuity fields are optional. If continuity is absent, the signal communicates presence only. If continuity.has_context is false, the agent is asserting that it has no relevant prior context.

7.4 Signal Transport

ANCHOR v0 does not specify a transport mechanism. Signals may be passed in-band (as part of agent messages), out-of-band (via a shared registry or sidecar), or injected by the hosting framework. Transport is an implementation concern.

8. Prohibitions and Explicit Non-Goals

The following are explicit prohibitions in ANCHOR v0. Implementations that violate these prohibitions are not conformant.

MUST NOT guarantee outcomes. An ANCHOR signal must not claim, imply, or be construed as claiming that assigning a task to a signaling agent will produce a specific outcome, improve task success rate, or increase the likelihood of any particular result.

MUST NOT trigger automated actions. An ANCHOR signal must not be used as an automatic trigger for task assignment, routing, or any other decision that removes planner judgment from the process.

MUST NOT evaluate agent quality. An ANCHOR signal must not include quality scores, performance ratings, reliability metrics, or any other evaluation of the signaling agent. The signal describes state, not quality.

MUST NOT implement a reputation system. ANCHOR is not a reputation protocol. Signals must not be aggregated across time to produce reputation scores. Agents must not be ranked based on their ANCHOR signal history.

MUST NOT be used for agent identity verification. ANCHOR does not authenticate agents. The agent_id field is an opaque identifier, not a verified identity. Planners must not use ANCHOR signals as evidence of agent authenticity.

9. v0 Constraints

ANCHOR v0 is a minimal first version with significant constraints relative to what future versions may offer.

Read-only signal. The planner reads the signal but does not write to it or acknowledge it. There is no two-way communication in v0.

No validation infrastructure. v0 does not include a mechanism for verifying that signals are accurate. An agent can emit false presence or continuity claims. Planners should treat signals as advisory and unverified.

No standardized transport. v0 does not specify how signals are transmitted. This is a deliberate deferral to allow diverse deployment patterns.

No history aggregation. v0 does not specify how to handle multiple signals from the same agent over time. Each signal is independent.

10. Future Directions

ANCHOR v0 is designed to evolve. Potential future directions include:

Signal acknowledgment (v1). Planners acknowledging receipt of signals, enabling two-way coordination without prescriptive routing.

Structured continuity metadata. More structured descriptions of what kind of context the agent has, without adding quality claims.

Transport standardization. A lightweight standard for signal transport that enables cross-framework interoperability.

Multi-agent session coordination. Signals that describe not just individual agent state but the state of an agent within a larger session involving multiple instances.

None of these are commitments. They are directions. v1 and beyond will be informed by practical experience with v0 deployments.

11. Conclusion

ANCHOR v0 introduces a minimal, advisory signal for presence and continuity in multi-agent AI systems. It does not solve the allocation problem. It does not guarantee outcomes. It does not rank, evaluate, or authenticate agents.

It surfaces one dimension of agent state — continuity — that is currently invisible to most planners, and it does so in a way that preserves planner autonomy, avoids over-specification, and is explicit about its own limits.

The signal is a weak prior. Its value is proportional to the care planners take in applying it: considering it among other inputs, weighting it appropriately for the task at hand, and never treating it as a guarantee.

Appendix A. Icon Semantics (Non-normative)

The canonical ANCHOR icon consists of concentric rings with an empty center.

• The concentric rings represent presence over time: a signal maintained through continued assertion, not accumulated value.
• The empty center represents non-determinism: the signal conveys no guarantee and implies no authority, priority, or correctness.
• The icon carries no evaluative meaning. It is not a score, rating, or reputation mark.

The icon is a visual metaphor only. It has no semantic effect on the signal, the protocol, or planner behavior.

This icon is used as the canonical mark in the website header and document footer.

This document is a public draft. Feedback and discussion welcome.