> **TL;DR:** Six weeks of running forty-three Claude Code and Codex sessions through Tightbeam, Mike Manzano's open gateway that records every agent claim, review, and ruling in one ledger instead of chat logs. Covers the four-word model (work item, assignment, claim, verdict), the nobody-approves-their-own-code rule, statutes compiled into harness hooks, the ATC and TopLines views, and the real cost: credential rotation on a Mac, a database that grew to 1.39 GB and crashed the gateway, and fourteen of the fifteen open issues being the author's. Try it if you already run several agents and own an always-on box.

This spring I got good at a job I never wanted. I'd leave a few coding agents running, come back an hour later to walls of text and tool calls, and spend the next twenty minutes running a standup with each one. What were we doing here, did you hit any problems, did you get it done. Most of the time I skipped the transcript and went straight to the outputs, because whether the thing works matters more than how we got there. The agents were fine. They had done their jobs. I had lost track of what each one was doing, and the only record was a chat log, which has no idea of "done" and no way to answer "what needs me" without reading the whole thing.

I'd been down this road once already. [Gastown](https://github.com/gastownhall/gastown) worked for a while, very expensive, and it taught me what orchestration should look like. Yegge himself says it "[fell apart at the seams with Opus 4.7](https://simonwillison.net/2026/Aug/4/steve-yegge/#:~:text=Gas%20Town%20fell%20apart%20at%20the%20seams%20with%20Opus%204.7)." For me it evolved into cmux and then [Herdr](https://herdr.dev/), tools for being a faster orchestrator, and that still wasn't the job I wanted.

