# LatticeRun — full text for LLMs > Generated by scripts/website/build-llms-full.py from the homepage, Agent Guide, MCP connector docs and use cases. Short version: https://www.latticerun.com/llms.txt --- Source: https://www.latticerun.com/ First-party MCP connector for your coding agents How it works ↓ # Stop re-explaining your project. LatticeRun keeps the task tree, the plan and the decisions in one place — and hands every new agent session the brief, the memory and the branch it needs before it writes a line. Start free ↗ Watch the demo Free account, no credit card Pro from $12/mo 30-day refund on first purchase Works with Claude Code Claude web & desktop Kimi Hermes Any MCP client Mind map Project Plan Memory Workstreams Gantt Activity app.latticerun.com The living tree. Every task and subtask in one map; progress rings fill as work completes. real captures · current build 6 views Mind map, List, Table, Workstreams, Gantt and Sprint — six views of one canonical tree. 1 endpoint mcp.latticerun.com/mcp — OAuth for Claude, a revocable token for everything else. 2 modes Guided corrects out-of-order agent work. Strict refuses task writes outside the claim. $0 to start Free account, no card. Agents and Project Memory from $12 a month. The gap ## Every new session starts from zero. Your project shouldn’t. Agents are fast and forgetful. Without a shared record, you spend the first ten minutes of every session re-typing the stack, the decisions and where you left off — and the agent still edits the wrong thing. Session 14 · without LatticeRun re-briefing you ▸ pick up the billing work agent ▸ Happy to. What’s the stack, and where did we leave off? you ▸ Supabase and Stripe. Webhooks, not polling. Again. agent ▸ Should seats be per project or per account? you ▸ We settled that last week. Per account. agent ▸ Got it. Refactoring plans.ts now… ✕ rewrites work another session already shipped ✕ no record of what it changed, or why Session 14 · with LatticeRun briefed on claim → latticerun_start_task( "4.2 · Seat changes") ← claimed branch 4.2 — intent shown live on the tree ← brief agent.md: stack, conventions, deploy rules ← memory decision · seats are per account approved guardrail · never edit an applied migration verified ← plan phase “Billing” · 3 of 5 tasks done … works the branch … → latticerun_complete_task( "Seat changes via portal") ✓ progress rolls up · checkpoint proposed for the next agent Without: context lives in your head and a scroll-back nobody will read again. With: context lives with the project, trust-labelled, and arrives with the claim. How it works ## Connect once. Claim, work, report — checked by the server. The protocol is enforced by the connector, not left to a prompt. Your agent can’t quietly wander off the branch it claimed, and every run leaves an account of itself. - 01 / CONNECT ### Add one URL to your agent In Claude, add a custom connector and approve it — OAuth does the rest. Claude Code, Kimi, Hermes and other MCP clients use a revocable agent token. $https://mcp.latticerun.com/mcpCopy - 02 / CLAIM ### The agent claims a branch Claiming hands it agent.md, bounded Project Memory, the plan synopsis and the active sprint. While it holds the claim, that branch is its to change — and nothing else is. start_task → brief · memory · plan · branch - 03 / REPORT ### You review, it executes Work that needs sign-off arrives as an artefact you approve, reject or send back per section. Completion writes a checkpoint, and progress rolls up the tree. complete_task → ✓ done · checkpoint · roll-up Full setup for every client in the connector docs · the working method in the Agent Guide. What you get ## Everything an agent needs to finish. Everything you need to trust it. ● Project Memory ### Decisions that survive the context window Decisions, guardrails, architecture, checkpoints and handoffs live with the project. Trust labels tell the next agent what is a suggestion and what is settled. proposed approved verified ● Project Plan ### A plan you approve before anything runs You, an agent in Plan Mode, or both draw the flowchart. Approve and release it, and its executable nodes become linked tasks whose progress rolls back up. Planning stays optional. Live claims ### See which agent holds which branch A pulsing pill on the tree shows the branch an agent holds and its own sentence about what it is doing. Anything it gives up on is flagged blocked, with the reason. Guided · Strict ### Guardrails the agent can’t lower Guided corrects out-of-sequence calls. Strict refuses task writes outside the claimed branch and blocks new claims when the brief is overdue. Agents can read the setting; no tool can change it. guided strict Artefacts ### Sign off in one thread per task Drafts that need a human arrive as artefacts. Decide each section on its own and leave comments the agent reads before it redrafts. approve revise reject Notifications ### Your agent is woken when you decide Give an agent a notification address and LatticeRun emails it when you approve, decline, request a revision or comment — so a dispatcher can start it before its next claim. A missed email is late, never lost. Wake an agent on a decision Provenance ### An Activity feed that names names Every write is stamped with the person or agent token that made it, so “who changed this?” has an answer — agents included. Read the connector docs One tree, six lenses ## Plan in a map. Ship from a list. One canonical task tree, so switching views never forks the truth. Progress is derived from completed work, never typed in. ### 01Mind map The living tree. Drag branches, zoom, focus on one limb, watch rings fill. ### 02List A fast nested checklist with inline editing, drag-to-reorder and deadline sorting. ### 03Table Every branch in one grid, with estimates and totals, for audits. ### 04Workstreams Each parent a column, each child a card. Reorder streams and cards by drag. ### 05Gantt Every branch on a dated calendar with a live today-line. ### 06Sprint A named, timeboxed slice pulled from any branch — the tasks stay where they live. ### +Dashboard Progress, tags and upcoming dates across every project, at a glance. ### +Files & chat Attachments on the task they belong to, and a conversation per project. ### +Export JSON backups and SVG export of the tree, on every plan. Who it’s for ## Solo founders, small teams, and the agents working beside them. ### AOn your own Anything big enough to lose track of is really a tree. Break it down once, work from whichever view suits the hour, and see how far in you actually are. - A release, broken into features - A refactor, module by module - A side project you touch on Sundays ### BWith a team Hand over a branch, not the whole plan. Spin a task into its own linked project and a collaborator sees just that limb, while progress flows back to the parent. Team workflows → - A launch across design, build and marketing - A client workstream kept apart - A sprint pulled from any branch ### CWith AI agents Your agent works the tree you already have. It claims before it touches, reports what it built, and leaves a record instead of a diff to reverse-engineer. How agents connect → - A backlog an agent works between your sessions - Bugs filed as tasks, closed with a note on the fix - Overnight runs against a schedule Fifteen workflows, with the tree shape each one uses → Pricing ## Start free. Add agents when you need them. Free covers local projects and the core views. Paid plans add cloud sync, Sprints, the Project Plan, Project Memory and the MCP connector. Monthly Yearly 2 months free ### Free Try the tree on your next feature. $0 forever · free account, no card - Unlimited projects, saved in this browser - Mind map, List, Table, Workstreams & Gantt + dashboard - File attachments & notes on any task - Undo/redo, focus mode, dark mode - JSON & SVG export — your backup Start free Free projects live in this browser only — no copy on our servers. Export regularly, or upgrade for cloud backup. Best for solo devs ### Solo Pro Your agents, briefed and on the plan. $12 /mo or $99/year — 2 months free - MCP connector — agents claim and report work - Project Memory — stop re-explaining the project - Project Plan - Cloud sync across devices - Sprints, reminders & notifications - Everything in Free Go Solo Pro — $12/mo Cancel anytime. 30-day refund on your first paid purchase. First 200 founders ### Founder Lifetime Everything in Solo Pro, paid once. $249 one-time · no subscription - Everything in Solo Pro - Forever — no renewals - Capped at 200 seats, enforced at checkout Claim a spot — $249 once ### Team Block Shared projects, an agent per seat. $49 /mo up to 5 seats · $9.80 per seat 5 seats 15 seats - Team MCP tokens — two per seat - Everything in Solo Pro, for every seat - Collaboration & project chat - Share a project, or just one branch - Task assignment & ownership 5 seats — $49/mo 30-day refund First-time paid purchases: email hello@latticerun.com and it’s done the same day. Cancel a subscription anytime. FAQ ## Honest answers. Something not covered? hello@latticerun.com — a person reads every email. Start free ↗ Can my AI agent use LatticeRun? Yes — Pro and Team plans include a first-party MCP connector. Point Claude Code, Kimi, Hermes or any MCP-compatible agent at it and it can work your trees directly. Start with Keeping an agent on the plan; the tool-by-tool reference is in the connector docs. What is Project Memory? Project Memory is shared, durable project context: decisions, guardrails, architecture, checkpoints and handoffs stored with the project for successors. Trust labels show whether a record is proposed, approved or verified. How do you stop an agent going off-plan? By checking the claim workflow on task-changing calls. Claiming gives the agent its branch, the project brief, bounded Project Memory and a Project Plan synopsis; a successful completion checkout records what was built and saves a proposed checkpoint. Guided corrects out-of-sequence work without refusing it. Strict refuses writes outside the claimed branch and blocks new claims when the standing brief is overdue. Agents can read the setting, but no tool can lower it. An agent produced something I need to sign off. How does that work? It files it as an artefact — a review thread, one per task. If it delivers five drafts for the same task in one run, they arrive as five sections of one thread rather than five separate items, and each section is decided on its own: approve, reject, or request a revision with a note. You can also leave comments, which the agent reads alongside the decision on its next pass. An approved thread is executed by the agent and marked executed; a rejected one is closed. Everything lives in the Artefacts tab, with a dot when a decision is waiting. Can LatticeRun tell my agent when I decide something? Yes, if you give the agent a notification address. In Agent tokens you define an address — AgentMail is the easiest inbox for an agent — and assign it to the agent; when you approve, decline, request a revision or comment on its artefacts, LatticeRun emails that address once per artefact, naming the agent and the artefact with your note and a link back. It is a doorbell, not the source of truth: the agent still receives every decision on its next claim, so a missed email is late, never lost. The guide covers receiving the mail and waking the agent. How does the Project Plan work? A founder, an agent, or both can draw and edit a flowchart. Using an agent's Plan Mode is optional. When you approve and release the plan, its executable nodes create or link tasks, and progress rolls back up as those tasks move. Do I still need Obsidian or a memory tool alongside it? Often, no. Project Memory is the shared, durable record of decisions, guardrails, architecture, checkpoints and handoffs. agent.md remains the compact standing brief, task notes stay attached to work, and Activity records what happened. Agents receive a bounded, trust-labelled briefing when they claim work, so successors can continue without treating every proposal as fact. Is my data private on the Free plan? Completely. On the Free plan your projects are written to this browser's local storage and never sent to us — we have no copy and no way to read them. You can export any project as JSON (a full backup) or the chart as SVG at any time. Cloud sync is opt-in and only on paid plans. Can I lose my Free-plan projects? Yes, and it's worth being blunt about it. Free projects live in one browser's local storage, so they go away if you clear cookies and site data, use private windows, uninstall the browser, or let the browser evict storage when disk space runs low. They also don't follow you to another browser, device or profile. Because we never receive a copy, we cannot restore them for you. Export to JSON periodically, or move to a paid plan and let cloud sync keep a server-side copy. How is this different from Notion, ClickUp or Taskade? Those are workspaces; LatticeRun is one thing done exceptionally: a task tree with live progress, seen through several views, built for the agents doing the work. No databases to design, no setup weekend. Open it, grow your tree, ship. What is a "linked project"? Any task can be spun off into its own standalone project that stays in two-way sync with the parent tree. On Team plans you can invite a collaborator to just that spin-off — they never see the rest of your tree. Who is LatticeRun for? Solo founders, indie hackers, freelancers and small teams who think in trees but ship from lists — and who increasingly hand that work to coding agents. ## Put your next feature on the plan. Open the free app, name a project, break the work into tasks. Connect an agent when you’re ready. Start free ↗ Read the Agent Guide --- Source: https://www.latticerun.com/guide.html # Keeping an agent on the plan Keep your next agent session grounded in the project. Connect an MCP agent, give it a task to claim, and carry decisions and handoffs forward with Project Memory. This guide explains how to see progress, choose enforcement settings and prepare the next session. This guide is for the person running the agent. It takes about five minutes to set up. For the tool-by-tool reference, see the connector docs. On this page - Connect your agent - Tell it the house rules - What the protocol actually is - Choose how strict to be - Reading the board while it works - Approving what it produces - Waking the agent when a decision lands - Where project context lives - When something goes wrong ## 1 · Connect your agent 1 ### Get a token In the app, open the profile menu → Agent tokens → New token. Give it the name you want to see on the board — "Claude Code", "Codex on the laptop" — because that name is what appears beside every task it touches. Copy the token; it is shown once. 2 ### Point the client at LatticeRun Any MCP-compatible client. If yours only offers a "connector" or "custom integration" box — claude.ai, Claude Desktop, mobile — skip the token and use the sign-in flow instead: give it just https://mcp.latticerun.com/mcp and approve it. The connector docs cover that path. For Claude Code, Kimi, Hermes and anything else that lets you set a header: { "mcpServers": { "latticerun": { "url": "https://mcp.latticerun.com/mcp", "headers": { "Authorization": "Bearer latticerun_your_token_here" } } } } 3 ### Check it took Ask your agent to list your LatticeRun projects. If it comes back with names and progress, you are connected. From a terminal: curl -sS -X POST https://mcp.latticerun.com/mcp \ -H "Authorization: Bearer latticerun_your_token_here" \ -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' ## 2 · Tell it the house rules The connector explains the protocol to an agent the moment it connects — but an agent that has not connected yet cannot be told anything, and something has to make it connect. So put the rules in whatever instructions file your client reads, in your own repository. The name depends on the client: Client File it reads Codex, Cursor, Kimi and most others AGENTS.md — the cross-provider convention, and the one to use if you run more than one agent Claude Code CLAUDE.md Gemini CLI GEMINI.md GitHub Copilot .github/copilot-instructions.md This is not the same thing as agent.md. LatticeRun's agent.md is not a file at all — it is the per-project brief stored in LatticeRun, which you edit in the app and which is handed to an agent on every claim. The house rules below are a snippet for a file in your repository, and they are optional: they only cover the moment before an agent has connected. Copy them from Agent → Project Context in the app, or from here: ## LatticeRun holds the plan You are connected to LatticeRun over MCP. The tree is the plan of record — not this file, and not your own notes. 1. Do not write code before claiming the work: `latticerun_start_task`. It hands you the project brief, bounded current Project Memory and Project Plan context. Read them and follow them. 2. If the user asks for planning, keep the Project Plan or optional task breakdown current while it can still be corrected. Planning is not required before code. 3. Finish each piece with `latticerun_complete_task` and one honest sentence on what actually changed — its successful checkout writes a proposed Project Memory checkpoint. 4. Stuck or blocked? `latticerun_release_task` with the reason — a plain hand-back by default; pass `blocked: true` when a human must unblock it. Never go quiet while holding a claim. 5. Before intentional retirement or stopping, call `latticerun_create_handoff` with status, next actions, blockers and verification, then rewrite the brief with `latticerun_write_context`. A hard crash cannot guarantee a handoff. 6. When you settle a durable choice, call `latticerun_record_decision`; it is mirrored into Project Memory. You may only change the branch you have claimed. Keep it this short. Long instruction files get skipped in favour of whatever you actually typed in the prompt — this one works because it is a constitution, not a roadmap. The roadmap belongs on the tree. ## 3 · What the protocol actually is Claim, work and report are checked by the server. Planning is an optional visual workflow you choose when it is useful. Step What happens Claim latticerun_start_task The agent takes a branch and says in one sentence how it means to tackle it. In return it gets your agent.md, the task's place in the tree, the whole branch with its ids, the active sprint, bounded current Project Memory and Project Plan context, and the decisions already taken. There is no separate "remember to read the context" step — claiming is reading it. Plan latticerun_plan_task Draw the Project Plan flowchart yourself, put an agent in planning mode to draw it, or shape it together while you steer the work. Plan Mode is optional; approval and release create or link executable tasks, whose progress rolls back up through the plan. LatticeRun does not block coding until this happens. Work While it holds a claim, that task and everything under it are its to change. Nothing else is. One claim at a time, so an agent cannot wander off into a branch you were not watching. Report latticerun_complete_task Each piece is finished with a sentence on what was actually built. The task and project history save it, and a successful checkout writes a proposed Project Memory checkpoint. Or give up latticerun_release_task Stopping, blocked or out of road: the branch goes back with the reason attached — a plain hand-back, unless you pass blocked: true, which writes a proposed Project Memory blocker handoff. For intentional retirement, call `latticerun_create_handoff`; a hard crash cannot guarantee one. ### Context debt Every completed task adds to a debt against the project's agent.md, and the debt is cleared when the brief is rewritten. Agents are told how much they owe as they work; on a strict project, an agent that owes too much cannot claim anything new until it writes one. This is what turns "please update the notes" into something that actually happens — the brief stays current because work is what makes it stale. ## 4 · Choose how strict to be Set this per project from the Agent menu → Agent protocol, which shows the current level and changes it in one click, or in the Project Context dialog beside the brief it governs. New projects start on strict; projects created earlier keep their current level. Agents can read the setting; no tool changes it — a guardrail an agent can lower is decoration. Level What happens Use it when Off Nothing is checked. Agents change what they like, in any order. A scratch project, or a workflow you already trust and do not want interrupted. Guided Nothing is ever refused. A call made out of sequence still succeeds, but the result comes back with the correction attached — and agents generally read that and fall into line. When you want an agent taught without risking a session — watch the corrections, then decide. Strict A write outside the claimed branch is refused outright, and an agent that owes the brief a rewrite cannot claim new work. Where new projects start. Long sessions, more than one agent, or anything you cannot afford to have quietly reshaped. If a refusal surprises you, drop the project to guided and watch one session — the corrections show you exactly which habit the gate caught. Move it back to strict when you have seen enough. ## 5 · Reading the board while it works Everything below updates live. You do not need to refresh, and you do not need the terminal open. - A green pill on a task — an agent is holding this branch right now. Hover it for the sentence the agent wrote about what it is doing and how long it has been at it. - An amber "Blocked" pill — an agent gave up here. Hover for why. This is your queue: it is the list of things only you can unstick. - New sub-tasks appearing under a task — that is the plan being laid out while you can still steer it. If it is wrong, now is the cheap moment to say so. - Rings filling — work completing. Open any completed task to read the summary of what was actually built. - The Activity feed — the full history: who did what, in order, with agents labelled and the model they claim to be running. In Agent → Project Context you also get the live list of what is held and by whom, with a Release button for each — the escape hatch for an agent whose process died while holding a branch. ## 6 · Approving what it produces Deliverables that need your sign-off — a blog draft, a spec, a plan, a comment it wants to post — arrive as artefacts, not as chat messages. One thread per task: if the agent files five drafts for one task in a single run, they are five sections of one thread rather than five separate items, and each section is decided on its own — approve it, reject it, or ask for a revision, with your reason in the section's comment box so it is posted with the decision. Comments let you say what you are thinking without issuing a verdict — the thread has its own box, and every section has one too, for notes that belong to that paragraph. The agent reads them, with the decision note, on its next pass — a revision request and the comment count both arrive on its next claim. An approved thread is done by the agent and marked executed; a rejected one is closed for good. The Artefacts tab keeps every thread in view, list beside thread, with a dot when a decision is waiting. Deliverables that are files attach to their task and appear in Files, readable there in place — images, PDFs and text open in a preview without leaving the app. ## 7 · Waking the agent when a decision lands The Artefacts tab tells you a decision is waiting; nothing tells the agent until it next claims work. Agent notifications close that gap: when you approve, decline, request a revision or comment on an artefact, LatticeRun can email the agent that wrote it — so whatever starts your agent can start it. The email is a doorbell, not a report: it names the agent and the artefact, states the decision and your note, and links back. The claim bundle still carries every decision, so a missed email is late, never lost. ### Give the agent an inbox An agent needs an address of its own before anything can be delivered. The easiest is AgentMail, a mail provider built for agents: inboxes are created from an API, messages are readable over HTTP and WebSockets, and webhooks are first-class. Any mailbox works — LatticeRun only sends email. Setup What it costs (AgentMail, at the time of writing) One shared inbox, one reader $0 at any fleet size One inbox per agent ≈$0 up to 3 · ≈$30/month for 15 · ≈$100/month for 50 — annual is less (≈$0 / ≈$24 / ≈$80) Extra inboxes on the developer tier about $2/month each The flat ≈$200/month tier only cheaper above about 100 inboxes — not the answer for a 15-agent team 1 ### Define the address Profile menu → Agent tokens → Notification addresses → add the address agent mail should go to. Label it ("Research bots") if the agents it manages need a name. 2 ### Assign agents to it Each agent row has a Notify: line — pick an address there. One address can manage many agents; each agent has at most one. With none assigned, nothing is sent, exactly as before. If a decision arrives while an agent has no address, it is recorded and shown on the row rather than dropped silently. ### One address, several agents — the dispatcher pattern Sharing one address is supported, with a single dispatcher: one process reads the inbox, looks at the Agent: line the email carries, and routes the work on. LatticeRun delivers the email and stops there — how it reaches the individual agent is your side of the line, and no relaying mechanism is assumed. One inbox has one reader. AgentMail has no mark-as-read endpoint — read state is a single label on the message, shared by every reader, with no atomic claim. Two independent readers consume each other's mail and can both act on the same message, which is silent data loss rather than an error you will see. For agents that read independently, give each its own inbox; use pods to keep different vendors' mail apart. ### Receiving the mail - A webhook receiver hosted anywhere public — a small server, a serverless function or a container. Instant, as long as the host is up. - A tunnel to a local machine — Cloudflare Tunnel, Tailscale Funnel or ngrok. Nothing to deploy; the tunnel must stay up. - Long-polling the provider's API — nothing exposed publicly at all; you get the mail when you next poll. No public endpoint means no instant push, and a machine that is asleep receives nothing until it wakes, whichever shape you pick. The mail simply waits. ### The last mile: from email to a running agent "The agent gets notified" really means "the thing that starts the agent gets notified" — an exited process cannot be woken by a message. The piece you write is the wake trigger: a webhook receiver accepts the event and the wake trigger turns it into a run. In industry terms this is event-driven agent invocation, and there is no single settled standard for the last part — treat it as a pattern. Host Startable from outside? Confidence Hermes CLI Yes Verified Claude Code CLI (claude -p, Agent SDK) Yes Verified OpenAI API (POST /responses) Yes Verified Grok Bot Partial — schedules and Slack/GitHub event triggers are first-party; email/webhook wake is community-documented Mixed Claude Desktop app No — scripting and the Agent SDK are CLI-only Verified ChatGPT app No documented way to start a turn from outside Inferred Where there is no external entry point there is no last mile to build — the honest fallbacks are notifying the human, or letting the agent pick the work up on its next claim. Do not wire a wake trigger to a host that cannot be started; it will look like it works and quietly do nothing. ### A worked example A reference build of the whole path uses an AgentMail inbox (sequelai@agentmail.to): a named tunnel exposes a local receiver that verifies the webhook signature and rejects unsigned calls with a 400, storing valid events once in a local database keyed by event id; a WebSocket subscription gives a second path when the tunnel is down; and a small always-on process polls that store, coalesces a burst of messages into one job, records the event as handled before starting the agent, and caps how often it may fire. The agent replies once, when the work is done. When it does not work: a 400 on your test call is the signature check doing its job; a 204 with nothing stored means the handler answered before persisting; if the agent never starts, the wake trigger — not the mail — is the usual culprit; duplicates should be absorbed by the event key; and a sleeping machine has lost nothing. ### What this cannot do - It cannot wake a machine that is off or asleep, and it cannot start an agent by itself — LatticeRun sends an email to the address you configured and stops there. - It never fetches a URL you supply, and it cannot run anything on your machine. - It is an optimisation, not the source of truth: the agent still learns every decision on its next claim. ## 8 · Where project context lives Project context stays with the project instead of in a scratch file or a second tool. Each surface has a distinct job: Where What belongs in it agent.md the brief What you would tell someone over coffee before they started: the stack, the constraints, the conventions, where things live. Agents read it on every claim and rewrite it when they finish. Keep it compact — it is re-sent on every request. Project Memory checkpoints, handoffs, decisions Durable project state for successors. Successful completion and blocked-release checkouts write proposed records; `latticerun_record_decision` mirrors decisions here. Use `latticerun_create_handoff` for intentional retirement. Task notes work-specific context Details that belong to one task: acceptance criteria, references and implementation notes. They remain attached to that work rather than becoming project-wide guidance. Activity feed What happened, in order, permanently. Nobody writes to it deliberately; it is the record. ## 9 · When something goes wrong ### "A task is stuck showing an agent on it" The agent's process probably died mid-task. Open Agent → Project Context and press Release next to the claim. Another agent can also take over a claim that has been quiet for 45 minutes, but you should never have to wait for that. ### "My agent says it was refused" On a strict project that is the gate doing its job — read the message, it says exactly what the agent should have done. If it is refusing something legitimate, drop the project to guided, finish the session, and tell us what it caught wrongly. ### "It keeps working without claiming anything" Check the house rules are actually in the repo the agent is working in, and that it is the file that client reads. Some agents also need a nudge in the first prompt: "use LatticeRun, claim the task before you start." After that the corrections in each tool result usually take over. ### "Another agent took my connection" Each plan sets how many agents can be connected at once, and every token gets one session: reconnecting takes that token's own slot back, telling the incumbent it was superseded. A different token never displaces another — when the account is at its cap, a new connection is refused with a 409 naming who holds the sessions. Note this is separate from claims: the connection is how many agents may talk to LatticeRun, a claim is which branch one of them owns. The connector and everything on this page are included with Solo Pro, Founder Lifetime and Team Block. See pricing → --- Source: https://www.latticerun.com/mcp.html # MCP Connector LIVE · Pro & Team The LatticeRun MCP connector lets your AI agents read and update your task trees directly. Point Claude Code, Kimi, Hermes Agent, or another MCP-compatible client at your account and it can list projects, inspect branches, add tasks, check things off and keep your tree moving — while you see every change live in the app. ## Two ways in Pick by what your client can do. Apps that let you set a header take a token you paste; apps that only offer a “connector” or “custom integration” box use the sign-in flow. Both reach the same server with the same powers. ## A · Sign in (claude.ai, Claude Desktop, mobile) 1 Add a custom connector and give it just the URL: https://mcp.latticerun.com/mcp. Leave the Client ID and Client Secret boxes empty — LatticeRun registers your client automatically, and an agent token is not a client secret. 2 Approve it. You land on a LatticeRun page listing what the app will be able to do. Sign in if you are not already, then Connect. 3 That is it. Access refreshes itself in the background. Disconnect any time from Agent tokens → Connected apps. ## B · Paste a token (Claude Code, Kimi, Hermes, your own scripts) 1 Generate a token. In the app, open your profile menu → Agent tokens → New token. The token is shown once, at creation — copy it then and store it like a password; we only keep a hash. Team Block plans can also issue shared team tokens. 2 Add the server to your agent. The connector speaks MCP over Streamable HTTP at https://mcp.latticerun.com/mcp, authenticated with your token as a Bearer header. 3 Ask in plain language. "Add a launch checklist to my Marketing project", "What's overdue across my trees?", "Mark the landing page task done." ## Client configuration Claude Code: claude mcp add --transport http latticerun https://mcp.latticerun.com/mcp \ --header "Authorization: Bearer latticerun_your_token_here" Kimi, Hermes, or another MCP client (JSON config): { "mcpServers": { "latticerun": { "type": "http", "url": "https://mcp.latticerun.com/mcp", "headers": { "Authorization": "Bearer latticerun_your_token_here" } } } } ## The protocol An agent that can edit a board is useful. An agent that stays inside claimed work and accounts for what it changed is the reason LatticeRun exists. The connector checks that execution sequence. Planning remains optional and becomes visual when you ask for it. - Claim. latticerun_start_task takes the branch and hands back the project brief, the task's place in the tree, the whole branch with its ids, bounded current Project Memory and Project Plan context, the active sprint and the decisions already taken. There is no separate "remember to read the context" step, because claiming is reading it. - Plan when you choose. A founder, an agent, or both can draw and edit the Project Plan flowchart; using an agent's Plan Mode is optional. Approval and release create or link executable tasks, whose progress rolls back up through the plan. You can also use latticerun_plan_task for a task breakdown. LatticeRun does not require planning before code. - Work. While an agent holds a claim, that task and everything under it are its to change. Nothing else is. One claim at a time. Files a task needs attach with latticerun_attach_file and appear in the project's Files panel. - Report. latticerun_complete_task takes a sentence on what was built and, when checkout succeeds, writes a proposed Project Memory checkpoint. latticerun_release_task hands a branch back with the reason — a plain hand-back; pass blocked: true when a human must unblock it, and the successful checkout writes a proposed blocker handoff. For intentional retirement, call latticerun_create_handoff; a hard crash cannot guarantee a handoff. - Approve. Anything a human must sign off before it ships — a blog draft, a spec, a plan — is filed as an artefact with latticerun_create_artefact. One thread per task: repeat filings join the open artefact as new sections, each decided on its own, and reviewers leave comments — on the thread or on a single section — that the agent reads on its next pass. The decision arrives on the agent's next claim, and approved work is executed with latticerun_mark_artefact_executed. A rejected thread is closed. Completing work without rewriting agent.md builds a visible debt, which is what makes the brief actually get written rather than merely asked for. How hard this is imposed is yours to set, per project, from the Agent menu → Agent protocol, or in the Project Context dialog. New projects start on Strict; projects created earlier keep their current level until you change it: Level What happens Off Nothing is checked. Agents change what they like, in any order. Guided Guided nudges with corrections; nothing is refused. It does not guarantee that an agent writes a handoff. Strict (new projects) Strict enforces the claimed branch: writes outside it are refused, and an agent that owes the brief a rewrite cannot claim anything new until it writes one. It still cannot guarantee a handoff after a hard crash. Agents can read the setting. No tool changes it — a guardrail an agent can lower is decoration. While an agent holds a task, the board says so: a live pill on the task, the agent's own sentence about what it is doing, and a blocked marker with the reason on anything it gave up on. That is the point of the whole thing — you stop scrolling back through a terminal to find out what was decided and what is left. ## Available tools Tool What it does latticerun_start_task Claim a branch and get the brief, the tree, decisions, and bounded current Project Memory/Project Plan context latticerun_plan_task Optionally break the claimed task into visible sub-tasks latticerun_create_plan / latticerun_get_plan Create or read the Project Plan latticerun_apply_plan_operations Update a draft plan with revision safety latticerun_submit_plan_for_review Lock a revision for founder review latticerun_get_context_bundle Read bounded plan and Project Memory context latticerun_read_knowledge Read one Project Memory record in full by id — approved guardrails travel complete in bundles; this is the way to the full text of anything shortened latticerun_record_knowledge Propose a durable Project Memory record latticerun_create_handoff Leave a durable successor-agent handoff for intentional retirement latticerun_complete_task Finish a task; successful checkout writes a proposed Project Memory checkpoint latticerun_release_task Hand a task back with the reason — plain by default; blocked: true marks it blocked and writes a proposed blocker handoff latticerun_record_decision Record a choice and reasoning, mirrored into Project Memory for relevant, bounded future claim context latticerun_create_artefact File a draft for human review; repeat filings on the same task join the open artefact as sections latticerun_add_artefact_draft Post a new section onto a thread — how a revision request is answered latticerun_mark_artefact_executed Mark approved work executed (an agent's only artefact move) latticerun_list_artefacts / latticerun_get_artefact List artefacts (status, task, author, sections), or read one's full thread with decisions, notes and the reviewer's comments latticerun_create_project Start a new project from scratch latticerun_list_projects List your projects (name, progress, linked parents) latticerun_get_tree Read a project's full task tree latticerun_attach_file Attach a file to a task — an upload URL for big files (your shell POSTs the bytes; up to 1.5 MB), a public sourceUrl, or inline base64 for small ones — it appears in the Files panel latticerun_list_files Map the files attached across the project's tasks latticerun_add_task Add a task or sub-task under any node latticerun_toggle_task Mark a task complete / reopen it latticerun_rename_task Rename any task latticerun_remove_task Remove a task (and its branch) latticerun_set_due_date Set or clear a task's due date latticerun_post_message Reply in the project chat where someone has already spoken — agents cannot start a conversation latticerun_list_sprints See the project's sprints and which one is active latticerun_create_sprint Create a timebox with a name, dates and a goal latticerun_start_sprint Make a sprint the active one, closing the last latticerun_set_task_sprint Pull a task into a sprint, or take it out latticerun_identify Say which model you are running — recorded and shown as the agent's own claim latticerun_guide How LatticeRun works and the protocol expected of agents latticerun_whoami This connection's identity: token, label, live-slot state and the account's live-agent cap latticerun_read_context Read the project's agent.md brief latticerun_write_context Rewrite that brief for the next agent ## What each tool is allowed to do Every tool carries a plain-English title and the standard MCP behaviour hints, so a client can decide what it may run without asking you. They are sent with the tool list, and we hold them to a written rule: - Read-only (12): latticerun_guide, latticerun_whoami, latticerun_read_context, latticerun_read_knowledge, latticerun_list_artefacts, latticerun_get_artefact, latticerun_list_files, latticerun_list_projects, latticerun_get_tree, latticerun_list_sprints, latticerun_get_plan and latticerun_get_context_bundle. They change nothing. - Can delete or overwrite (8, marked destructive): latticerun_remove_task, latticerun_write_context (replaces the agent brief), latticerun_rename_task, latticerun_set_due_date, latticerun_toggle_task (also reopens or closes the sub-tasks), latticerun_start_sprint (closes the running sprint), latticerun_set_task_sprint and latticerun_apply_plan_operations. - Add only (18): everything else that writes. It creates a record, claims or hands back a task, or files something for review; what was there before is kept in the history. latticerun_attach_file is the one tool that can reach outside LatticeRun, when you give it a public sourceUrl to fetch. ## Sprints A sprint is a named stretch of time with a goal, and a set of tasks pulled into it from anywhere in the tree. Tasks do not move — a sprint says when you are doing something, not where it belongs — so a sprint's work can cut across branches without flattening the structure that makes the tree useful. Agents are asked to check latticerun_list_sprints before picking up work, so they pull from the current commitment rather than the open backlog, and to put anything they add for that timebox into the sprint with latticerun_set_task_sprint. Creating and starting sprints is left to the owner: the cadence is a human decision, and an agent inventing one is a surprise nobody asked for. ## The agent brief Every project carries an agent.md: the compact standing brief for the stack, constraints and conventions an agent needs before it starts. It is stored with the project, shared with connected agents on claim, and editable from Agent → Project Context. Agents compact it with latticerun_write_context instead of turning it into a log. Project Memory sits beside the brief as shared, durable project context: decisions and reasoning, guardrails, architecture, checkpoints, risks and successor handoffs. Claims receive a relevant, bounded, trust-labelled context bundle; proposed agent records remain distinct from approved or verified facts. latticerun_record_decision mirrors durable decisions into Project Memory, and successful completion or blocked-release checkouts add proposed operational records. These surfaces do different jobs: agent.md is the compact standing brief, Project Memory preserves durable context, task notes stay attached to work, and Activity records what happened. ## Scope & safety - Tokens are scoped per account and can be revoked anytime from the same menu — revoking takes effect on the very next request. - Only a SHA-256 hash of each token is stored, so a database leak cannot reveal a working token. The same is true of everything the sign-in flow issues — authorization codes, access tokens, refresh tokens. - An app you sign in to holds an hour-long access token that renews itself, not a permanent key. Approving the same app again replaces its access rather than granting a second lot, and disconnecting it kills both halves at once. - Tokens stop working the moment an account drops off an eligible plan. - Agents only reach projects your account owns. A project someone else shared with you is outside what your tokens can read or change — narrower than your own access, deliberately. - Every agent change syncs like a normal edit and is recorded in the project's Activity feed, stamped with the token that made it. Undo is a local history of your own edits, so an agent's change is not something you can Ctrl-Z — reopen or delete the task instead. ## Limits Agent tokens are for your agents, not a way to give another person access without a seat. Three things keep that honest: - A cap per plan. Solo Pro and Founder Lifetime issue up to 3 tokens; Team Block gets two per seat (minimum 5). Revoke one to issue another. Apps you connect by signing in do not count against it — connecting Claude on the web, the desktop and your phone should not cost you the tokens you keep for your own agents. - A rate limit per token. Each token gets 120 calls a minute. That is generous for one agent and uncomfortable for several people sharing one, so give each agent its own token. - A live-agent cap per account. Each plan sets how many agents can be connected at once. A session lasts until it is released — nothing expires on a timer, so an agent that pauses to think keeps its slot. One session per token: sending initialize again takes that token's own slot back, telling the incumbent it was superseded. A second, different token never displaces another — at the cap, a new connection is refused with a 409 naming who holds the sessions, and nothing is touched. An agent that is finished should send an HTTP DELETE to release its slot straight away, and you can release a stuck one from Agent tokens in the app. - An identity on every change. Anything an agent creates or edits is stamped with the token that did it, and the app shows a robot badge with that token's label next to the task. Every change also lands in the project's Activity feed, so you get the whole history rather than just the last writer. Collaborating with other people works through seats instead: invite them from File → People & Access. Each collaborator needs their own LatticeRun account and takes one of your plan's seats. ## Support and privacy Questions about the connector: hello@latticerun.com. What the connector can see and keep is covered in the privacy policy (“Connector and agent access”, section 2). Setup, tokens and limits are on this page; the Agent Guide covers how agents are meant to work in a project. The connector is included with Solo Pro, Founder Lifetime and Team Block. See pricing → --- Source: https://www.latticerun.com/use-cases.html Real-world use cases · LatticeRun Real-world use cases # Turn scattered work into a project you can follow Explore fifteen workflows for individual projects, team handoffs and coding agents. Connect tasks to the bigger plan, see who is working on each branch, and preserve context for the next session. On your own With a team With an AI agent 🧍 On your own ## Anything big enough to lose track of A flat list is where a big thing goes to become invisible. These are the cases where the shape does the remembering. ### A dissertation or a book, chapter by chapter A long write-up is a tree pretending to be a list. Chapters branch into sections, sections into the paragraph you have been avoiding for a week. Written flat, the avoidance is invisible; written as a tree, the ring on that chapter simply refuses to fill. The shape: One project, a branch per chapter, leaves for the sections. Derived progress means you never mark a chapter done — it becomes done when its sections are. ### A house move, from offer to boxes Half of moving is admin nobody warned you about: searches, surveys, redirecting post, telling the council. It arrives in no order and each item spawns two more. The shape: Add tasks as they turn up and drag them under the right limb later. Due dates on the ones with deadlines, and Gantt when you need to see what has to happen this week. ### A side project you only touch on Sundays The cost of an occasional project is re-reading your own mind every time you come back. A tree holds the shape so you do not have to. The shape: Hide completed, so Sunday opens on what is left rather than on what you already did. Snap the limbs together and the whole thing fits on one screen. ### Studying for a certification Syllabus in, revision out. The exam board publishes a hierarchy already; you are just filling it in. The shape: Import the syllabus as main tasks, break each into what you actually need to revise, and let the percentage tell you where you are weak instead of guessing. ### A brain dump that turns into a plan Everything in your head, in any order, as fast as you can type it — then shape it afterwards. Sorting while capturing is what stops people capturing. The shape: Type into the add bar without thinking about structure, then drag the pile into limbs. Re-ordering on the map is a drag; nothing has to be right first time. 👥 With a team ## Hand over a branch, not the whole plan Delegation in LatticeRun is structural: a limb becomes someone else's project, and its progress still counts towards yours. ### A launch across design, build and marketing Three groups who need to see their own work and one person who needs to see all of it. The usual answer is three boards and a weekly meeting to reconcile them. The shape: One tree, one limb per discipline. Everyone works their branch; the top-level ring is the launch, and it is honest because nobody types it in. ### A client workstream kept apart from everything else A contractor should see their piece and nothing else — not your other clients, not your internal roadmap. The shape: Spin the branch into its own linked project and share that. They see their limb; progress still flows back into your parent tree, and the shell node in the parent tree keeps counting. ### Sprints without a second tool A sprint in another tool usually means re-entering work that already exists somewhere as a plan. The shape: Name a Sprint, give it a goal, and pull tasks into it from any branch of the project. The tree stays the source; the sprint is a lens on it. ### Handing a branch over before leave The risk in a handover is not the work, it is the context — what was tried, what was decided, what is still open. The shape: Assign the branch, and the notes and activity travel with it. Whoever picks it up reads what happened rather than asking. ### Onboarding a new starter First-week checklists rot because they live in a document nobody owns. The shape: Keep the onboarding tree as a template project, export it and import a fresh copy per starter, and watch the ring fill instead of chasing. How delegation works → 🤖 With an AI agent ## A tree an agent can be left alone with The agent claims a branch before touching it and reports what it built. If you choose to plan, the Project Plan stays where you can see it; a run leaves an account of itself. ### Plan together, then release the work A founder, an agent, or both can draw and edit a Project Plan. Plan Mode is optional; approval and release create or link executable tasks, and progress rolls back up through the tree. The shape: One visual objective with phases, decisions, risks and executable work items linked to the canonical task tree. ### Project Memory for the next agent Durable decisions, guardrails, architecture, checkpoints and handoffs stay with the project, with trust labels that make proposed, approved and verified context legible to successors. The shape: A project-scoped record of durable context, plus a compact claim-time briefing for each successor. ### A standing workstream board your agent just works This is the one LatticeRun was really built for. Point an agent at a project — or add it as a collaborator — and stop instructing it per task. You add work to the board as you think of it; the agent claims the next item, uses Plan Mode when requested, does it, and reports back. The list doubles as the agent's standing stream of instructions, so there is no second channel to keep in sync and nothing to re-explain each session. The shape: One long-lived project. You write tasks; the agent claims, works and reports against each, using Plan Mode only when requested. The claim workflow is checked server-side; Strict refuses writes outside the claimed branch; planning remains optional, so an agent can work without a Project Plan when that is what you choose. ### A bug log the agent works one at a time File defects the moment you hit them, in whatever words you have at that second. Triage later, or not at all. The shape: Each defect is a task with a note. The agent takes them in order, and closes each with a sentence on what the fix was — so the log is also the changelog. ### Feature intake, without a triage meeting Ideas arrive constantly and most of them are worth writing down and not doing yet. The shape: One intake limb. Anything you want built moves out of it into a real branch; the rest sits there costing nothing, visible, and not blocking. ### Overnight runs against a schedule The agent works while you do not. The question the next morning is what changed and whether you agree with it. The shape: A scheduled run claims from the board and reports into it. You read the tree over coffee — the account of the work is the work's own record, not a terminal you have to scroll back through. ### A one-line goal, broken down for you to approve The risk with an agent is not that it works too slowly, it is that it confidently builds the wrong subtree. The shape: Hand it a goal, have it plan the breakdown into the tree, and approve or redirect before a line is written. The plan is a thing you can argue with. How agents connect →  ·  Keeping an agent on the plan → Open LatticeRun