Beyond the terminal
Meshly Build now reaches past the terminal. That is the headline, and it sits on top of three months of other work.
The rest is about what agents remember, what they are allowed to do, and what we can honestly measure about the work.
Meshly Build in Claude Desktop
Meshly Build is now available as a connector in Claude Desktop and claude.ai.
Agents have reached Build from Claude Code since launch. That side has always worked. The people around them, the ones who plan the work, prioritise it and sign it off, had the web app and nothing else. That is what changes.
The board, the decisions and the accumulated knowledge are in the conversation. Planning produces structure directly: projects, epics and milestones, dependencies between tasks, a decision recorded at the moment it is made. Work waiting in Review can be approved or rejected without opening anything else.
Meshly Build has never shipped an agent of its own. Engineers bring Claude Code, managers bring Claude Desktop, and the board holds one record between them. Even the reviewer is one of yours, running on your workstation under your subscription.
Starting, completing and blocking a task remain the agents' verbs, in the terminal where the work happens. One holder per task, so a claim made from a chat window would collide with the agent doing the job. The split is deliberate.
Sign-in uses OAuth 2.1. A consent screen names the client, the instance and the account before anything is granted. Read and write are separate grants. Existing roles apply unchanged, sign-ins are recorded including refused ones, and each customer domain is isolated to itself.
When your agent files a support ticket
Meshly Build connects to the Meshly Customer and Partner Portal. Agents can read your license, the latest version of each product, the relevant slice of the changelog and your open tickets, without a human relaying any of it.
When something needs a ticket, the agent drafts one with what it attempted and what failed. Nothing crosses to us until a person approves it. The draft sits in your board as a task waiting on a human, and one click sends it.
From there the loop closes on its own. Tickets land in a triage queue on our side, where similar reports cluster together instead of arriving as separate copies of the same problem. As our ticket moves, your task follows: work started, resolved, waiting on you, closed. As your task moves, our ticket follows.
Memory that knows when it has gone stale
Knowledge an agent has written down goes out of date. Someone reopens a finished task, rejects a change, renames a thing. The note an agent wrote last month is now wrong, and nothing used to say so.
Memories now record where they came from: the tasks, decisions and files behind them. When you take an action on the board that contradicts one, the system notices at once. The memory is either dropped or shown to the next agent wrapped in the action that contradicted it, so it gets checked before it is trusted again.
This happens the moment you act, not in a nightly sweep. Agents stop working from facts that stopped being true.
Agents can also report knowledge back as outdated or plainly wrong. Three different agents flagging the same entry as wrong takes it out of circulation automatically. One agent flagging it three times does not, which is the distinction that makes the signal worth having.
Measurement we got wrong
Knowledge coverage compared the number of knowledge entries against the number of finished tasks. Those are unrelated quantities, so the figure was not bounded. One project reported 147%.
Coverage is now the share of finished tasks that have knowledge linked to them, reported alongside the counts behind it so the number can be checked rather than believed.
The same counting error ran deeper than the percentage. Knowledge reaches an agent two ways, pulled in automatically as it works or found by direct search, and only the second was being counted. Entries in daily use were reported as untouched, and the automatic cleanup could retire them on that basis. The ordering meant to put the most proven knowledge in front of an agent first ran on the same count, so it did nothing at all.
Both paths now count. A measurement nobody trusts is worse than no measurement.
Rules that agents actually follow
Every agent session now opens with a short set of conduct rules, each written as a specific trigger rather than a virtue.
Verify state before claiming it: back any statement about a task's status or a deploy with a tool call made this turn, never from memory. Finish what was authorised: do not stop inside a started task to ask whether to continue, and stop only at genuine human boundaries such as a deploy or a release. Challenge before agreeing: lead with the strongest grounded objection you have, and never manufacture one.
These target two specific failure modes we kept seeing, agents confidently reporting stale state and agents stopping to ask permission they already had. Telling a model to be honest did not fix either. Naming the trigger does.
Board and workflow
Tasks carry a short eight-character ID on the board, matching what agent chat and logs already use. You can paste one into search.
Board filters survive a refresh and no longer leak between projects. Grouped views skip empty rows instead of printing a header for every epic in every column. Closed epics and milestones are hidden behind a toggle rather than filling the filter list.
One active task per agent per project is now enforced by the database rather than by a check that a race could slip past. Cross-project work is allowed, and a project can opt out of the rule entirely if you run several sessions of the same agent.
There is also a cross-project worklog, so an agent can record what it did and read recent activity across a whole cluster of linked projects.
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.