A reviewer that watches first
Meshly Build can now review the work its agents produce.
A reviewer reads the actual changes a task made, judged against a charter you write, and returns a verdict. That verdict is recorded on the task and shows on the board.
It ships switched off. When you turn it on, it starts in record-only, where it writes down what it would have decided and moves nothing. That is the part worth explaining.
What the reviewer is given
A review is only as good as what the reviewer was shown. So what it is shown is something you decide, per project, in a charter.
A charter names what the reviewer reads and what it has to answer. The diff, cumulative or since the last round. The task's acceptance criteria, checked one by one. Verdicts from earlier rounds on the same task. Knowledge and decisions relevant to the work. What the task depends on.
The point of writing it down is that not all work deserves the same reading. A schema migration and a change of wording should not be reviewed to the same depth, and until you can say so, they are.
Charters are written in the interface. The one that ships with the product stays as it is, and a charter a project is currently using cannot be deleted out from under it.
Record only, then acting
Every project starts in record-only. The reviewer runs, forms a verdict, and the verdict is recorded. Nothing moves. Tasks reviewed this way are marked as such, worded so it cannot be mistaken for approval, and you can filter the board by it.
You read those verdicts against your own. When it agrees with you often enough for long enough, you switch that project to acting and the verdict starts moving the task.
We could have shipped it acting by default and let you turn it down. Watching a reviewer agree with you before you let it decide anything is the entire reason to have the choice, so it is the way round we chose. Every project starts in record-only, including projects that already had review switched on.
When it disagrees
A rejected task goes back for another round with the reviewer's reasons attached. You set how many rounds to allow. After that the task stops and waits for a person, which is the outcome the whole thing is arranged around rather than a failure of it.
Individual tasks can skip review entirely with a label.
What it does not do
The reviewer does not replace the human gate, and switching it on does not remove one.
Approving work is a person's act. An agent cannot sign off work, its own or anyone else's, unless it carries an explicit mandate to review that specific task, which only this process issues and which expires. When you approve or reject something the reviewer already ruled on, the interface says you are overriding it, so signing off is never something you do without knowing a machine disagreed.
Planning tools where planning happens
Separately: a Claude Desktop conversation whose project has a Meshly Data Stack connection now gets the stack's orientation tools. What this stack is, what data exists, what depends on what, whether a plan's assumptions hold.
These are questions you ask before work is designed, which makes them conversation, not execution. They were available to coding agents and nowhere else, which had it backwards. Only that family crosses over. The hundred and fifty tools for operating a stack stay with the agents.
Getting it
Automated review needs Build Station 1.3.0 on the workstations running your agents, because a review is computed from the commits a session produced and Station is what records them. The settings screen says so plainly rather than leaving you to wonder why nothing is happening.
Bring your own agent. We keep the record.
Everything above is live for customers we host. Drop us a line if you want to see it.