Skip to content

Components

Six things. Most people deal with three.

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

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

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.

Terminal window
hexaeight-activate install-agent

→ Identity Agent · Deploy an agent

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.

→ Bring your own engine

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.

Terminal window
hexaeight-activate install-router

→ LLM Router

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

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

ComponentDo you run it?Do you configure it?
AuthenticatorOn your phoneCreate a vault once
AgentYesYes — policy, engines
EngineYes — you write itYes
RouterOnly if you want oneUpstreams and keys
PlatformNoNever
RegistryNoOnly whether to publish

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.