One request, end to end: from a card to the cloud and back

A card computer, an assistant, a compute cell, a mini computer and a server sled joined by one cable that loops back to the card

You are walking to a train with your hands full. You tap the card on your lanyard and say: “Find the three supplier contracts that renew next month, compare their notice periods, and draft the letters for the ones we are leaving.” Twenty minutes later, on the platform, the band on your wrist buzzes. The drafts are ready, one contract has a notice period that ends on Friday, and your assistant wants to know whether to send that letter now or wait until you have read it.

That is one request. Below is the path it is designed to take through the Kyber system, layer by layer, and the places where an ordinary assistant would have let it leak. None of this ships yet; it is the design we are building to.

Why most requests leak

The usual architecture is one call to one model on one server. A device records your voice and sends it to a provider, where it is transcribed, interpreted and executed with whatever permissions the app was given, and the answer comes back. It is simple, and it is the reason everything you say ends up in one place you do not control.

A request like the one above touches contracts, suppliers, dates and money. It is exactly the kind of request you would not want sitting in somebody else’s logs. The fix is not one clever component. It is a path on which every step has a reason to keep from the next step whatever that step does not need.

Where an ordinary request leaks

The microphone is a pipe. Audio leaves the device before anything has decided whether it should. Everything that was said, including the parts that were not meant for the assistant, goes upstream.

The assistant is a front end. It keeps no memory on your side; it looks you up in an account somewhere else. Context about you is fetched from a server rather than held by you.

Agents run with your keys. Once the work is delegated, whatever does it gets broad access to mail, files and accounts, because narrowing that access is hard. One confused step can read or send far more than the task needed.

The system underneath is a black box. You cannot see what else runs next to the work, what it can reach, or what it writes down.

The cloud keeps the receipts. The job is billed to an account with your name, card and address on it, so even encrypted work is tied to you by the paperwork around it.

The path it should take instead

KyberDeck hears. The card transcribes on the device, and nothing leaves it unless a policy you can read allows it. The card is small on purpose; which form does what is argued in the five forms of KyberDeck.

KyberBot decides, and asks when it matters. Your assistant already knows which suppliers you mean, because its memory lives on your devices. It works out what the job needs, strips what it does not, and marks the one step that matters, sending a letter against a deadline, as a step it will ask you about. How it splits work is described in how an assistant hands work to a swarm.

KyberAgent swarms do the work. A planner writes a to-do list. Three sub-agents, one per contract, each start with fresh context, read one document and come back with one report. A fourth drafts the letters from the reports. None of them holds your keys.

KyberLinux keeps each agent in its cell. Every agent runs in a KyberCell whose files are fixed when it starts, whose network is closed except for the one endpoint it needs, and which writes down every step it takes. The system that enforces this is described in how KyberLinux keeps a swarm in its cells.

KyberFusion lends power, paid in tokens. If comparing the contracts needs more compute than your Node at home has free, the work goes out to the network as encrypted cells, settled in tokens and unlinked from your name. What the machine that runs it can and cannot see is the subject of what a node knows about you.

The answer comes back to you. The reports return to KyberBot, the cells are destroyed, and the band on your wrist asks the one question that needed you.

Your data stays yours at every step: on the device whenever it can be, encrypted and unlinked from you in the cloud when it has to go there.

The honest limits

A path with more steps has more places to go wrong. Every handover between layers is an interface that has to be specified, tested and attacked before anyone should trust it. Anonymity in the cloud is a goal the network is built for, not something we can claim before it has been tested. And the small model on a card will not understand everything a large one would. The design accepts that, and sends the hard parts to where they can be done.

A test you can run today

Take one request you made to an assistant this week and trace it. Write down every machine it touched: the device, the service that transcribed it, the one that interpreted it, every tool it called, every account it reached. Next to each, write who owns that machine and whether you could obtain its log of your request.

If you cannot fill in the list, that is the finding. A system you can trust with your work is one where you could. The KyberFusion homepage shows the path we are building for exactly that.