Since late July I've been running my agents through [Tightbeam](https://github.com/clickety-clacks/tightbeam), which fixes the standup problem and, on purpose, not much else. It's a server you install like a database. Every coding agent you run plugs into it, and everything they claim, review, or ask for gets written down in one place. So I can always answer "what did they do, and what's waiting on me" without reading a transcript. The code is public on GitHub, my friend [Mike Manzano](https://x.com/bffmike) built it, and I contribute to it.

Right now it runs forty-three agent sessions for me across Claude Code and Codex, on a Linux box in my office. Cursor works too, on my fork, and hasn't shipped in a release yet. The org has one human in it, and that's me.

## It runs your agents like a company

Tools like OpenClaw give you one capable assistant. Tightbeam is what that assistant works inside. The README's line for it is "[it is the difference between hiring a brilliant freelancer and owning a company](https://github.com/clickety-clacks/tightbeam#:~:text=It%20is%20the%20difference%20between%20hiring%20a%20brilliant%20freelancer%20and%20owning%20a%20company)." Agents join as staff. Each one is a real session in its vendor's own tool, Claude Code or Codex, which I'll call the harness from here on. Tightbeam hands them tickets, gives each piece of work a reviewer that didn't write it, enforces the rules you write, and keeps a paper trail behind every claim. You install it "[the way you would a database](https://github.com/clickety-clacks/tightbeam#:~:text=the%20way%20you%20would%20a%20database)."

I wasn't looking for a boss. If anything, Gastown's mayor agent didn't boss the agents enough early on: it lost track of the work and needed prodding. What I wanted was something that kept track. Tightbeam keeps track and refuses to orchestrate. Claude Code and Codex have gotten good at running their own subagents, tracking their own tasks, and firing their own hooks, and they keep getting better at it. An outside orchestrator that keeps its own idea of what a session is has to duplicate all of that, and then the two disagree, and the bugs live where they overlap. Tightbeam uses what the harnesses already do. The project's design corpus, published in mid-August, calls it "[a patchbay between chat clients and coding-agent harnesses](https://github.com/clickety-clacks/tightbeam-design/blob/main/tightbeam.md#:~:text=A%20patchbay%20between%20chat%20clients%20and%20coding%2Dagent%20harnesses)" with "[nothing in the middle that thinks](https://github.com/clickety-clacks/tightbeam-design/blob/main/tightbeam.md#:~:text=nothing%20in%20the%20middle%20that%20thinks)." It routes messages, records claims, and enforces rules, and anything that needs judgment stays in the agents. They meant it. An earlier feature let Tightbeam settle disputes between agents. It livelocked production, and they [deleted 5,700 lines of it the day they adopted that principle](https://github.com/clickety-clacks/tightbeam-design/blob/main/adjudication-deletion-amendment.md).

Under the hood it's one Elixir process with a SQLite database and a git repo the gateway creates on first boot to hold every agent's identity, meaning the role templates, guidance, and rules each agent is built from. Changing who an agent is means a commit, and agents only ever read the published branch. The gateway talks to each agent, on whatever machine you pointed it at, over [ACP](https://agentclientprotocol.com), the agent protocol that came out of Zed, so it never scrapes a terminal or forks a harness. Adding a second machine takes one command, and it doesn't need a daemon. sshd is the transport, and credentials never leave the host that owns them.

The whole product is forty-five commands, all listed on [one help screen](https://github.com/clickety-clacks/tightbeam/blob/main/cli/src/args.rs) (the output of `tightbeam --help`), and there's no separate console for the human. Most of the time I talk to one agent, an exec, whose job is to drive those commands for me, as me. Most agent frameworks have a management layer the agents themselves can't use. Here the exec runs the same commands the coders and reviewers run, so when I ask it what the org is doing, it's reading the same record they write to.

## No model grades its own homework

The reason a standup can't tell you what's done is that "done" is whatever the agent last said. Tightbeam replaces that with four words: work item, assignment, claim, verdict. A work item is the ticket. An assignment is one job in one session's hands. As the session works, it files short claims against that assignment: made progress, done, or giving up. Done is only a claim. A verdict is a separate claim, and it has to come from a session other than the one that did the work. Tightbeam never judges whether the work is good. It counts which claims have been filed and by whom, and every status view is computed from that count. There's no percent complete anywhere. In a status meeting we all accept "I'm about 20% from done" as if it were a number, when all anyone knows is that you're close. There's nothing in the record to make that number up from.

Rules act on those claims. The one that matters most is the rule every engineering team already has: nobody approves their own code. In the [shipped rule set](https://github.com/clickety-clacks/tightbeam/blob/main/priv/kungfu/agentic-engineering/rules/engineering.toml) it reads [finishing a coding assignment requires one review assignment, held by a different session, with a clean verdict](https://github.com/clickety-clacks/tightbeam/blob/main/priv/kungfu/agentic-engineering/rules/engineering.toml). When an agent claims done without one, it doesn't get refused. Tightbeam assigns a reviewer and holds the claim until the review lands. The agent doesn't have to remember the rule. It claims done, and done arrives later with someone else's name on it.

The rule only says the reviewer has to be a different session. My own habit, from orchestrating by hand, is stricter. A Claude coder gets a Codex reviewer and a Codex coder gets a Claude one, because two models from the same vendor learned the same things and miss the same things, and a review is only worth having if it's a second mind. I haven't taught Tightbeam that habit yet. Nothing stops me, since the rules can say it, but out of the box the vendor is a preference and the default list starts with Claude for code review. My orchestrator agents went ahead and did it anyway, and I found out by reading the record. In early September one of them handed a Claude fix to a Codex reviewer. The reviewer didn't take the fix on faith. It pulled the fix out, watched the check fail, put it back, and only then signed off. On another piece of the same project, the first review caught a real bug where two parts of the code met, the coder fixed it, and the second review came back clean. Every one of those steps is in the record with the reviewer's name on it. That's the difference between a review and an LGTM on a pull request nobody ran.

## Some rules an agent can't talk its way past

Rules run inside Tightbeam and act on claims. Statutes are a separate mechanism, for the things an agent shouldn't be able to do at all, and they live one level closer to the agent. They run inside the harness itself and act on individual commands before they execute. A statute is a few lines of TOML that compile into a Claude Code hook and a Codex hook. The [shipped example](https://github.com/clickety-clacks/tightbeam/blob/main/docs/statutes.toml.example) is `no-push-main`, a regex on a tool call. When an agent runs `git push origin main`, the hook denies the call before it executes and hands back the statute's own text: "Pushing to main is forbidden: work lands on branches; the operator merges." It applies to whichever model is working, and it adds nothing to any model's context. The design doc's line is "[the agent learns the law by hitting it, never by reading it](https://github.com/clickety-clacks/tightbeam-design/blob/main/tightbeam.md#:~:text=the%20agent%20learns%20the%20law%20by%20hitting%20it%2C%20never%20by%20reading%20it)." I'd been through the whole progression before Tightbeam: repeating myself in prompts, then moving the rules into CLAUDE.md and AGENTS.md, then into skills, and finally building guardrails so that if the model forgot, it didn't matter. Statutes are that last step, shipped.

The project turned that into a test strategy too: "[the RAILS ARE THE JUDGE](https://github.com/clickety-clacks/tightbeam/blob/main/docs/EVALS.md)." Run a scenario against a gateway with the statutes loaded. If the agent's instructions lead it into a denied command, that denial is the failing test, and no rubric or judge model is involved.

## The agents page me when they need me. The rest waits until I ask.

All of that machinery exists so I can stop running standups. When an agent hits something only I can rule on, it files a decision request. Filing one doesn't pause anything; the agent still owes what it owed. If the request is a blocker, it pushes a notification to my phone right away. Everything else waits in a digest. A few times a day I ask the exec what's waiting on me, either inside the org or from a Claude Code session outside it that loads a small plugin wrapping the Tightbeam CLI. It reads the record and comes back with the three or four things that need a ruling. I rule with a required rationale, from a laptop or the phone, and the ruling goes into the record too.

The night I moved the org onto its new machine, I went to bed with three streams of work open. The morning brief said all three had finished everything they could without me and been reviewed clean, and it ended with "Production untouched, verified 05:26." The agents had stopped on purpose at the one step that needed root, because that step was mine. Stopping there was a burden some mornings, since it meant setting up new permissions and boundaries before anything could move, and I was glad it waited for me until I understood what could go wrong. The record told me exactly what the agents had and hadn't touched, and I didn't have to read a transcript to believe it. I did read one, that first morning. It matched.

[In February I argued](https://www.georgediab.com/posts/2026/the-dark-factory) that verification, not generation, is the bottleneck now, and that the teams who win will be the ones that build evidence systems. Tightbeam is the first evidence system I've run. The argument since then has been about software factories, with Dex Horthy saying "[the lights off factory does not work](https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/wsff.md#:~:text=the%20lights%20off%20factory%20does%20not%20work)" and PostHog answering that [it works once agents get the same production context a product engineer has](https://www.linkedin.com/pulse/can-software-factories-actually-work-posthog-aefqc/). Tightbeam sits under both. It's the record either kind of factory would need, whichever side of that argument you land on. And in [The Agents Are Idle](https://www.georgediab.com/posts/2026/the-agents-are-idle) I wrote that AI doesn't reduce your cognitive load, it concentrates it. What's left for the human is the stack of hard decisions plus reviewing everything. Six weeks in, Tightbeam has me working that stack instead of the busywork underneath it, and the busywork was most of my day.

The last thing I use it for is building its own tooling. I wanted the org's state as a sortable table, so I wrote [a spec and a brief addressed to an AI product owner](https://github.com/gdiab/tightbeam-toplines), hired that product owner with three shell commands, and it staffed and built the thing. It's not only my org. About thirty-eight commits on Tightbeam's own main branch are authored by the project's agents, under names like `tightbeam coder` and `Codex Retirement Guard`, and the two newest commits on main today are agent merges, which anyone can check in ten seconds. The README claims it "[improves itself unasked](https://github.com/clickety-clacks/tightbeam#:~:text=improves%20itself%20unasked)."

![Tightbeam TopLines. Open work items, the session roster by role, queued messages, and decisions waiting on the owner, laid out as a table.](/posts/running-an-organization-of-agents-through-tightbeam/tightbeam-toplines.png)

## The board shows only what the record can prove

The table answers "what's waiting on me." For "what is the whole org doing right now," there's [Tightbeam ATC](https://github.com/clickety-clacks/tightbeam-atc), a live 3D view of the org: a single HTML file plus three.js, reading the database without ever writing to it. I [posted a recording of it in August](https://www.linkedin.com/feed/update/urn:li:activity:7497782330405568512/), so here's the short version. Discs below the grid are agents, arranged by who spawned whom and colored by how recently they acted. Solids above the grid are work items, and height is how much of the required proof is still missing. An item drops a band as each piece gets filed (progress, tests, completion, independent review, a clean verdict) and turns from red to green on the way down. The README's rule is "[Nothing is estimated. Where the ledger cannot answer a question, the view says unknown rather than guessing](https://github.com/clickety-clacks/tightbeam-atc#:~:text=Nothing%20is%20estimated)."

![Tightbeam ATC. Agents are discs below the grid, work items are solids above it, and height is how much of the required proof is still missing.](/posts/running-an-organization-of-agents-through-tightbeam/tightbeam-atc.png)

Agents can drive the display through a small API: point at a node, pin a tag, draw a labelled arrow, or narrow the board to a set of items. That last one has to be named, and the board refuses a search without a name. The IDs say what matched. The name, something like "everything blocking the 0.1.8 cut," says what the agent was asking, and an hour later the name is all I read when deciding whether to reopen it. When my agent asks the board what I'm looking at, it gets three fields back (selected, focused, and the open decision), and the docs warn that a human's bare "this one" almost always means selected, and "answering about the wrong one is the most common way to be confidently useless." I don't say "this one." What I say is "I have a question about the items I've selected," and now my agent answers about those, which matters more to me than the 3D. My own addition on top of the board is a desk: open decision requests show up as a list I can rule from, with the rationale required and an audit log behind it.

## What it cost me

I don't want to oversell any of this. The public repo is six weeks old, it's two people and a couple hundred agents, and I have been the beta program.

The first wall was credentials, and it took me a week to see that it was really a wall about where the thing runs. I installed on my laptop because that's where my harnesses already lived. Claude Code rotates its login token about every eight hours. Tightbeam kept its own copy, so every eight hours that copy went stale and I had to onboard again. The org shipped [the fix](https://github.com/clickety-clacks/tightbeam/pull/19) itself after a week of that. Underneath it was a problem no fix could solve: a daemon on a Mac can't read the login keychain at all, and GitHub auth and Cursor broke the same way. So the org moved to a Linux box that stays on, with fifty-odd agents running, after a rehearsal on a copy. I was the first person outside the project to run it, so some of these lessons were mine to find. This one you can skip. Start on an always-on machine you own, onboard the harness credentials there, and treat your laptop as a client from day one. The part I haven't solved is that I'm still the one carrying every secret to the box, which makes me the bottleneck the software was meant to remove. The fix is designed but not built.

The second wall was the database. It grew to 1.39 GB in two weeks. Part of that was a leaked test client that made 286,000 calls as me over two days. Part was a sweep writing twenty thousand empty entries an hour ([issue #23](https://github.com/clickety-clacks/tightbeam/issues/23)). I didn't know either was happening until reads started queuing behind the single database connection, timeouts cascaded, and [the gateway itself crashed](https://github.com/clickety-clacks/tightbeam/issues/10). A cleanup took it to 164 MB in under a minute. Both issues are still open, and it regrows.

After that the failures came one at a time. The review rule I praised above [deadlocks rebase-heavy merge chains](https://github.com/clickety-clacks/tightbeam/issues/18). It froze one of my pipelines for about twenty hours, and I carried a one-line local patch for two releases. A published release once shipped without its database update and crash-looped on my data. Killing the harness connectors around a restart locked both of them out, with no command to let them back in, so I edited the database by hand. And in early September a cleanup routine inherited the wrong environment and killed production. While debugging that one I found that `tightbeam-gateway --help` boots a real gateway. I have filed [sixteen issues](https://github.com/clickety-clacks/tightbeam/issues?q=author%3Agdiab). Fourteen of the fifteen open issues on the repo are mine.

When the gateway came back after that crash, every agent knew its state and what it had been doing when it died, and picked up from there. Gastown had a version of the same idea with beads, its work ledger. After a failure the agents need their own history to restart from, and I'd call that non-negotiable now.

## Try it if you already run several agents and own a box you can leave on

This works today if you run at least two coding-agent harnesses, you have a machine that stays up, you're comfortable reading a boot log, and what you want from it is the record more than the convenience. It breaks if you want it on a laptop that sleeps, or if you need it stable on a deadline. This is frontier software. If you like tinkering, now is a good time. Give it a quarter before betting a team on it.

The install path is a release tarball, and `npm install tightbeam` does not exist. From the [releases page](https://github.com/clickety-clacks/tightbeam/releases), download the tarball for your platform (macOS arm64 or Linux x86_64) and the checksums, verify, then `npm install -g ./tightbeam-<version>-<os>-<arch>-<commit>.tgz`. You need `claude` or `codex` on PATH first; if it can't find one, startup fails and says so. Then create the first user and run `tightbeam onboard` for each provider. Being logged into Claude or Codex yourself doesn't count, because Tightbeam needs its own copy of the credentials. Run `tightbeam learn agentic-engineering` to install the default roles and rules, send the org's first agent (it's called Main) a hello, and install the gateway as a service. That last step needs root and a human, and the README says so in capitals. My suggestion is to put an agent on the install with you. Same if you want it gone. There's no `tightbeam uninstall` yet, so ask an agent to tear it down and clean up.

The gateway repo has no license file yet. Nobody decided that; the repo isn't ready for a wide release, and the license lands when it is. ATC and TopLines are already MIT. Until the gateway has one, read it and run it, and hold off on redistributing it.

If a client or team wants the shape without the software, the ideas travel without it. You can keep durable tickets, give every change a reviewer from a different vendor than the writer, and write your rules as hooks instead of prompts.

## Contributing today means filing a good issue

There's no real path for a new contributor yet. There's a [CONTRIBUTING file](https://github.com/clickety-clacks/tightbeam/blob/main/CONTRIBUTING.md), and it documents how releases are cut (two release lines, numbered builds, fixes moved between lines only by deliberate cherry-pick), not how a stranger gets a first pull request merged. There are no issue templates and no good-first-issue queue. So file issues, and make them good. The existing ones set the bar; every title names a mechanism and a consequence, like "[completion-requires-review structurally deadlocks rebase-heavy merge flows](https://github.com/clickety-clacks/tightbeam/issues/18)." File them on [the gateway repo](https://github.com/clickety-clacks/tightbeam/issues), or on [ATC](https://github.com/clickety-clacks/tightbeam-atc/issues) for the board. The reasoning behind all of it is in the [design corpus](https://github.com/clickety-clacks/tightbeam-design), frozen mid-August. Pull requests are open as well, taken as they come, though that could change if the volume ever becomes overwhelming. Most of the open issues are mine, and I'd like some company.

If you try it and something breaks, I'd like to hear about it. I'll answer questions, and if you want a walkthrough over a call I'll do that too. [Reach me here](https://georgediab.com/about), or go straight to the source: Mike is [on X](https://x.com/bffmike).

## The software will change. The record won't.

There have been eight releases in three weeks, and the CLI has already outrun the design corpus, which still says there's no `unlearn`. Expect everything above to look different next month, including the parts I praised.

Tightbeam writes down every claim an agent makes and who checked it, and I read that record instead of the transcripts. Its rules hold because hooks block the command and a reviewer that didn't write the code checks it, with no prompt doing the enforcing.

Every entry from the last six weeks is exactly as it was filed, who held what and who reviewed it, plus every ruling with the rationale I had to type. This spring I ran a standup with every agent, every time I sat down. I don't do that anymore.