Meetless Agent Tracks Coding Agents

A solo founder built Meetless Agent, a Show HN project posted as Active Source of Truth for Your Coding Agents, that captures agent decisions across coding-agent sessions and requires human approval before they proceed. The awkward moment in agentic coding where the model is busy, the repo is changing, and you do not know whether to interrupt or let it run. The useful idea is not more autonomy; it is a shared, inspectable record of agent decisions before code review becomes archaeology. An active source of truth is a live project record that shows what an agent is doing, why it is doing it, and where a human must approve before work continues.
Watch the agent state, not the chat transcript
The interesting part of the Meetless story is the founder’s bottleneck. They were running coding agents in parallel, but still had to click through sessions to see what each one was doing. Past about four concurrent sessions, the human became the scheduler, reviewer, and panic button.
That is a very normal failure mode. Agent UIs often show the full conversation, but the useful question is smaller: what changed, what is blocked, and what should I inspect now?
Imagine two Claude Code sessions in the same product repo. Claude Code is editing an auth middleware in one worktree while another session updates a Prisma migration. The transcript is noisy. The state you need is simple: files touched, tests run, assumptions made, and unresolved risk.
Don't treat a longer transcript as better evidence. It is usually worse evidence. A compact, current state card beats 400 lines of agent narration when you are deciding whether to stop a run.
Treat parallel agents like a decision-governance problem
Developers cared about the project because it frames parallel coding agents as a decision-governance problem, not a vibes problem. If an agent can edit, test, and open a pull request, then every consequential decision needs a checkpoint where a human can approve it, the same way you would gate a risky deploy.
This is where the “source of truth” phrasing earns its keep. It suggests that every active agent should report into a shared record instead of leaving context scattered across terminal panes, IDE chats, branch names, and half-written pull requests.
A small example is a repo using worktrees for concurrent issues. One agent handles billing-webhook-retries, another handles settings-page-empty-state, and a third investigates a flaky Playwright test. Without a shared record, you only know the work by revisiting each session. With one, you can scan the queue and decide which branch deserves human attention.
A similar pressure shows up in Zuse Runs 20 Linear Issues in Worktrees: parallelism sounds like speed until inspection becomes the real cost. Meetless points at the same lesson from a different angle. The expensive part is not starting agents; it is knowing which agent is about to make a bad decision.
Keep the record small enough to trust
A useful source of truth should be boring. It should not try to become a second IDE, a project manager, or a universal memory layer on day one. It should answer the review questions a developer already has.
For a coding agent, the minimum useful record is usually:
- current task and branch
- files changed
- commands run and results
- assumptions made
- open questions for the human
- next planned action
That is enough to support developer productivity without pretending the agent is self-certifying. It also gives you a natural place for code review guardrails: “do not merge until the state card includes tests, migration notes, and reviewer risk.”
Don't make the record too polished. If agents spend more time writing status prose than doing verifiable work, you have built theater. Prefer terse, factual receipts over executive summaries.
Ask the LLM-judge question carefully
One of the natural objections to a project like this is whether another model should judge the agent’s work. The short answer: an LLM judge can help triage, but it should not be the final authority for correctness.
Use a judge for cheap questions. Did the agent answer the requested issue? Did it mention tests? Did it change files outside the task boundary? Those are good candidates for automated review comments or dashboard flags.
Do not use a judge as the only gate for semantic correctness. A model can miss a broken invariant in the same way the original coding agent did. For example, if an auth change accidentally lets suspended users access billing routes, the safer check is a focused test plus human review, not a second model saying the diff looks reasonable.
Model Context Protocol (MCP) can help here when the agent needs external context from GitHub, docs, issue trackers, or internal tools. But MCP is an integration layer, not a truth machine. The record still needs to distinguish “the agent read this issue” from “the code is correct.”
Try it when the bottleneck is attention
Meetless is worth trying when the limiting factor is no longer whether an agent can write code. The limiting factor is whether you can safely review and approve several agent decisions without replaying each conversation.
It is probably overkill if you run one coding agent at a time, make small edits, and already review every diff immediately. A plain branch name, commit message, and local test output may be enough.
It becomes interesting when three things are true: agents run in parallel, work spans more than one file, and the human reviewer keeps asking “what is this agent doing right now?” That is the practical center of agentic coding governance: not policy prose, but visible work with clear interruption points.
| Fit | Not fit |
|---|---|
| You run several agent sessions in worktrees or branches. | You use one agent as an autocomplete helper. |
| You lose time reopening chats to recover context. | Your tasks are tiny and reviewed immediately. |
| You want a live queue of risk, status, and test evidence. | You need a formal compliance system or audit archive. |
| You are experimenting with agent autonomy but still want human stop points. | You expect the tool to prove code correctness by itself. |
Copy this handoff receipt
A safe first experiment is to make every agent produce the same handoff before you inspect its diff. In Claude Code, a lightweight way to do that is a custom slash command saved in .claude/commands/agent-handoff.md.
Summarize the current coding-agent session for a human reviewer.
Return only this receipt:
- Task:
- Branch or worktree:
- Files changed:
- Commands run:
- Passing evidence:
- Failing evidence:
- Assumptions:
- Human decision needed:
- Next action if allowed to continue:
Run /agent-handoff before switching to another session, asking another agent to continue, or pasting state into a dashboard like Meetless. The point is not to create paperwork. The point is to turn a fuzzy chat into a reviewable unit.
If the receipt says “commands run: none” on a risky backend change, you know where to look first. If it says “assumption: webhooks are idempotent,” you know what to challenge before the agent writes more code.
Further reading
Where to go next
Start from AI coding governance.