Components

Six things. Most people deal with three.

Solid lines are your data. Dotted lines carry no message content at all.

The Authenticator — your phone

Where a person’s identity lives. It holds a vault, and the vault issues the resources that agents take.

You use it twice: once to create an identity, and again whenever you approve something — a licence, or a browser app asking to talk to your agent.

You need this before anything else works. → The Authenticator · How identity is issued

The agent — your machine

A single self-contained binary. It holds an identity, proves who is calling, applies your policy, and hands work to your engine.

It is the only component that has to be running for anything to happen, and everything else is optional around it.

The installer sets it up.

→ Architecture · Installing

The engine — the harness, or your code

The engine does the work. Every agent ships with one, the harness, so there is nothing to write. You can also put your own behind an agent: a process that takes a message and returns a reply:

the agent runs:   your-engine -p "<the message>" [--resume <session id>] …
and reads back:   {"result": "…", "session_id": "…"}

Any language, because it is a process rather than a library binding — you declare the argv and which JSON fields carry the reply. It is where the actual work happens: reading files, running commands, calling systems.

The agent supplies identity, encryption, sessions and policy. You supply the capability.

→ Bring your own engine

The router — optional in the architecture, needed in practice

Holds your model provider keys so your agents do not have to. Agents reach it with a proven identity and it forwards to whichever provider you configured.

It is optional in the sense that nothing in the design requires it: an engine that does its own work and never calls a model needs no router at all. But if your engine calls a model, you need one today — no provider yet serves an LLM endpoint that accepts a HexaEight identity directly, so something has to hold the provider’s API key, and the router exists so that it is never your agent. That may change as adoption spreads; until it does, treat the router as a step rather than a choice. The installer sets one up with your provider key.

Worth running when you have more than one agent, or when you would rather your provider key existed in exactly one place.

→ Run your own router

The platform — ours

It issues keys. That is the entire list.

It never sees ciphertext, never relays a message, never holds plaintext. Your traffic does not pass through it. The algorithm is published with sample values so this is checkable rather than a promise.

You never install or configure it. An agent talks to it when it needs a key for a recipient.

→ Dead Drop Encryption

The registry — ours, and optional

A phone book. An agent publishes the URL where it can be found; another agent looks it up by name.

It never sees a message. Remove it and agents that already know each other’s addresses keep working — you lose discovery, not communication.

→ Agents on different machines

What you actually touch

Component	Do you run it?	Do you configure it?
Authenticator	On your phone	Create a vault once
Agent	Yes	Yes — policy, engines
Engine	Built in (the harness), or your own	Only if it is your own
Router	Yes — the installer sets one up	Your provider and its key
Platform	No	Never
Registry	No	Only whether to publish

Putting it together

The smallest useful system is an agent plus an engine, with an identity from the Authenticator. Everything else is added when you need it: a router when keys should live in one place, the registry when other agents need to find you.

Now see how they fit together — one request, end to end.

Or skip ahead and install it: Installing.