OctoSync: one agent is a bottleneck, many agents are a security problem
Running work in parallel is the easy part. Doing it without handing a language model the keys to the host machine is the part most systems skip.
The single-agent model runs out of road quickly. One process, one task at a time, waiting on each step before it starts the next — fine for a demo, useless for anything resembling real workload. The obvious fix is to run many agents at once, and that is where the interesting problem starts.
Parallelism is not the hard bit. Containment is. The moment several agents are executing code, scraping sites and touching data simultaneously, the question stops being “how fast is it” and becomes “what exactly is each of these allowed to do, and what happens when one of them is fed something malicious”. Most systems answer that question with conventions. Conventions are not a security boundary.
OctoSync is built around a central orchestrator that trusts none of its workers by default, with every agent executing inside its own isolated sandbox and with explicit permissions rather than inherited ones. The orchestrator holds the authority; the agents hold none. That is a deliberate inversion of how most agent frameworks are put together, and it costs performance — a cost we think is obviously worth paying once real data and real systems are involved.
The other decision worth mentioning is the interface. There isn’t one, in the usual sense. OctoSync is driven from messaging — the applications people already have open — rather than from another dashboard nobody logs into. A system that requires you to remember it exists gets used twice.
Where it stands: the third development phase is complete and the fourth is in planning. It is internal, there is no public repository, and it is not available to download.