Claude Code ships with Bash, Read, Write, Edit, Glob, Grep, WebFetch, Task, Plan. For a single agent on a single task, they're fine. Once you're running a multi-agent system, the defaults break fast.The problems we hit:1) No cross-repo exploration. Want an agent to read another project's code? You need to manually configure permissions. There's no "go explore this OSS repo and answer my...
2. The manager never blocks. She helps me dump tasks into taskwarrior and route them. Since the manager plane is a mesh with p2p communication, no single agent becomes a bottleneck. Each designer connects to 1 or more workers in a star topology, and when workers get blocked, they alert the designer directly rather than waiting.
3. Pane looks interesting. How are you embedding the terminal into the desktop app? Is it a PTY wrapper or something like xterm.js?
In my setup there are two planes — manager and worker. On the manager plane, all primary agents form a mesh with p2p communication. Each designer connects to 1 or more workers in a star topology, since workers may have questions or get blocked while executing a plan.
The limitation of the built-in agent tool is it doesn't allow nested subagent spawning. But it's normal for a designer or researcher to need subagents — when a plan is done, I use a plan-review-leader agent to review it. If you try mother → planner → plan-review-leader → plan-vs-reality-validator, the nesting gets deep fast and blocks your manager from doing other work.
I wrote a blog post about this yesterday: https://dev.to/neil_agentic/ttal-more-than-a-harness-enginee...
What I'm exploring now:
1. How to convert tokens to value more efficiently
2. How to orchestrate a large LLM team instead of babysitting one session
3. How to parallelize work and make sure nothing blocks others
4. How to accelerate both productivity and quality control
5. How to make the system evolve itself
To achieve these, it requires much more skill and knowledge, not less.
Most agent frameworks use structured tool calling — JSON schemas, tool_call_id tracking, provider-specific APIs. But for bash-heavy agents, the LLM can just write `$ ls -la` as plain text. You scan for the prefix, execute it, feed output back, repeat.No schemas, no JSON parsing, no provider lock-in. Works with any model that outputs text. Multiple commands in one response with zero...
I built TTal because I got tired of babysitting Claude Code sessions. Every PR meant switching between windows, copy-pasting review feedback, telling the coder what to fix, and repeating until it merged. I wanted to manage all of this from my phone while doing other things.TTal is a Go CLI that orchestrates multiple Claude Code sessions in a two-plane architecture:Manager plane — long-running...
https://ttal.guion.io gets updated daily with guides. Still incomplete, but shows the actual patterns.
If you want to dive deeper or integrate this into your workflow: [email protected]
The key difference: on-demand human-in-the-loop. Agents never block waiting for you. They pick up work, execute, commit, and exit. You make decisions asynchronously when ready.
This eliminates the biggest bottleneck in agent systems—the human becoming a serial dependency.
Proof isn't in benchmarks or simulation. It's 706 commits shipped in 5 days using standard tools (Taskwarrior, Zellij, Claude Code). System got rate-limited, not me.
Site: https://ttal.guion.io706 commits, 38 PRs merged, 5 repos, 5 days. One person with max 5 Claude Code sessions.The stack: Taskwarrior as the task queue, Zellij as the session manager, Claude Code as the worker. Each CC session runs in a Zellij pane with a task assigned. When a session finishes, the next highest-urgency task auto-starts via Taskwarrior hooks. You manage tasks, not...