Teamora: a team of coding agents with one human merge button
Building- Role
- Architect and reviewer
- Timeline
- 2026 (Active development)
- Status
- In active development (Private repo)
- Stack
- TypeScript · Node.js · PostgreSQL 16 · GitHub Actions
Problem
Coding agents are fast but they hang, loop, take credit for each other's work and leave half-finished runs writing to the repo.
Get in touchWhat I built
A local-first workspace where a Chief of Staff agent runs each project. One agent plans, another reviews the plan, others implement, a reviewer checks the code, and only I can merge.
Get in touchArchitecture diagram
Inside a local-first workspace backed by Node.js and a PostgreSQL 16 task and session ledger, the Chief of Staff agent hands work to the planner agent, then the plan reviewer agent which caught six serious bugs before code existed, then the implementer agents which run under a 45-minute hang watchdog and reaper, then the code reviewer capped at four review rounds, and finally the human merge gate where only the human merges to main. Merged work flows down to GitHub Actions for isolated CI test runs.
Key decisions
- 01
45-minute hang watchdog with same-thread resume
Why: A subagent that goes silent for 45 minutes gets stopped, its leftover child processes are reaped, and the task is resumed in the same thread.
Trade-off: Long-running single steps get interrupted if they don't emit heartbeat events, but one stuck agent can never stall the whole queue overnight.
- 02
Review loops capped at 4 rounds
Why: Capped automated code-review cycles at 4 rounds after one feature spun for 13 rounds.
Trade-off: Forces human escalation if an agent hasn't converged by round 4, but since adding the cap, features pass by round 4—and some on round 1.
- 03
Cryptographic/logged proof of authorship
Why: Work is credited only with proof: session ID, model name, start timestamp, and end timestamp.
Trade-off: Extra bookkeeping on every task transition, but eliminates agents claiming credit for another agent's commits.
- 04
Keeping the Plan Reviewer step
Why: Kept a dedicated plan-review agent before implementation even though it adds latency prior to writing code.
Trade-off: Slower start per ticket, but it caught 6 serious issues before a single line of code existed—including one bug that would have silently wiped a to-do list of owed fixes with no error or warning.
Result
6
pre-code bugs caught in a single plan-review pass
real log proof (opens in a new tab)≤4
review rounds per feature, down from a 13-round runaway
post-mortem thread (opens in a new tab)- [PLACEHOLDER]
[ADD METRIC: features shipped, average review rounds, hours saved]
Demo
[ADD SCREEN RECORDING of a run]