Meetless Agent Tracks Coding Agents

Meetless Agent is a solo founder’s Show HN project, posted as Active Source of Truth for Your Coding Agents, that gives developers one place to watch multiple coding-agent sessions. It deals with 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 work 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 should intervene.

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, Anthropic’s coding agent, 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.

The trap is treating 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 an observability problem

Developers cared about the project because it frames parallel coding agents as an observability problem, not a vibes problem. If an agent can edit, test, and open a pull request, then you need the same shape of visibility you expect from background jobs: status, logs, outputs, and alerts.

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.”

The trap is making 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 understand several agent runs 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.

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.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Practical starter checklist

- [ ] Name the Claude Code artifact first: a hook boundary, an MCP permission note, a slash-command workflow, a Claude skill outline, a review checklist, or a concise CLAUDE.md note when repository memory is the topic.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• How should teams start with Claude Code?

  Start by writing down one visible team rule for Claude Code, not a loose preference. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Claude Code artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a hook checklist, MCP permission rule, slash-command workflow, skill outline, or concise CLAUDE.md note. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Claude Code teams deciding which hook, skill, MCP boundary, slash-command workflow, review habit, or repository-memory convention to standardize next around “Meetless Agent Tracks Coding Agents.”
• Best first artifact: turn the named fix into a hook checklist, skill note, MCP permission note, review receipt, or concise CLAUDE.md convention when repository memory is the real topic before the next automated run.
• Best comparison angle: compare the workflow against the current Claude Code handoff, hook behavior, and MCP scope; keep the path that leaves the shortest auditable trail.

Further reading

• Active Source of Truth for Your Coding Agents — source
• Claude — Agent
• Model Context Protocol — specification
• developers.google.com: fundamentals creating helpful content

Where to go next

Start from the related training topic and make the first exercise prove scope, verification, and ownership in the PR body.