Running one coding agent is a tool. Running three or four simultaneously starts to feel like herding — you tab between terminals, lose track of which session is still spinning, and only discover a conflict after two agents have both edited the same file.
A developer recently shared iterm-agents, a small iTerm2 sidebar panel that aggregates session state across Claude Code, Codex, Cursor Agent, Devin, and Kimi Code. Sessions group by Git repo, worktrees fold into their parent, and you can mark tasks complete or search across everything. The core problem it solves is embarrassingly simple: when you have four agent panes open, you shouldn't have to eyeball each terminal to know which one is still running.
That's a local, macOS-only fix. But the underlying need is broader and worth building for: a lightweight, hosted status board and session ledger that any agent — on any machine — can report into.
What the Ledger Actually Needs to Store
Keep it minimal. Each agent session needs a row: a session ID, the agent name, the repo or task it's working on, its current status (running / done / failed), a timestamp, and optionally a short list of files it touched. That's it. You don't need a workflow engine or a message queue — you need a table you can write to from a `curl` call and read from a browser.
SQLite is the right fit here. It's a single file, zero config, and handles concurrent reads without drama. For a handful of agents reporting in every few seconds, it won't break a sweat. VicroCode's SQLite editor lets you inspect and edit that database directly in the browser, which matters more than it sounds — when something goes wrong mid-session, you want to be able to manually correct a stuck "running" status without writing a migration script.
The Backend: A Python HTTP Listener
The reporting endpoint is a small Python server — maybe 60 lines. It accepts POST requests from agents (`/report`), writes the session row to SQLite, and serves GET requests (`/status`) that return JSON. Agents call it with something like:
curl -X POST /ai-market-guide/market/6742/ \
-d '{"session_id": "abc123", "agent": "claude-code", "repo": "payments-api", "status": "running", "files": ["src/billing.py"]}'You can run Python online and host that endpoint directly through VicroCode — no separate server to provision, no cloud account to configure. The endpoint stays live as long as you need it, and you can update the logic without redeploying anything.
One thing worth getting right early: use an append-only log table, not an upsert. If you overwrite rows, you lose the history of what each agent touched and when. Keep the raw event log separate from a `sessions` view that collapses it to current state. That way you can reconstruct the sequence of events after the fact — useful when two agents both report touching `config.yaml` and you need to figure out which one went last.
The Status Board: A Hosted HTML App
The frontend is a single HTML file that polls `/status` every few seconds and renders a table: session ID, agent, repo, status (color-coded), last update, and files touched. No framework needed. A `<table>`, a `setInterval`, and a `fetch` call gets you 90% of the way there.
For AI agent development workflows where you're orchestrating multiple agents across different repos, add a column for the Git branch or worktree. Group rows by repo the same way iterm-agents does — it's the natural unit of work when you're running parallel feature branches.
VicroCode can host and publish that HTML app directly, so you get a stable URL you can bookmark or share with a teammate. The status board becomes a persistent artifact of your workflow, not something that disappears when you close a terminal.
The Friction You'll Actually Hit
A few things that aren't obvious until you build it:
**Agents don't always clean up after themselves.** If a session crashes, its status stays "running" forever. Add a staleness check: any session with no update in the last N minutes gets flagged as "stale" in the UI. You can set N based on how long your longest tasks typically run.
**File lists get noisy fast.** An agent that touches 40 files produces a useless wall of text. Truncate to the last 5 files touched, or only show files that were written (not read). The ledger's job is orientation, not a full audit trail.
**Session IDs need to be injected, not generated by the agent.** If you let each agent generate its own ID, you'll get collisions or orphaned rows when a session restarts. Generate the ID before you launch the agent and pass it in as an environment variable or flag. Then the agent just echoes it back on each report call.
**The endpoint needs to be reachable from wherever the agents run.** If you're running agents on a remote machine or in a CI environment, a locally hosted server doesn't help. Hosting the Python backend on VicroCode means the URL is stable and publicly reachable — agents anywhere can POST to it.
What This Isn't
This isn't a full orchestration layer. It doesn't schedule agents, route tasks, or handle retries. If you need that, you're looking at a different class of tool. What this is: a shared whiteboard that any agent can write to and any human can read. Simple enough to build in an afternoon, useful enough to keep running indefinitely.
The iterm-agents project solves this for one person on one Mac. A hosted ledger solves it for a team, for remote agents, and for sessions that outlast any single terminal window.