Continuity · · 11 min read
Project Mesh: preserve work instead of doing it twice
Observed claims, scoped memory and a stable Task help agents coordinate and continue across models and computers. We verified failed-attempt persistence through an Engine restart.
Two coding agents can work quickly and still waste a large amount of time together. One investigates an error that another chat has already explained. Both edit a neighboring module without seeing the overlap. A replacement model starts from an empty conversation and reconstructs the same project history. These are coordination costs, and they eventually become token costs because investigation, explanation, and repair all pass through model context. GrantTap's Project Mesh gives those facts a durable home and a visible route to the next Execution, so progress does not depend entirely on remembering which chat contained an important sentence.
Mesh is built around the Project and the Task. A Task is the stable unit of work a person recognizes; an Execution is a provider's session performing that Task on a computer. Changing the provider, model, or computer does not require inventing a new identity for the work. In this research pass we checked scoped context, observed file claims, event delivery, handoff boundaries, and durable knowledge behavior. We also verified a failed run through the actual Engine and read its attempt record after restarting the daemon. The goal is practical: make facts reusable and coordination bounded, without assigning another model to write a report every time something happens.
The account connects computers; the Project connects work
An account's trusted device area and a Project Mesh answer different questions. The account identifies which computers and controllers may participate in the user's protected space. A computer running the MCP runtime contributes routes to its Tasks and Executions. A Project Mesh associates work with repository identity, relationships, policy, and project knowledge. Several computers can work on one Project, and one computer can host unrelated Projects. A dependency between repositories does not make all their Tasks interchangeable, and account membership does not erase project visibility. Keeping these distinctions allows GrantTap to aggregate useful activity while retaining the route to the computer that can act on it.
This is why a Task keeps its computer route. The list on a phone can represent work across several machines, while an approval or continuation must reach the relevant local runtime. Project coordination can include intersecting repositories, declared dependencies, and independent work. Repository bindings connect logical identity to an available local checkout rather than assume that equal directory names prove equal projects. The distinction also matters for economy: an agent needs the neighboring work relevant to its Project, not the complete history of every trusted computer. Mesh can carry a small scoped view instead of turning an account into one enormous shared conversation.
Observe supported work instead of asking for reports
GrantTap can derive useful facts from native activity it already observes. Supported file writes become claims associated with an Execution, Task, repository, checkout, and path. Delivered runs enter a journal with their outcome, observed tool count, and changed files. Structured events carry progress into the Task. These operations are algorithms on the computer. The coding model does not need an additional instruction to narrate each file write for the interface to know that a file was touched. The resulting facts also preserve attribution, making it possible to inspect which session supplied an observation and when it became visible.
Observation has a defined boundary. The system does not turn every shell command into a verified file write, or treat a chosen capability as proof that it was used. A tool count from a transcript is an observed count with that source's limitations. A model's statement remains a report. These distinctions improve reuse: a later Execution can consult an observed path, an explicit decision, and a reported conclusion without confusing their strengths. Economy comes from avoiding repeated mechanical collection and preserving known facts, while tests and source inspection still establish whether a proposed implementation behaves correctly.
Inspect the work inside a chat
The chat places Files and Agents directly above the composer. Files opens the changes observed in the current reply, with addition and deletion counts and an expandable diff when the provider supplied one. All Files opens the Task's known checkout as a folder tree, with paged file previews. A preview already received is saved privately on the device and can reopen offline; reading a new path still requires its computer. The computer resolves the Task's admitted checkout and rejects paths outside it, external symlinks and protected credential files.
Agents opens the Execution's nested conversations and their known messages. This makes delegated work visible inside the Task. Files, diffs and agents keep their source attribution: the interface does not add historical edit counts to a new reply or attribute a child's changes to its parent. These inspection actions help a person see where work happened before asking the model to repeat a summary.
File claims reveal overlap early
A claim helps answer a concrete question: is another Execution already working on this resource? Exact overlap in the same repository and checkout has a different meaning from similar paths in independent worktrees. Logical overlap across checkouts can still be relevant to a later merge, and neighboring module activity may deserve a warning without proving a direct conflict. GrantTap's observed claim tests exercise these distinctions instead of comparing filenames alone. Claims also have an expiry and ownership, so yesterday's activity does not permanently block a resource or falsely imply that a chat is still working there.
Consider two agents investigating a pairing failure. One owns the local runtime's account binding file while the other is changing the phone's display state. A short Mesh view can show their Tasks and claims before either reads the other's full transcript. If both begin touching the same runtime path, they can narrow the responsibility, request a handoff, or wait for the relevant result. This can prevent duplicate exploration and repair. It is an engineering mechanism rather than a measured universal percentage: the amount of avoided work depends on the Tasks, their overlap, and whether the agents actually use the coordination evidence before proceeding.
Keep failed attempts alongside useful results
Project memory includes decisions, results, and attempts with source attribution. Failed approaches are useful because a future Execution can see what was already tried and the reason it did not close the Task. In the updated delivery path, an unsuccessful run emits structured failure data automatically. Its knowledge projection creates an attempt record, rather than a successful result or a new project decision. The record carries the source event identity, so repeated synchronization can recognize the same observation. Ordinary successful progress remains progress; it does not automatically declare that the whole Task has been completed.
Visibility is part of that record. A Task's failed progress stays private to that Task. An explicitly shared completion can expose its attempt to the Project. An agent answer remains an attributed report, while a user decision retains its separate source. Superseding a record preserves the correction relationship instead of keeping two conflicting answers equally active. During our real Engine check, the failure reason was recorded, the daemon was restarted, and the same attempt was returned from durable history. That verifies persistence. Its usefulness on another Task still depends on the appropriate visibility and relevance, rather than a broad promise that every failure automatically becomes everyone's instruction.
A compact view makes reuse affordable
Shared memory would defeat its purpose if every prompt received every retained event. GrantTap prepares bounded context with stable identifiers and expansion links. The compact Project view shows a limited event window, knowledge window, and claims, alongside Task identity and neighboring activity. A full read remains available when a specific source needs inspection. Cursor based deltas can deliver new events after a known identifier. When a cursor is unknown, the system returns a compact reset with an explicit reason, rather than pretending to know which missing updates the consumer has already seen.
The Claude prompt integration also offers bounded unread run summaries and a Mesh brief on the next supported prompt. That brief can identify other active Tasks, relevant neighboring claims, dependencies, and unresolved coordination questions. Being offered is distinct from being acknowledged, so a delivery does not silently claim that the agent understood or acted on the information. Other provider paths have their implemented resources and hooks; coverage should be read per provider. The common design is economical delivery of actionable coordination, not another long compulsory narrative that every agent must generate and then consume before doing any useful work.
Hand work to another model with continuity
A handoff capsule carries the facts needed to continue: the Task goal and status, source and target provider and computer, repository and revision information, changed files, dependencies, claims, remaining work, and important decisions. The user can add a comment that explains why the work is being handed over. This gives the next Execution a structured starting point. It can inspect the relevant evidence and perform the remaining work without rebuilding the entire previous conversation. Provider native sessions remain distinct, while the user visible Task continues across the transition and its work history retains the relationship between executions.
Readiness is checked at the destination. A target that is offline, paused, unable to write, missing the required repository, or blocked by conflicting claims cannot simply be treated as ready because a model was selected. Delivery reports distinguish queued, blocked, offline, and failed states. The capsule also does not claim to transfer an arbitrary filesystem, install a provider, or synchronize uncommitted changes through a chat message. For work across machines, the actual repository and worktree state still matter. These checks help the transfer save investigation without creating a second repair Task caused by an incorrect environment or missing local changes.
Coordination data is evidence, not authority
Mesh messages can guide a coding agent toward relevant work and project facts. They can say that another Task owns a path, that a dependency changed, or that a previous attempt failed. They cannot grant permission to bypass a computer's capability policy. Source content and agent reports remain data even when they appear inside a context packet. This separation allows the Project to share useful information without turning an untrusted message into an instruction to run a shell command, change global approvals, or publish code. Governance evaluates the proposed action through the local enforcement path.
The same distinction protects architectural reasoning. A repository relation can be observed or declared, and its provenance matters. A graph can direct attention toward a dependency, but the corresponding source and behavioral checks determine what an edit actually affects. Mesh records can preserve a decision without retroactively converting an agent's guess into verified truth. The next model should therefore inherit a usable evidence trail, not a requirement to trust every prior sentence. Avoiding repeated work does not require avoiding verification; it requires knowing which verification has already been performed, on which revision, and whether that evidence still applies.
Measure avoided work at the right scale
A useful evaluation begins with a repeated investigation or a real overlap scenario. Record which facts the first Execution established, what the replacement Execution received, which files it reopened, and whether it reached the same verified conclusion. Compare the complete interaction rather than just the capsule's size. A small handoff can still require a large reconstruction if it lacks the decisive source. Conversely, several extra coordination lines can be worthwhile if they prevent two agents from rewriting the same module or repeating a failed approach. The denominator should include the work that actually produced a correct result.
Our checks in this pass establish the mechanisms: scoped memory excludes another Task's private records, supported native writes create scoped claims, conflicting and stale claims have distinct handling, and an unsuccessful delivered run persists as an attempt across an Engine restart. Those facts support a concrete explanation of how Mesh can reduce waste. They do not supply a universal provider billing reduction, because we did not run matched paid model sessions for every provider and workload. GrantTap makes reused evidence and coordination inspectable, so a project can measure its own outcome while the computer performs the repetitive state management automatically.
