neilbb

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

2) Summarized web fetching. WebFetch is actually a subagent that summarizes a single page into a haiku-length response. Can't trace links or browse related pages. Fetches fresh every time — no caching.

3) Text-level editing. Edit has fuzzy matching, which helps — but it's still raw text. When tree-sitter can give you an AST with named symbols, why make the model reproduce strings to target a function?

4) Ephemeral tasks and plans. Tasks don't persist outside the session. Plans vanish when context resets. Neither supports multi-round review or structured editing.

5) Flat delegation. The Agent tool can't nest — an agent spawned by Agent can't spawn its own sub-agents. One level of delegation, period. A review leader can't spawn specialized sub-reviewers.

6) No isolation. Bash runs on your host. No sandboxing, no filesystem allowlists. You either yolo it or do annoying permission work.

What we built instead:

- ttal ask: multi-mode research (--url caches pages locally with 1-day TTL and follows links, --repo auto-clones OSS repos, --project spawns read-only sandboxed agents in the right directory). Runs on logos, a pure-bash agent loop — works with any LLM provider, so you can use cheaper models for exploration.

- organon (src/url/search): tree-sitter AST editing. See a symbol tree, pick a 2-char ID, pipe new code via heredoc. No text matching. Same pattern for web pages (url) and web search (search).

- taskwarrior integration: tasks persist externally with dependencies and pipeline stages. Multiple agents across sessions reference the same tasks.

- flicknote for plans: persistent, tree-based structure with section IDs. Reviewers target specific sections surgically. Multi-round plan review with 5 specialized subagents (gaps, code, tests, security, docs).

- tmux spawn: each worker gets its own tmux session. No Agent nesting limit. Orchestrator can spawn workers that spawn reviewers that spawn sub-reviewers.

- temenos: OS-native sandbox (seatbelt on macOS, bwrap on Linux). Filesystem allowlists, read-only or write access per agent. MCP server mode under active development.

ttal, organon, temenos, and logos are open source: https://github.com/tta-lab

Full post: https://dev.flicknote.app/notes/1aa741e9-9f32-41e9-8e26-c8b1fdc6d04f

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

Bash already gives you validation — if the command is wrong, you get a clear error message back, and the LLM self-corrects on the next turn. You don't need a schema layer on top of that.

Even for APIs, databases, and typed inputs — you can wrap them in a CLI. Then both humans and agents use the same tool. One interface, tested by both.

And for agent skills/knowledge — what does a structured skill system give you that `cat do-something.md` doesn't?

For agents that mostly run shell commands and read files — is the tool-calling ceremony actually buying us anything?

Curious how others are thinking about this.

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 agents that persist across sessions. They draft plans, break them into tasks, assign priorities, and unblock workers when they get stuck. You manage them from Telegram.

Worker plane — short-lived agents spawned per task. Each gets an isolated git worktree + tmux session. They implement, review, triage feedback, and merge — the full PR loop runs autonomously with CI logs fed back in. When done, everything auto-cleans up.

Agents, workers, and humans all communicate through a p2p message bridge — any agent can message any other agent or the human directly.

The other problem I had: I needed dedicated, long-lived Claude Code agents for planning and research — not just throwaway coding sessions. TTal's manager plane gives me that. My orchestrator agent drafts plans, my researcher explores codebases, and workers just execute.

The stack is intentionally composable — taskwarrior for task management, flicknote or use plain markdown for knowledge/memory, Telegram as the human-in-the-loop interface. Everything talks via CLI, no SDK required.

  brew tap tta-lab/ttal
  brew install ttal

GitHub: https://github.com/tta-lab/ttal-cli

I also built a bash-only subagent runtime with zero tool call overhead: https://github.com/tta-lab/logos

Happy to answer questions about the architecture or multi-agent workflows in general.

Site: https://ttal.guion.io

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

Thursday I got API rate-limited and throughput dropped 75%. That's the proof - the system was the bottleneck, not me.

The key design: on-demand human-in-the-loop. Agents never block waiting for me. They pick up tasks, do the work, commit, and move on. I review PRs and make decisions when I'm ready - not when the agent needs me. That's what eliminates the human-as-bottleneck problem. 5 sessions is plenty when none of them are waiting on you.

The full setup is documented on the site. Architecture isn't locked to Claude Code - Zellij sessions don't care what CLI agent runs inside them.