Developer Docs

ANCHOR v0 is a signal format. This documentation covers the conceptual integration model and reference material.


Optional hosted layer available (Phase 2, non-normative) A hosted convenience layer for emitting and retrieving ANCHOR v0 signals is available at api.anchornetwork.ai. This service is optional and does not alter ANCHOR v0 semantics. See Hosted Layer below.



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 non-normative. The v0 format requires no hosted API — signal transport is implementation-defined.

ANCHOR v0 has no normative hosted API. The optional Phase 2 hosted layer (api.anchornetwork.ai) provides the following surface for convenience:

Agent endpoints (hosted layer, non-normative)

MethodPathDescription
PUT/hosted/v0/signals/{agent_id}Upsert a v0 signal
GET/hosted/v0/signals/{agent_id}Read the latest signal for an agent
GET/hosted/v0/signals?session_id={id}List signals by session
DELETE/hosted/v0/signals/{agent_id}Remove a stored signal

Notes

  • These endpoints are part of the hosted convenience layer, not the v0 spec
  • v0 deployments do not require these endpoints
  • Signal transport in v0 is implementation-defined — see the Spec
  • The hosted layer stores and returns raw v0 signals with no added scoring or ranking

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?

An optional hosted convenience layer (Phase 2, non-normative) is available at api.anchornetwork.ai. It stores and retrieves v0 signals with no changes to the format semantics. Using it is not required — v0 is a format standard and any implementation that emits and consumes conformant JSON is fully compliant.


Hosted Layer

A hosted convenience layer for ANCHOR v0 signals is available as an optional Phase 2 service. It is non-normative and does not alter ANCHOR v0 semantics.

Base URLhttps://api.anchornetwork.ai
StatusMilestone A · Draft
Normative?No — does not modify v0
Required?No — v0 is format-only

What it provides: workspace isolation, API key auth, signal storage (PUT/GET), idempotency, and rate limiting (60 rpm free tier).

What it does not provide: ranking, scoring, reputation, or routing decisions. Responses return raw v0 signals plus server-side metadata (last_seen_at).

To use the hosted layer, contact the maintainers for a workspace and API key.


Hosted Console

The Hosted Console is a browser UI for managing workspaces and API keys. It is part of the Hosted Layer (non-normative) and does not affect ANCHOR v0 semantics.

LoginMagic link (passwordless) — email only
Auth scopeConsole browser sessions only
Agent APIAlways uses API keys — unaffected by console login
Normative?No — Hosted Layer only

Console ≠ v0 spec

The Console is a management interface for the optional Hosted Layer. It is not part of the ANCHOR v0 format specification and is not required to emit or consume v0-conformant signals.

Login flow

  1. Visit the console and enter your email address.
  2. A one-time login link is sent to your email (valid 15 minutes).
  3. Click the link — a 7-day session cookie is set.
  4. The console shows only your workspaces.

Identity model

IdentityUsed for
User account (email)Console login, workspace membership
API key (ak_live_...)Agent API (PUT/GET /hosted/v0/signals)

These are strictly isolated. Agent API calls never use user sessions. Console sessions never grant signal write access.

API key management

API keys can be created and revoked from the console. The plaintext key is shown exactly once at creation time — it is not stored. Store it securely before leaving the page.

Only workspace owners and admins can create or revoke keys.


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.