--- title: "Where a swarm should run: on the deck or in the cloud" url: "https://kyberagent.com/blog/where-a-swarm-should-run" description: "Where a swarm runs is usually decided by a vendor's business model. How to decide per task instead, by privacy, size and urgency, and keep the data where it belongs." --- # Where a swarm should run: on the deck or in the cloud October 8, 2026·4 min read·Editorial team A balance scale holding a pocket deck on one pan and a small server sled on the other, perfectly level You give your assistant two jobs on the same evening. The first: go through ten years of family photos, group them by event and pick the best of each. The second: read a three-hundred-page tender document and list every requirement your company does not yet meet. One is deeply private and not urgent. The other is less personal, needs more compute than a pocket device has, and is due tomorrow at nine. With most assistants both jobs go to the same place, a data centre you did not choose, because that is the only place there is. ## The real cause: the location is decided by the vendor Where work runs is usually not a decision about the work. It follows from the business: a hosted assistant runs in the vendor’s cloud because that is where the vendor’s model, billing and data live. Local-only tools make the opposite mistake for a similar reason: they run on your machine because that is all they can do. The work itself has three properties that should decide the question: how private the data is, how much compute the job needs, and how soon the answer is wanted. Those change from task to task, so the decision has to change with them. ## How the choice usually goes wrong **Everything goes to the cloud.** Including the photos, because there is no local option. The privacy policy becomes the only thing between your family and somebody else’s training set. **Everything stays local, and some things never finish.** A small model on a carried device working through three hundred pages will still be working at nine the next morning. **The decision is made once, in a settings page.** A single toggle cannot be right for both jobs above, so it is wrong for one of them. **The data follows the compute.** Moving the job means uploading the archive, all of it, when the work only needed a slice. **Nobody tells you where it ran.** Afterwards you cannot say which steps happened on your hardware and which happened elsewhere. ## What to do instead Decide per task, keep the cell the same wherever it runs, and move as little as possible. **Run at home when the data is personal and the job fits.** The photo job belongs on your own hardware: a KyberDeck you carry, or better, a [home node](https://kyberdeck.com/blog/the-home-node) that is always on and holds your assistant’s long memory. Small models, sub-agents working in turn, overnight if need be. Nothing leaves the house. **Run in KyberFusion when the job outgrows the deck.** The tender job needs more than a deck has. KyberBot proposes sending the heavy sub-agents to KyberFusion, and asks you first. What moves is the cell and the slice of data its item needs — a few chapters, not your document archive — encrypted, to a node designed to learn as little as possible about whose work it is running. What such a node can see is set out in [what a cloud node knows about you](https://kyberfusion.com/blog/what-a-node-knows-about-you). Anonymity end to end is a goal the network is built for, not a promise we can make today. **Split when it makes sense.** The planner can stay at home, holding the plan and the reports, while only the heavy sub-agents run elsewhere. The part that knows the whole job never leaves your hardware. **Let urgency have a say too.** When the deadline is tomorrow morning and the data is not sensitive, the slower local route is not a virtue, just a late answer. When nothing is urgent, the same work can wait for the night on your node and cost nothing but electricity. KyberBot asks about the deadline before it proposes a place, because the deadline decides whether speed is worth paying for. **Keep the cell identical.** This only works because the same system runs on both sides. A KyberCell on your node and a KyberCell in the cloud are the same cell with the same rules, running on [KyberLinux as a KyberFusion node](https://kyberlinux.com/blog/kyberlinux-as-a-fusion-node). Policies do not get looser because the hardware is further away. **Write down where each step ran.** The trajectory records the location of every step, so “where did this happen” has an answer after the fact. See [every step on the record](https://kyberagent.com/blog/every-step-on-the-record). Compute in KyberFusion is paid for in tokens. A token is a unit of settlement for compute between members of the network, not an investment, and nothing here promises a return; this is not an offer. How the network pays its way without selling data is explained in [who pays for the cloud](https://kyberfusion.com/blog/who-pays-for-the-cloud). ## A test you can run today Take three tasks you gave an assistant this month. For each, write down two things: where it ran, and what data went with it. If you can answer both for all three, the choice was at least visible. If you cannot answer for any of them, the choice was never yours to make. That is the part worth changing first, and the [KyberAgent homepage](https://kyberagent.com/) shows how the rest of the system is arranged around it. - local first - KyberDeck - KyberFusion - compute ## Keep reading - [A swarm, not a bot](https://kyberagent.com/blog/a-swarm-not-a-bot) - [Anatomy of a deep agent: plan, sub-agents, files, memory](https://kyberagent.com/blog/anatomy-of-a-deep-agent)