HN user

aceelric

33 karma
Posts13
Comments15
View on HN

Anthropic just shipped Agent Teams for Claude Code (https://news.ycombinator.com/item?id=46902368). I've been building the same thing independently for months, but with a different architecture that solves the two biggest problems people flagged in that thread: file conflicts and quality.

Their approach uses file locking. Tasks have to be file-disjoint or agents overwrite each other. CAS uses git worktrees instead. Each agent gets its own full copy of the repo on its own branch. Three agents can edit the same file simultaneously and the supervisor merges everything back. No locks, no file-disjoint constraint.

The other problem: agents that say "done" when they're not. CAS has verification gates. Workers self-verify before closing (no TODOs, code is wired up, tests pass). Tasks enter pending_verification and workers can't claim new work until it clears. This was born out of pain. Without it, agents mark tasks done while leaving half-connected code everywhere.

GitHub: https://github.com/codingagentsystem/cas Website: https://cas.dev

How it works

`cas` launches a TUI with a supervisor. You give it an epic and it takes over: analyzes the tasks, figures out the right implementation phases based on dependencies, determines how many workers can run in parallel without file conflicts, and spawns them. Each task gets a demo statement describing the observable outcome ("User types query, results filter live"). This was the single biggest quality lever I found. Without it, agents default to building layers of plumbing that never connect to a working feature.

For inter-agent messaging, we reverse-engineered Claude Code's Team feature to build a push-based SQLite message queue. The previous version injected prompts by writing raw bytes into the terminal multiplexer. It worked, but barely. Now the supervisor sends a message and the worker's next MCP call picks it up. Clean and reliable.

Workers claim tasks via a lease system (renewed by heartbeat) to prevent double-claiming. The supervisor reviews completed work, merges the branch, syncs remaining workers, and assigns next tasks.

The TUI has side-by-side/tabbed views, session recording/playback, desktop notifications, and detach/reattach. Terminal emulation uses a custom VT parser based on Ghostty's.

Persistent context

CAS also runs as an MCP server (55+ tools) so agents remember things between sessions. 4-tier memory inspired by MemGPT. Rules that earn trust (Draft > Proven > Stale) and auto-sync to .claude/rules/. Full-text search via Tantivy BM25. Everything local in SQLite.

What's hard

Agent coordination is a distributed systems problem wearing a trenchcoat. Stale leases, zombie worktrees, agents that lie about completion. We've added heartbeats, verification gates, and lease expiry, but supervisor quality still varies with epic complexity. The honest answer is this is an ongoing arms race.

Getting started

curl -fsSL https://cas.dev/install.sh | sh cas init --yes && cas

~235K lines of Rust, 17 crates, MIT licensed. Happy to answer questions.

I’ve been experimenting with a similar pattern but wrapping it in a “factory mode” abstraction (we’re building this at CAS[1]) where you define the spec once after careful planning using a supervisor agent then you let it go and spin up parallel workers against it automatically. It handles task decomposition + orchestration so you’re not manually juggling tmux panes

[1] https://cas.dev

Problem with skills is that agents have to load the entire skill for them to use it, or you could break down big skills into multiple smaller ones, which is just a hassle compared to cmcp.

With cmcp you get to use all thr available mcps, while still not bloating context.

Kudos to the guy for building such an awesome project in a very short amount of time. Of course he had to take some shortcuts to deliver, but at the end of the day, OpenClaw remains one of the best open source AI assistant implementations.

I’ve been using Fly for my new startup that offers notifications as a service [1], and the whole setup is super easy and efficient.

Since fly deploys at the edge closer to the users, our response times for notifications are 20ms on average which is mind blowing since I haven’t spent more than 1 hour on infrastructure setup.

1: https://usenative.com