neilbb

also wrote a note about ttal's multi-agent patterns: https://dev.flicknote.app/notes/5a95cdcd-bb63-4eb6-9961-7007...

just wrote a note about ttal's multi-agent patterns: https://dev.flicknote.app/notes/5a95cdcd-bb63-4eb6-9961-7007...

1. Windows users would need WSL. Currently focusing on macOS and Linux.

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?

using a single plan-reviewer would be slow when there are multiple aspects to review. That's why a local star topology with a plan-review-leader is needed: it spawns multiple reviewers in parallel, each focused on a different aspect.

Yeah the pipeline runs effectively and I'm able to be in the loop when the loop needs me.

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...

The problem isn't "skill atrophy" — it's which skills matter more in a changing world. If LLMs genuinely do something better, let them do it and focus on what they do badly.

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.

If you impl this as a backend and connect to Telegram bots, agents can just do `$ ask "Should I do this?"` for agent→human and `$ alert "this thing blocked me"` for coder→planner. That's what I'm actually doing — I have 1 manager + 3 designers + 1 researcher + 2 debugger + 1 communicator + any number of temporal coders/reviewers in my setup, all connected to taskwarrior for task-driven-dev

Yes. I've built hook scripts, Claude Code skills, and OpenClaw agents to make this work.

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: neil@guion.io

Thanks, I really need to hear that :) The pace isn't sustainable if I'm sleeping 3-4 hours. Need to actually prioritize rest—can't maintain this if I burn out.

I believe this is the most pragmatic approach for real production-ready multi-agent software engineering. Most frameworks are either theoretical or over-engineered—they try to automate humans away instead of augmenting them.

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.

See https://ttal.guion.io. The daily-update guide is the best intro to how it actually works and how you can integrate it into your own workflow.