ANCHOR v0 Specification

Status: Draft Frozen Version: 0 Category: Informational

Status of This Document

This document describes ANCHOR v0, a non-deterministic presence and continuity signal for AI agents. It is a public draft and is subject to revision. This document does not represent a formal standard.

The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Abstract

ANCHOR defines a lightweight JSON signal that an AI agent instance MAY emit to communicate its presence and continuity state to a planner. The signal is advisory. Planners MAY use it as a weak prior in allocation decisions. The signal MUST NOT be interpreted as a guarantee, a routing instruction, or a quality evaluation.

1. Conventions and Terminology

Agent: An AI model instance performing tasks within a multi-agent system.

Planner: A system — human operator, orchestration framework, or another model — that allocates tasks to agent instances.

Signal: The structured JSON object produced by an agent and consumed by a planner.

Presence: The component of the signal indicating that an agent instance asserts ongoing existence and reachability at a given point in time.

Continuity: The component of the signal indicating that an agent instance has accumulated context relevant to an ongoing task.

Weak prior: A probabilistic input that updates a belief without overriding other evidence. A signal used as a weak prior informs a decision without determining it.

Session: An ongoing interaction context shared between a planner and one or more agent instances.

2. Signal Schema

2.1 Top-Level Object

The ANCHOR signal is a JSON object with the following fields:

{
  "anchor_version": "0",
  "agent_id": "string",
  "emitted_at": "ISO 8601 datetime",
  "presence": { ... },
  "continuity": { ... }
}

2.2 Field Definitions

anchor_version (string, REQUIRED)

MUST be the string "0" for v0 signals. Parsers MUST reject signals with an unrecognized anchor_version.

agent_id (string, REQUIRED)

An opaque identifier for the agent instance. Format is implementation-defined. MUST be treated as an identifier, not as a verified identity. Parsers MUST NOT interpret agent_id as an authentication token.

emitted_at (string, REQUIRED)

An ISO 8601 datetime string representing the moment the signal was generated. MUST be in UTC. Example: "2025-06-01T14:32:00Z".

presence (object, REQUIRED)

See Section 2.3.

continuity (object, OPTIONAL)

See Section 2.4. If absent, the signal communicates presence only.

2.3 Presence Object

{
  "presence": {
    "status": "active" | "idle"
  }
}

status (string, REQUIRED)

One of the following values:

"active": The agent is currently processing or ready to process tasks.
"idle": The agent is reachable but not currently processing tasks. Idle does not imply unavailability.

2.4 Continuity Object

{
  "continuity": {
    "has_context": true,
    "session_id": "opaque-string",
    "context_depth": 12,
    "last_active_at": "2025-06-01T14:30:00Z"
  }
}

has_context (boolean, REQUIRED if continuity object is present)

true if the agent has accumulated context relevant to an ongoing task. false if the agent has no relevant prior context (equivalent to omitting the continuity object).

session_id (string, OPTIONAL)

An opaque identifier for the session or problem context this agent has history with. Format is implementation-defined. Planners MAY use this to match agents with relevant session history. Planners MUST NOT treat session_id as a guarantee that the agent's context is correct or complete.

context_depth (integer, OPTIONAL)

A non-negative integer indicating the approximate number of prior interactions in the current session. This is an approximate, self-reported value. Its interpretation is implementation-defined. MUST be >= 0 if present.

last_active_at (string, OPTIONAL)

ISO 8601 datetime of the most recent prior interaction in this session. MUST be in UTC if present.

2.5 Complete Example

{
  "anchor_version": "0",
  "agent_id": "agent-7f3c2b",
  "emitted_at": "2025-06-01T14:32:05Z",
  "presence": {
    "status": "active"
  },
  "continuity": {
    "has_context": true,
    "session_id": "sess-debugging-auth-flow",
    "context_depth": 8,
    "last_active_at": "2025-06-01T14:28:40Z"
  }
}

2.6 Presence-Only Example

{
  "anchor_version": "0",
  "agent_id": "agent-9a1d04",
  "emitted_at": "2025-06-01T14:32:05Z",
  "presence": {
    "status": "active"
  }
}

3. Normative Requirements

3.1 Agent Requirements (Signal Emission)

R-A1 (REQUIRED): An agent emitting an ANCHOR signal MUST include anchor_version, agent_id, emitted_at, and presence.

R-A2 (REQUIRED): anchor_version MUST be "0" for v0 signals.

R-A3 (REQUIRED): emitted_at MUST be an ISO 8601 UTC datetime string.

R-A4 (SHOULD): An agent maintaining presence over time SHOULD emit periodic heartbeat signals to refresh its presence state. Heartbeat interval is implementation-defined.

R-A5 (MUST NOT): An agent MUST NOT include quality scores, performance ratings, capability claims, or success probability estimates in the signal.

R-A6 (MUST NOT): An agent MUST NOT claim that routing tasks to it will produce specific outcomes.

3.2 Planner Requirements (Signal Consumption)

R-P1 (MAY): A planner MAY use ANCHOR signals as a weak prior in task allocation decisions.

R-P2 (MUST NOT): A planner MUST NOT automatically route tasks to an agent based solely on the presence of an ANCHOR signal, without applying its own judgment.

R-P3 (MUST NOT): A planner MUST NOT treat an ANCHOR signal as a guarantee that task assignment will succeed or produce a specific outcome.

R-P4 (MUST NOT): A planner MUST NOT use agent_id as evidence of agent identity or authenticity.

