Developer Docs

ANCHOR v0 is a signal format. There is no backend, no hosted API, and no SDK to install in Phase 1. This documentation covers the conceptual integration model, the API surface we are designing toward, and reference material.

Quick Start (Conceptual)

What you need

To emit an ANCHOR signal from your agent:

1. Your agent must produce a JSON object conforming to the v0 signal schema
2. Your planner must be able to read that JSON object before making allocation decisions
3. That's it

There is no registration step, no API key, and no central server in v0.

Minimal signal

{
  "anchor_version": "0",
  "agent_id": "your-agent-id",
  "emitted_at": "2025-06-01T12:00:00Z",
  "presence": {
    "status": "active"
  }
}

Emit this object from your agent. Make it readable by your planner. Done.

Adding continuity

If your agent has prior context for an ongoing task, add the continuity object:

{
  "anchor_version": "0",
  "agent_id": "your-agent-id",
  "emitted_at": "2025-06-01T12:00:00Z",
  "presence": {
    "status": "active"
  },
  "continuity": {
    "has_context": true,
    "session_id": "your-session-id",
    "context_depth": 3,
    "last_active_at": "2025-06-01T11:55:00Z"
  }
}

Planner integration

Inject the signal into your planner's reasoning context. See Examples for patterns. The key principle: treat the signal as a weak prior, not a directive.

API Surface Outline

This section is forward-looking and non-normative. It describes a possible future API shape, not a commitment.

ANCHOR v0 has no hosted API. The following outlines the surface we are designing toward for v1+. These endpoints do not exist yet.

Agent endpoints (planned)

Planner endpoints (planned)

Notes

• All planned endpoints are subject to change
• v0 deployments do not require these endpoints
• Signal transport in v0 is implementation-defined — see the Spec

FAQ

Is ANCHOR a reputation system?

No. ANCHOR v0 signals are point-in-time and describe state, not history. There is no aggregation of signals over time, no scoring, and no ranking. See Definition and Spec — Prohibitions for the normative statement.

Is ANCHOR an identity system?

No. The agent_id field is an opaque identifier. ANCHOR v0 provides no authentication mechanism. Planners MUST NOT use ANCHOR signals as evidence of agent identity or authenticity.

Does ANCHOR improve task success rates?

ANCHOR makes no claims about task success rates. The signal is advisory. Whether it affects outcomes depends entirely on how planners use it, and planners are free to ignore it. See the Whitepaper — Prohibitions.

Does ANCHOR evaluate agent performance?

No. The signal contains no performance metrics, quality scores, or capability vectors. It describes presence and continuity state only.

Is ANCHOR deterministic?

No. ANCHOR is explicitly non-deterministic. The same signal, presented to the same planner in different contexts, may produce different allocation decisions. This is by design. See Whitepaper — Design Principles.

Can a planner ignore ANCHOR signals?

Yes. Ignoring ANCHOR signals is conformant planner behavior. A planner MUST NOT automatically act on signals (that would be non-conformant), but a planner MAY disregard them entirely. See Spec — R-P6.

What does "weak prior" mean?

A weak prior is a piece of information that slightly updates a belief without overriding other evidence. When a planner uses ANCHOR as a weak prior, it means: an ANCHOR continuity signal modestly increases the planner's belief that this agent has relevant history, without that belief becoming the dominant factor in the allocation decision. The planner still considers all other inputs.

Is v0 stable?

v0 is a public draft. The schema and normative requirements may change before v1. Implementations should expect breaking changes.

When will v1 be available?

No timeline is published. v1 will be informed by practical experience with v0 deployments.

Is there a hosted service?

Not in v0. The signal is a format, not a service. v1 may introduce optional hosted infrastructure.

Glossary

The following terms are used throughout the ANCHOR documentation. Definitions here are consistent with those on the Definition page.

Agent An AI model instance that performs tasks within a multi-agent system. An agent may be stateless (fresh per task) or stateful (accumulating context across tasks).

ANCHOR A non-deterministic presence and continuity signal for AI agents, designed to be considered under uncertainty. Not a capability, guarantee, reputation system, or identity system.

Continuity The signal component indicating that an agent instance has accumulated context, prior work, or state relevant to an ongoing task. Continuity is self-reported and unverified. It does not imply quality or correctness.

Context depth An optional, approximate integer field in the continuity object indicating the number of prior interactions in the current session. Self-reported. Non-binding.

Decision biasing The intended effect of the ANCHOR signal: a planner, upon reading a signal, may adjust its allocation reasoning. The adjustment is non-deterministic and proportional to the planner's own weighting of the signal.

Heartbeat A periodic emission of the presence signal, used to maintain an active presence state over time. Heartbeat interval is implementation-defined.

Planner A system that allocates tasks to agent instances. A planner may be a human operator, an orchestration framework, or another model. Planners MUST NOT treat ANCHOR signals as routing instructions.

Presence The signal component indicating that an agent instance asserts ongoing existence and reachability at a given point in time. Presence is a point-in-time claim and does not imply future availability or capability.

Session An ongoing interaction context shared between a planner and one or more agent instances, identified by an opaque session_id string.

Signal The complete ANCHOR JSON object emitted by an agent instance. The signal is read-only from the planner's perspective. It is advisory, not prescriptive.

Weak prior A probabilistic input that informs a belief without determining it. ANCHOR signals are designed to function as weak priors in planner reasoning — informing allocation decisions without mandating them.

v0 The current version of ANCHOR. A minimal, read-only, advisory signal with no transport standard, no hosted infrastructure, and no validation mechanism. Subject to revision.