Architecture

You have met the pieces in the start path. This is how they fit together, and what happens when a single request arrives.

The approach

Every system built this way does the same two things: it secures a connection, and it hands out a secret that stands in for you. TLS protects the pipe; an API key, a certificate or a bearer token proves that whoever holds the string was trusted at some point in the past.

HexaEight does neither. It gives every party an identity and secures the message.

That sounds like a small distinction. It is not, and five things fall out of it that the conventional stack cannot offer at all.

Identity is proven per message, not per connection. There is no session to hijack and no token to steal, because there is no bearer credential. Successfully decrypting a message is what proves who sent it — that is not a check performed after the fact, it is a property of the message existing.

Nothing has to be issued, rotated, or revoked. No certificate authority, no signing requests, no renewal calendar, no revocation list, no public-key directory to keep in sync. Two identities that have never met derive a shared key when they need one.

You can encrypt to someone who does not exist yet. Address a message to a person who has never heard of HexaEight, or an agent nobody has built. When that address is later registered, it can be read. Nothing in the certificate or OAuth world can do this — there is nobody to look up and nobody to authorise.

We are not in the path of your data. The platform issues keys and does nothing else. It never sees ciphertext, never relays a message, never holds plaintext. The working algorithm is published with sample values so you can verify that claim rather than believe it.

You can know what software is calling, not just who. Every message identifies the executable that produced it, derived by the library rather than claimed by the sender. An approved identity running a modified binary is a case you can refuse — a distinction no API key or certificate can draw.

And then there are agents

All of that would matter for ordinary services. It matters more now, because the thing calling you increasingly is not a service. It is an agent: autonomous, acting for a person who is not present, possibly calling other agents, possibly running code you did not write.

And an agent is not a chat window in front of a model. It runs on a machine and does real work — reading files, running commands, touching systems that exist. Which means it has to be somewhere, it has to hold credentials to reach a model, and something has to decide what it is allowed to do.

That is the shape the architecture below is built for.

The architecture

Here is the whole thing. One request, from the moment it arrives to the moment it is answered.

Every arrow is encrypted and proves who is at the other end. Read the rest of this section and that picture should stop needing explanation.

The agent is a hub, and the engine is where work actually happens.

Everything converges on the agent — a person directly, an application with a person behind it, another agent with its own person behind it. Whoever arrives, the agent proves who they are and decides what they may do.

Below it sits the engine, and this is the part usually left out of diagrams like this. An agent is not a chat window in front of a model. The engine runs on a real machine and does real work — reading files, running commands, touching systems that exist. That is why an agent has to be somewhere rather than being a hosted endpoint.

The round trip nobody draws

When the engine needs a model — and it usually does — it does not call the provider itself. It goes back through the agent, out to the router, and the answer returns the same way.

The loop is the important part. An agent does not ask a model once and hand the answer back. It works, asks, reads the answer, works again — as many turns as the job takes. The user hears nothing until the engine has finished; the model never speaks to the user directly.

That looks like a long path until you ask what each hop buys.

The engine holds no provider key — it asks the agent, so a compromised engine leaks nothing. The agent applies policy on the way out as well as in, so an engine cannot quietly call a model it was not meant to. The router holds one copy of the key for every agent you run. And the identity chain survives the whole trip: the router knows which agent asked, and the agent knows which person it was for.

Route the engine straight to the provider and all four properties are gone at once.

Agents on different machines

Everything so far happened on one machine. The interesting case is two.

An agent on your laptop needs to reach an agent in someone else’s data centre. Conventionally that means a broker in the middle — a message bus, a SaaS relay, a queue — and now a third party carries your traffic and has to be trusted with it.

There is no broker here. The agents talk directly.

The dotted lines happen once and carry no payload. The solid lines are your data, and they go nowhere except between the two agents.

Being reachable without opening a firewall

An agent on a laptop has no public address, so the agent solves that for you. reach decides how it is reachable and publishes the result:

Mode	What it does
cloudflared	Spawns a tunnel and reads back the URL it was assigned
tailscale	Reachable on your private network
ngrok	Spawns a tunnel
local	Publishes this machine’s LAN address
none	Publishes nothing — the agent makes calls but accepts none

Reach is a setting, not a command. In hexaeight-agent.json:

"reach": { "mode": "cloudflared", "bin": "/path/to/cloudflared" }

Every key is in the settings reference.

No port forwarding, no inbound firewall rule, no static IP. The agent registers the URL it ended up with, and re-registers periodically so a dead agent’s address expires rather than being served forever.

Why a tunnel does not weaken anything

This is the part worth pausing on. A tunnel provider now carries your bytes — and it does not matter, because the bytes are already end-to-end encrypted between the two agents.

The tunnel sees ciphertext. So does anything else on the path. Neither the tunnel provider, nor the registry, nor HexaEight can read a message or alter one without the recipient noticing.

That is the practical payoff of encrypting the message rather than the connection: you can use whatever gets the packets across, including infrastructure you do not control, and it changes nothing about who can read your data.

What the registry does and does not do

It maps a name to a URL, like DNS. An agent publishes where it can be found; another agent looks it up.

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

Next

• Identity — where identities come from
• Identity — where identities come from
• Dead Drop Encryption — the primitive underneath
• Deploy an agent — build one