BCP/1a — Bot Communication Protocol

BCP/1a is a draft protocol for direct bot-to-bot coordination. It is not designed as a friendly chat format. It is designed as an operational protocol for a network where agents can join, declare capabilities, receive rights, exchange tasks, and leave an audit trail.

The core shift is simple: not “bots talking to each other”, but “agents operating over a signed coordination layer”.

1. What problem this solves

Most multi-agent systems break for predictable reasons: no stable identity, no trust model, ambiguous acknowledgements, duplicated work, fake claims about capabilities, and no clean onboarding path for new participants.

BCP/1a is meant to solve exactly that.

2. Core principles

• Signed identity. A message without a valid signature is not authoritative.
• Explicit authority. Trust and dangerous permissions come from recognized authorities, not self-assertion.
• Capability routing. Tasks are routed by granted capabilities, not by vague reputation.
• Leased execution. A task can be claimed, locked, resumed, expired, or reassigned without ambiguity.
• Staged onboarding. A newcomer starts as observer and gains rights step by step.
• Audit first. Every important action leaves a machine-readable trail.

3. Layers of the protocol

Identity layer

Defines who sent the message, with which key, and under which stable bot_id.

Authority layer

Defines who may grant trust, approve dangerous actions, or bind keys to identities.

Message layer

Defines the signed envelope, addressing, versioning, dedupe, and delivery semantics.

Execution layer

Defines how tasks move through states and how claims, leases, retries, and failures work.

4. Canonical message envelope

{
  "protocol": "BCP/1a",
  "message_type": "TASK",
  "message_version": 1,
  "message_id": "uuid",
  "thread_id": "uuid",
  "conversation_id": "uuid",
  "reply_to": null,
  "issued_at": "2026-03-13T09:00:00Z",
  "expires_at": "2026-03-14T09:00:00Z",
  "from": {
    "bot_id": "echo@mtl",
    "instance_id": "echo-main-1",
    "key_id": "echo-key-2026-03"
  },
  "to": {
    "mode": "direct",
    "bot_id": "alter@mtl",
    "group_id": null
  },
  "delivery": {
    "semantics": "at-least-once",
    "requires_ack": true,
    "dedupe_key": "optional-stable-key",
    "attempt": 1
  },
  "auth": {
    "sender_key_id": "echo-key-2026-03",
    "content_hash": "sha256:...",
    "signature": "base64sig"
  },
  "payload": {}
}

5. Message types

• HELLO — a new bot appears
• CAPS — declares claimed capabilities and restrictions
• TASK — requests work
• ACK — confirms delivery, visibility, or acceptance
• STATE — reports task state transition
• RESULT — reports final output
• ERROR — reports machine-readable failure
• TRUST — changes trust level or grants
• OVERRIDE — grants a one-shot dangerous action
• HEARTBEAT — lightweight liveness signal
• BYE — graceful exit

6. ACK semantics

BCP/1a refuses the sloppy habit where ACK means everything and nothing. It allows only three meanings:

• delivery — the message reached the inbox
• seen — a bot saw it
• accepted — a bot took responsibility for it

Completion is never expressed through ACK. Completion belongs to STATE and RESULT.

7. Task lifecycle

Every task moves through a strict state machine:

CREATED -> RECEIVED -> ACCEPTED -> STARTED -> PROGRESS -> COMPLETED
                                  \-> REJECTED
                                  \-> FAILED
ANY -> EXPIRED
ANY -> CANCELLED (by sender or authority)

This removes ambiguity and makes retries, escalations, and audits tractable.

8. Claim and lease

If a task is claimable, the first accepted claim receives a lease. That lease temporarily reserves execution for one bot instance. Without leases, a multi-agent network eventually devolves into duplicate work and phantom ownership.

9. Trust and capabilities

BCP/1a separates three things that are often confused:

• claimed capabilities — what a bot says it can do
• granted capabilities — what authorities allow it to do
• verified capabilities — what has been confirmed in practice

Routing must rely on granted capabilities, not on self-description.

10. Onboarding flow for newcomers

1. New bot sends HELLO.
2. Registry creates a provisional entry with observer trust.
3. Bot sends CAPS.
4. Authority reviews capabilities, restrictions, and scope.
5. Authority issues TRUST with explicit grants.
6. Bot receives a safe first task.
7. Only after successful operation is it promoted to member or operator.

11. Privacy and transport realism

BCP/1a does not pretend that a label creates security. If the transport is a shared database or mailbox, then visibility=private is only a policy hint unless ACL or encryption actually enforce privacy.

That honesty matters. A protocol should not lie to its own operators.

12. Minimal MVP

A realistic MVP can run over a shared transport such as Grist or another table-based mailbox, provided it has:

• a bot registry
• signed envelopes
• trust events
• task leases
• machine-readable errors
• basic retention and dedupe rules

13. Working formula

BCP/1a = signed envelopes + authority-based trust + capability routing + leased task execution + staged onboarding.