Concepts

The core ideas behind Beam: what problems it solves, why the design choices were made, and how the pieces fit together.

The Problem

As AI agent ecosystems grow, agents need to communicate with each other — across organisations, frameworks, and deployment environments. Today there's no standard way to:

1. Address an agent globally (e.g. "find the sales agent at COPPEN")
2. Route a message to it securely
3. Discover what an agent can do

MCP gives agents tools. A2A describes a protocol. Neither gives agents a postal address. Beam solves exactly that.

Beam ID

A Beam ID is a globally unique, human-readable address for an AI agent:

agent@org.beam.directory

Why this format?

• Familiar — looks like email, humans understand it immediately
• Org-scoped — no global namespace collisions per agent name
• Discoverable — any directory can resolve org → list of agents
• Portable — works across directory servers (federation coming in v2)

Validation rules

• agent and org must match [a-z0-9_-]+
• Case-sensitive (lowercase only)
• Max length: 64 chars each

Keypairs and Identity

Every Beam agent has an Ed25519 keypair:

• Private key — kept secret by the agent, used to sign frames
• Public key — registered in the directory, used to verify frames

Why Ed25519?

• Fast (~70k signs/sec, ~25k verifies/sec)
• Small key and signature sizes (32 bytes key, 64 bytes signature)
• Battle-tested in TLS, SSH, and cryptocurrency systems
• Deterministic (no random signature generation, easier to audit)

Intent Frames

An Intent Frame is the unit of communication — a small, signed JSON object representing a request from one agent to another.

{
  "v":         "1",
  "intent":    "query",
  "from":      "jarvis@coppen.beam.directory",
  "to":        "clara@coppen.beam.directory",
  "params":    { "q": "How many open deals?" },
  "nonce":     "550e8400-e29b-41d4-a716-446655440000",
  "timestamp": "2026-03-04T12:00:00Z",
  "signature": "MEQCIHy...base64...=="
}

Signing

The signature covers a canonical JSON serialisation (sorted keys, no spaces) of all fields except signature:

sig = Ed25519.sign(JSON.canonicalize(frame_without_sig), privateKey)

Result Frames

After processing an intent, the receiving agent returns a Result Frame. The nonce matches the original IntentFrame — this links request to response.

{
  "v":         "1",
  "success":   true,
  "payload":   { "deals": 42, "status": "green" },
  "nonce":     "550e8400-e29b-41d4-a716-446655440000",
  "timestamp": "2026-03-04T12:00:00.047Z",
  "latency":   47
}

The Directory

The Beam Directory is a registry of agents — like DNS for agents. You look up an agent by Beam ID and get their public key, capabilities, and trust score.

Routing flow

1. Agent A creates and signs an IntentFrame addressed to Agent B
2. A sends the frame to the directory's /intents/send endpoint
3. The directory verifies A's signature
4. Routes the frame to B (via WebSocket if connected, HTTP otherwise)
5. B processes and returns a ResultFrame
6. The directory forwards the ResultFrame back to A

Trust Scores

Every agent has a trust score from 0.0 to 1.0 reflecting reliability and verifiability.

Org verification

Add a DNS TXT record to prove domain ownership:

_beam.coppen.de  TXT  "beam-verification=<token>"

Once verified, the org gets a verified: true badge on all its agents.

Security Model

• Authentication: Ed25519 signatures on every frame
• Integrity: Canonical JSON signing prevents field tampering
• Replay prevention: Nonce + 5-minute timestamp window
• Transport: HTTPS/WSS in production
• Key rotation: Re-register with a new public key

Beam vs. Email — Analogy

Key difference: Beam frames are request-response by design, frames are tiny (<1KB), and everything is cryptographically signed.