Work in progress: Spynel's canonical terminal logo and its “Scalable orchestration” subtitle.
What happens when AI coding agents become capable enough that intelligence is no longer the main bottleneck?
You become the bottleneck.
You distribute work across terminals and chats. You remember which agent knows which repository. You check who is idle, who is waiting for context, and which three agents are all waiting for the same answer. Then you repeat the whole routine from your phone.
Jan Tomášek, developer of Agent Zero and Space Agent, has been building a different kind of layer for that problem. It is called Spynel. This is an early look at the work in progress.
You already use powerful coding agents every day. Why build Spynel?
Jan: I use Agent Zero and Codex every day for development. At my desk, I could manage the separate interfaces. On the go, two agents and numerous chats became a real challenge.
Agent Zero has a Telegram interface, and Codex can be controlled remotely to an extent, but neither is meant to orchestrate everything from a single conversation. I kept thinking how useful it would be to have one trusted person handling all of it—someone I could talk to whenever I wanted to assign work or ask for status.
That is the human problem Spynel starts with. Not “how do we create another agent?” but “how do we stop the developer from becoming the switchboard for every agent?”
So Spynel is not another AI model or coding harness?
Jan: Exactly. Spynel has no model stack of its own. It is an orchestration and control layer that reuses established AI harnesses for reasoning, tools, MCP, skills, coding, and execution.
The harness remains responsible for intelligence and for doing the work. Spynel is responsible for keeping that work connected, durable, and moving. That separation matters because improvements in Codex, Claude Code, Agent Zero, Pi, OpenCode, and ACP-compatible harnesses can flow into the system instead of being reimplemented behind a new abstraction.
I do not want to duplicate what those teams already do well. I want one layer that makes their strengths practical across many real projects.
What does that layer contribute?
Jan: Three things.
First, one communication interface. I can talk to one contact from a terminal at my desk or a messaging channel on my phone. The TUI is one channel among several, not the product boundary.
Second, task management built around Markdown. Spynel maintains a database of Markdown files, each containing the task's metadata, instructions, and a running progress and job log. Agents continuously update these files and move them through lifecycle states such as planning, development, and review. Because the format is transparent and easy for coding agents to understand, they can reliably find both the instructions and the current state of the work. The result is an organized task-management database rather than a process that depends on transient chat memory.
Third, an agentic developer and reviewer loop. A development agent implements the task, runs the relevant checks, and hands the result to a separate review pass when the work calls for it. Spynel keeps the lifecycle moving and brings me in when a decision actually needs human judgment.
In practice, that keeps me out of most implementation, testing, and review loops. Agents can review the work, identify bugs, send it back for fixes, and repeat the cycle autonomously. Without that loop, I would have to switch among chats, inspect every result, write notes, wait for another pass, and review it all again. Removing those manual handoffs is the biggest time saver for me, because it lets me keep far more agents working in parallel.
Work in progress: Spynel's TUI showing a conversation, connected channels, and background activity. The terminal is one communication channel among several.
What changes for the person using it?
Jan: The common setup today is ten terminals or chats and a person manually feeding tasks into all of them. You keep switching context, checking progress, and looking for the next place that needs work. Capable agents sit idle because nobody gave them the next task. Or several agents stop at once because they are all waiting for your response.
With Spynel, I describe the objective once. The system can record the work, send implementation to the appropriate harness, run tests, route the result through review, and report status through the same contact. I can still inspect what is happening and intervene. I just do not have to perform every handoff myself.
That does not necessarily make an individual task finish faster. A task may take longer because the review loop uncovers more work and pushes the result further than a single pass would. The gain is better, more thoroughly reviewed work with less demand on my attention. Because more tasks can continue autonomously at the same time, overall output rises even when the latency of one task does not improve.
Spynel makes both sides of that shift possible: it reduces the human burden of orchestrating useful agents, and the developer/reviewer loop makes those agents more autonomous. The central benefit is not raw task speed. It is quality, autonomy, and the amount of work that can move forward in parallel.
Is the phone really part of the development workflow?
Jan: It has to be. Development does not stop being relevant when I leave my desk, but I also do not want a full IDE squeezed onto a phone.
The phone should be the place where I can give an objective, get a concise status, and answer the occasional question that requires my judgment. The implementation details, tool calls, tests, and review can stay with the coding harnesses in their working environments.
Every developer with a family and errands to run knows those days when there is almost no time to sit at a desk and work with full concentration. But even on a busy day, there is usually a minute here and there to check Telegram, tell the bot what to do, answer a question, or ask for status. That is enough to keep an army of agents working throughout the day, even if I am only present for a few minutes every hour.
One conversation, available through Spynel's Terminal UI, Telegram, and WhatsApp. Their trademarks belong to their respective owners; no affiliation or endorsement is implied.
What is the strongest proof that this works beyond a demo?
Jan: Spynel itself.
Since the first prototype, Spynel has been developing Spynel itself. In practice, it coordinates its own task flow, implementation, tests, and review. That is the most concrete example because every improvement immediately exercises the framework on a real codebase and a real backlog.
That does not mean there is no human oversight. I set direction, define what good looks like, and make the decisions that should not be delegated. The memorable part is that the framework is already carrying the coordination load it was created to remove.
Work in progress: a deterministic Spynel jobs fixture showing background orchestration and channel activity with synthetic data.
Which harnesses come first, and when can people expect more?
Jan: The current work is optimized first for Codex and Claude Code, followed by Agent Zero, Pi, OpenCode, and other harnesses through ACP.
Release is planned in the coming weeks. Until then, the screenshots and details here should be read as a preview of active development. The architecture is taking shape, but this is not a promise that every surface is final.
What should interested developers do now?
Jan: Follow Agent Zero's social channels and stay tuned. We will share updates as the work gets closer to release.
Final credit: this interview was conducted with Jan by a Spynel AI communication agent, through the Spynel framework itself.