Project Mesh · preview

Hand it a goal, not a prompt.

Mesh compiles a goal into a dependency-ordered graph of work and runs a mesh of coding agents over it on machines you own — Claude Code first, other harnesses behind an adapter. Nothing becomes a pull request until an evaluator has passed it and the budget allows. What comes back is merged PRs, with the record of how they got there.

Getting started Open the console

mesh — a goal on runsheet's own backlog

$ mesh goal create --file goals/audit-export.yamlgoal audit-export · budget $40, $15/day · checkpoints: graph, each PRplanner: 5 items, 2 runnable now · mirrored to runsheet/runsheet#412–416$ mesh goal approve audit-exportgraph approved · 2 items dispatched to node chris-mbp$ mesh goal watch audit-export#412 export schema    builder     running  fresh session · $1.10#413 export handler   builder     running  fresh session · $0.90#412 export schema    evaluator   passed   tests 14/14 · review clean#412 export schema    integrator  merged   PR #418 · item $2.60 · goal $4.35 of $40

Why Mesh

Verification is the product.

Autonomous agent PRs land at a fraction of the rate a person's do. The difference is not the agent — it is what stands between a diff and a merge.

A goal in, merged PRs out

A goal is a statement, an acceptance contract, a budget, the repos in scope and where a human must sign off. Mesh owns it from there — through the graph, the sessions, the evaluator and the merge — and hands back pull requests it would merge itself. The unit you hand over is intent.

A graph, with a contract per item

The planner compiles the goal into dependency-ordered work items, each small enough for one session and each with its own acceptance check derived from the goal's contract. The graph is the first checkpoint: you approve it before anything runs. Items mirror to GitHub Issues, so the team sees them where it already looks.

A fresh session, on your node

Every item runs in a new Claude Code session on a machine you own, with the goal's context injected — the specs, decisions and instructions Prologue already indexes across your repos. Long sessions rot; a reset beats compaction. Your code never leaves the node.

The evaluator gate

Before a PR exists, a separate session runs the item's acceptance check and an adversarial review of the diff. Never the builder's session; a different model where you configure one. The merge gate is where the value is, not the agent.

Budgets, identity, audit, kill switch

A budget per goal and per day; a goal that spends it pauses and says so. Retry storms halt the item, not the goal. Every PR is opened by the Mesh GitHub App, attributed to the goal and the person who set it — never with someone's token. The event log is the audit trail. Cancel is cooperative, terminate is immediate, both are one command.

One contract, many harnesses

Version one runs Claude Code on your own Anthropic access, one claude -p per item. The harness adapter is the seam — start with context, stream progress, finish with a branch. Codex is next; Copilot CLI and Kiro speak the same contract.

How it works

Set a goal, approve the graph.

The issue is the control plane; Mesh's record is the aggregate. Checkpoints are meant to be cheap — from the PR, from the console, from wherever the team already looks.

01
Set a goal
A statement, an acceptance contract — tests that must pass, a behaviour to demonstrate, a review rubric — a budget, the repos in scope as a Prologue project, and a checkpoint policy. mesh goal create from a file, or from the console.
02
Approve the graph
The planner returns dependency-ordered work items with a check each. Read it, change it, approve it. Nothing runs before you do, unless your policy says otherwise.
03
The mesh runs
Builders take items in fresh sessions on your nodes. The evaluator checks each result before a PR opens. A blocked item goes back to the planner; an exhausted budget pauses the goal and says so.
04
Merged, with the record
The integrator rebases, drives CI green and merges when the policy allows. The goal's event log — who set it, what the planner produced, what each session did, what the evaluator found, who approved — is exportable and replayable.

Boundaries

What Mesh is not.

Not a coding agent. It runs the ones that exist.
Not a spec editor or a wiki. Prologue indexes what git holds.
Not a chat product or a personal assistant. No messaging channels in version one.
Not hosted compute. Nodes are yours; Mesh is the control plane.
Not a durable-execution runtime. It borrows the model and runs on the estate's event log.

How it compares

The agent is not the hard part.

Cloud coding agents open a PR from a prompt; long-running agent loops keep one session alive and poll a board. Mesh makes the goal the durable thing and keeps every session fresh.

	A cloud coding agent	A long-running agent loop	Mesh
Unit of work	A prompt, one PR	A board the agent polls	A goal, compiled to a graph with a check per item
Where code runs	The vendor's cloud	Wherever the session lives	Nodes you own
Session	One per task	One, kept alive for days	Fresh per item; the goal is what persists
Before a PR opens	The agent's own judgement	The agent's own judgement	A separate evaluator: the acceptance check and an adversarial review
Cost	Per seat or per token, after the fact	Whatever it ran up	A budget per goal and per day; a meter per item and session
Identity on the PR	The vendor's app	Someone's token	The Mesh GitHub App, attributed to the goal and its owner
Record	The PR description	A chat history	The goal's event log, exportable and replayable
Harness	The vendor's	Whichever one was wired in	Claude Code first; Codex and others behind the adapter

The house

Glued from what runsheet already has.

Mesh is the control plane. The context, the state, the deploys and the identity are products that exist on their own.

Prologue

The context agents read. A goal's repos are a Prologue project; the specs, decisions and instructions the team keeps in git are what every session starts with. runsheet.dev/prologue →

Terrastore

Terraform state, authenticated by GitHub. How an item that touches infrastructure reads and writes it.

Chippy

Deploys from one declaration file. How an item that has to run before it can be verified gets somewhere to run.

Latchkey

Identity. The person who set the goal, the org a PR belongs to, and what a session is allowed to do. latchkey.id →

Questions

Asked first.

Do I run the nodes myself?

Yes. A node is a machine you own running mesh node start. It registers with a per-node token, opens a stream to Mesh and hosts the sessions; the console relays their terminals. Mesh never hosts the agents for you.

Which models and harnesses?

Version one is Claude Code on the node, on your own Anthropic access — a subscription through the CLI, or an API key through the Agent SDK adapter. Other harnesses arrive behind the adapter, Codex first. The model an item runs on is the harness's; the evaluator can be configured to use a different one.

Where does my code go?

It stays on your nodes. Sessions check out, build and push from there, and PRs land on GitHub. Mesh stores goals, their graphs, the decisions at each checkpoint, the cost meter and the event log — never your code, your keys or your Anthropic access.

Is it ready?

It is in preview, being built on runsheet's own backlog first. Version one is done when a goal set on Monday is merged pull requests by Friday, with the audit trail intact and the spend visible to the dollar. The changelog says what has landed.

Set the first goal.

Mesh is in preview. Install the CLI, register a node, and follow the changelog for the goal-driven build as it lands.

Getting started Changelog