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
Section titled “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
Section titled “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.
hexaeight-activate install-agent→ Identity Agent · Deploy an agent
The engine — your code
Section titled “The engine — your code”This is the part you write. 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.
The router — optional in the architecture, needed in practice
Section titled “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 (step 3).
Worth running when you have more than one agent, or when you would rather your provider key existed in exactly one place.
hexaeight-activate install-routerThe platform — ours
Section titled “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.
The registry — ours, and optional
Section titled “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
Section titled “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 | Yes — you write it | Yes |
| Router | Only if you want one | Upstreams and keys |
| Platform | No | Never |
| Registry | No | Only whether to publish |
Putting it together
Section titled “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 build it: Deploy an agent.