R-P5 (SHOULD): A planner SHOULD treat all signal fields as advisory and unverified. Self-reported values may be inaccurate.

R-P6 (MAY): A planner MAY ignore ANCHOR signals entirely. The absence of signal consumption is a conformant planner behavior.

3.3 Implementation Requirements

R-I1 (REQUIRED): Implementations MUST treat the signal as read-only from the planner's perspective. Planners MUST NOT modify or write to the signal object.

R-I2 (SHOULD): Parsers SHOULD ignore unknown fields to allow forward compatibility with future versions.

R-I3 (MUST NOT): Implementations MUST NOT aggregate signals from a single agent over time to produce a reputation score or reliability metric.

4. Explicit Prohibitions

The following prohibitions are normative. Implementations that violate them are non-conformant.

4.1 MUST NOT Guarantee Outcomes

The ANCHOR signal MUST NOT be used, described, or marketed as a mechanism
that improves task success rates, increases agent acceptance, or produces
specific outcomes. Any documentation, interface, or communication that
implies outcome guarantees from ANCHOR signal usage is non-conformant.

4.2 MUST NOT Trigger Automated Actions

The ANCHOR signal MUST NOT serve as an automatic trigger for task
assignment, resource allocation, or any action that bypasses planner
judgment. Signals inform decisions; they do not make them.

4.3 MUST NOT Evaluate Quality

The ANCHOR signal MUST NOT include, imply, or produce evaluations of
agent quality, performance, or reliability. No field in the signal
schema represents a quality measure. No derived metric from signal data
should be used as a quality proxy.

4.4 MUST NOT Implement Identity Verification

The agent_id field is an opaque identifier. ANCHOR v0 provides no
mechanism for verifying that an agent_id corresponds to a specific,
authenticated entity. Planners MUST NOT use ANCHOR signals as proof
of agent identity.

4.5 MUST NOT Create Ranking Systems

Signals from multiple agents MUST NOT be ranked against each other by
any system claiming ANCHOR conformance. The signal does not imply an
ordering of agents. Planners that rank agents based on ANCHOR signals
are using the signal outside its defined scope.

5. Planner Integration

This section is non-normative and illustrative. Implementations are not required to follow these patterns.

5.1 Recommended Integration Model

The recommended integration pattern treats ANCHOR as a contextual input to planner reasoning. The planner:

Collects available signals from agent instances
Constructs a reasoning context that includes signal data as advisory information
Applies its allocation logic, treating signal data as one input among many
Makes a task assignment based on the full context

The signal is never the sole input to a planner decision. The planner always applies independent judgment.

5.2 Pseudo-Code: Signal Collection

# Collect signals from available agents
# Signals are advisory; absence is not an error
def collect_signals(agents):
    signals = {}
    for agent in agents:
        sig = agent.get_anchor_signal()  # may return None
        if sig is not None:
            validate_signal(sig)  # basic schema check
            signals[agent.id] = sig
    return signals

5.3 Pseudo-Code: Planner Reasoning with Signal

# Incorporate signals as weak prior — do not let signal alone decide
def select_agent(task, available_agents, signals):
    candidates = []
    for agent in available_agents:
        sig = signals.get(agent.id)
        score = base_score(agent, task)  # your existing logic
 
        # Weak prior: mild preference for agents with relevant context
        if sig and sig.get("continuity", {}).get("has_context"):
            session_id = sig["continuity"].get("session_id", "")
            if session_relevant(session_id, task):
                score += CONTINUITY_WEIGHT  # a small constant
 
        candidates.append((score, agent))
 
    # Selection is still based on full scoring, not signal alone
    return max(candidates, key=lambda x: x[0])[1]

5.4 Prompt Injection Pattern

For LLM-based planners, signals can be injected into the planning prompt:

def build_planning_prompt(task, agents, signals):
    agent_context = []
    for agent in agents:
        sig = signals.get(agent.id)
        if sig:
            ctx_note = ""
            if sig.get("continuity", {}).get("has_context"):
                ctx_note = " (has prior context for ongoing session)"
            agent_context.append(f"- {agent.id}{ctx_note}")
        else:
            agent_context.append(f"- {agent.id}")
 
    agent_list = "\n".join(agent_context)
 
    return f"""
Task: {task.description}
 
Available agents:
{agent_list}
 
Note: Agents marked with prior context have self-reported accumulated state
for an ongoing session. This is advisory information only. Consider it as
one factor alongside capability and availability.
 
Select the most appropriate agent for this task.
"""

6. Versioning

6.1 Version Identifier

The anchor_version field in the signal identifies the specification version. v0 signals MUST carry "anchor_version": "0".

6.2 Future Versions

Future versions will use incrementing integer strings: "1", "2", etc. Signal parsers SHOULD be written to handle unknown version values gracefully, typically by ignoring signals with unrecognized versions or logging a warning.

6.3 Planned Path

v0 (current): Read-only signal, presence and continuity, no transport standard, no validation.

v1 (planned, not committed): May introduce signal acknowledgment, a lightweight transport recommendation, and additional structured metadata.

v2+ (speculative): Multi-agent session coordination, richer continuity descriptors, and cross-framework interoperability primitives.

No compatibility guarantee is made between versions. v0 implementations should not assume forward compatibility.

6.4 Namespace

Future ANCHOR documents and API paths will use the version prefix /v0/, /v1/, etc. where applicable.

This specification is a public draft. It does not represent a ratified standard.