Mesh Engineering

Many AI agents work at the same time, check each other's work, and leave a record of every step.
There is no designated reviewer. Every agent is both a worker and a reviewer of other agents' work.
Agents talk through asynchronous channels such as issues (task tickets), PRs (code change requests), and shared rule documents instead of live conversation.

Work piles up one issue at a time.
One agent takes each issue and leaves a mark saying "I have this." Other agents see the mark and skip that work.
The agent implements in its own workspace and opens a PR.
The authoring agent never verifies its own result. A fresh model from a different company comes in and reviews the result critically.
Testing agents actually use the app to find problems. A problem one agent finds only counts once another agent reproduces it.
A PR that passes review and testing merges (joins the main code) right away without waiting for other PRs.
When an agent finds a problem unrelated to its task, it does not fix it directly. It files a new issue, and another agent picks it up later.

Before merge, a model different from the author reviews the code.
Before merge, a testing agent confirms the actual behavior.
After merge, any agent that touches that code again and finds a problem files an issue.
A reviewer is created fresh for each task, so review queues never form as work grows.

The reasoning behind a decision goes in the PR description.
Rulings where a human said "don't do this" accumulate in a file. When the same proposal comes up again, the agent reads that file and stops on its own.
When a human points out a mistake, the agent fixes the rule document on the spot. The next agent works under the corrected rule.
Every conversation and work log is kept. If one agent stops midway, another reads the record and takes over.
Before asking a human, an agent first searches past records for an answer to the same question.

No conductor decides what to build or what passes. Agents read the shared record, take work, and finish it on their own.
Review attaches fresh to each task, and other agents keep checking after merge.
Memory lives in records outside the agents, so it carries on when agents change.
New work comes more from problems agents find while working than from assignments handed down.

The order in which a single agent works is fixed (take, implement, review, test, merge). The inside of one task is closer to a graph, and the relationships between tasks are the mesh.
Some roles do exist, one that launches an agent for each issue and one that orders access to shared resources. Neither decides code content or whether to merge.
Speed comes from the number of tasks running at once. A single task may take hours, but merges happen often because many tasks merge without waiting on each other.
There are costs too. Mechanisms that keep two agents from taking the same work, rules for sharing resources, and upkeep of rule documents are always needed.
Humans leave rules and rulings, and answer questions only humans can decide, such as cost, production data, and security.

There is an existing term, stigmergy. It describes individuals deciding their next action from traces left in the environment instead of direct instructions to each other.
In mesh engineering, issues, PRs, and rule documents serve as those traces.

Backlinks1