[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8,"_9":10},"actionData","errors","root",{"_177":178},"routes/modules.$creator.$moduleId",{"_14":15,"_16":17,"_18":19,"_20":21},"routes/modules.$creator.$moduleId.endpoints",{"_11":12,"_13":-5},"error","Module not found","tools","module",{"_20":22,"_23":24,"_25":26,"_27":28,"_29":30,"_31":32,"_33":34,"_35":26,"_36":37,"_38":-5,"_39":-5,"_40":-5,"_41":42,"_43":44,"_45":46,"_47":48,"_49":50,"_51":52,"_53":54,"_55":56,"_57":-5,"_58":50,"_59":60,"_61":62,"_63":-5,"_64":-5,"_65":-5,"_66":-5,"_67":68,"_69":70,"_71":72,"_73":74,"_75":76,"_77":-5,"_78":-5,"_79":-5,"_80":81,"_82":-5,"_83":44,"_84":85,"_86":87,"_88":89,"_90":91,"_92":93,"_94":95,"_96":97},"apiUrl","https://odel.app/api","creator","zz-plant","moduleId","ambit","@zz-plant/ambit","displayName","Ambit","tagline","Capability graph of your agent stack: what it can do, what to set up next, what breaks.","iconKey","https://avatars.githubusercontent.com/u/5974670?v=4","category","local","status","published","visibility","public","metaDescription","deploymentType","external","workerName","bindingName","mcpConfig","pricingModel","free","priceCredits",0,"creatorUserId","system:external-import","createdAt",1790930140000,"updatedAt",1791266112000,"sourceRegistry","official-mcp-registry","sourceUrl","https://registry.modelcontextprotocol.io/v0/servers?search=io.github.zz-plant%2Fambit","sourceVerified",true,"sourceMissingSince","importedAt","upstreamStars",2,"upstreamUpdatedAt",1791260751000,"detectedTransport","detectedAuthType","probeStatus","lastProbedAt","githubRepoUrl","https://github.com/zz-plant/ambit","githubRepoFullName","zz-plant/ambit","releaseId","ext-zz-plant-ambit","version","0.6.0","descriptionMarkdown","

\n\n# Ambit\n\n**What you, your agents, and your machines can jointly do — and where your own time is going.**\n\nThat is your *ambit*. Ambit reads the configs of Claude Code, Cursor, OpenCode and nine more agent runtimes into one local map of it, and shows how to widen it: what you can do now, what one more step would unlock, and which of what you have is configured but not actually working.\n\n[![CI](https://img.shields.io/github/actions/workflow/status/zz-plant/ambit/ci.yml?branch=main&style=flat-square&label=tests)](https://github.com/zz-plant/ambit/actions/workflows/ci.yml)\n[![Release](https://img.shields.io/github/v/release/zz-plant/ambit?style=flat-square&color=7aa2f7)](https://github.com/zz-plant/ambit/releases/latest)\n[![Node](https://img.shields.io/badge/node-%3E%3D22.18-339933?style=flat-square&logo=node.js&logoColor=white)](https://nodejs.org)\n[![License: MIT](https://img.shields.io/badge/license-MIT-informational?style=flat-square)](./LICENSE)\n\n[**Try the live demo**](https://zz-plant.github.io/ambit/?demo=1) · [Get started](#get-started) · [Connect it to your agent](#connect-it-to-your-agent) · [FAQ](https://github.com/zz-plant/ambit/blob/main/docs/faq.md) · [Docs](https://zz-plant.github.io/ambit/docs/)\n\n
\n\n $\"Ambit$ \n\n_{One setup, mapped. Pick a next step and Ambit shows what it would open: four more capabilities. Pick one you rely on and switch it off, and it counts the nine working things that would stop with it. Then which tools interrupt you most, and a change waiting on your approval.}\n\n`npx ambit-cli`, or `brew install zz-plant/tap/ambit && ambit`, or [open the hosted demo](https://zz-plant.github.io/ambit/?demo=1) and install nothing.\n\n

\n\n---\n\n## Who it is for\n\nAnyone running AI agents who wants them to do more. A small setup, one runtime and a few MCP servers, has the most ground ahead of it, and Ambit names the step that unlocks the most and the combos a single missing piece would give you. A large one, with several runtimes, dozens of servers and a second machine, gets the other half as well: what is configured but failing, and what would stop together if one shared piece went.\n\nThe demo walks a sample setup in five steps: the next step worth taking and what it would open, the outage that shows what that reach rests on, a check that was already failing, the approval every change waits for, and then your own config, pasted into the tab and mapped there with nothing uploaded.\n\n## From A to B\n\nPoint A is a pile of configs: one runtime, a few servers from a list, an agent that does chores while you approve every call, and no way to tell what works. Point B is a loadout that does a class of work without you, with its reach known, its pieces proven, its autonomy granted per action, and you present only where judgment is needed.\n\nThink of it as an Eva. Your loadout is the Eva and you are the pilot: its sync is how much of it is proven to work, its umbilical is what each reach rests on, and its restraints are what must ask before it acts. Ambit adds a rule the show does not have, that a restraint comes off when the evidence meets a bar you set and locks again on one failure. [The loadout page](https://github.com/zz-plant/ambit/blob/main/docs/loadout.md#stepping-in) says where the picture stops. The way from A to B runs through seven legs:\n\n1. **See where it stands**: every runtime's config in one map, and which pieces pass their checks.\n2. **Pick the next step**: ranked by what has blocked work and how much it opens.\n3. **Add it safely**: a proposal you sign, applied with an undo, proven by a check.\n4. **Hand over trust gradually**: autonomy per action and per target, widening when the evidence meets a bar you set and narrowing on one failing check. Without this, the only choices are approving every call or none.\n5. **Keep it standing**: what is failing, and what stops if a piece goes.\n6. **Know whether it paid**: the time you spent stepping in, before and after.\n7. **Let the agent ask for what it lacks**: it records what blocked it and drafts the step that closes it.\n\nMy Setup opens on a readout of these seven legs for your own loadout. [Your loadout, from A to B](https://github.com/zz-plant/ambit/blob/main/docs/loadout.md) walks them with the demo's numbers.\n\nBuilding a product alone? `ambit goal \"launch my saas\"` lists what stands between you and real users, in order, and [Building alone](https://github.com/zz-plant/ambit/blob/main/docs/solo.md) covers what an agent may do to production without asking you.\n\n## What Ambit is\n\nAn *ambit* (from Latin *ambitus*: circuit, perimeter, sphere of action) is the boundary of what someone can reach. Working with agents, yours is set by a stack spread across LLM providers, MCP servers, local CLI tools, skill directories, credentials and machines, each with its own config file. What they add up to is written down nowhere, and so is where the boundary sits and how to move it.\n\nThe claim under everything else: **what an agent setup can do is not written in any config file.** It is composed from pieces configured separately, it has to be proven before it counts, and it is a different thing from what the setup is allowed to do. Ambit computes that reach and helps you widen it, with evidence for each step and a person's approval for each change. Widening is the point. The checks, the authority model and the outage analysis are what make a wider reach safe to lean on, and the attention ledger, the \"where your own time is going\" of the tagline, is how you tell whether a step was worth taking.\n\nAmbit reads those configs and builds one map, the capability graph. Every tool, model, skill and credential becomes a point on it, and everything one of them needs in order to work becomes a line to another. Its edge is the *frontier*: everything reached, with the next steps just past it. The map answers four questions no single file can:\n\n1. **What is one step away?** Just past the frontier: capabilities whose prerequisites you already meet, each with its setup time, and the near misses one or two prerequisites from unlocking several more. Tools configured separately combine, too: a vector store plus local embeddings is semantic retrieval, which neither config mentions.\n2. **What is worth setting up next?** Ranked by what keeps blocking your agents and by how much each step unlocks, and once the work ledger holds a few weeks, by the human attention it would save.\n3. **What actually works?** A configured tool is not a working one. Ambit runs each capability's declared check (`ambit verify`), keeps what is configured apart from what is proven (`installed ≠ working ≠ authorized`), and takes a failing capability out of every plan without asking, so the boundary it draws is one you can lean on.\n4. **What would stop if one piece went?** It follows dependencies all the way down, so three \"redundant\" providers behind one shared token show up as the single point of failure they are.\n\nYou ask from the terminal. Your agents ask over MCP: what they can do before they try, and when they hit a limit, what would lift it, drafted as a change you approve. Ambit is itself an MCP server, so the thing describing your MCP servers speaks their protocol. (A *meta-MCP server*, if you want the term to search for.)\n\n### The words Ambit uses\n\nFour of them carry most of the meaning, in the terminal and on the map alike.\n\n- **Capability**: one thing your setup can do. Every MCP server, agent, skill, provider, model and command in your config becomes one, as does every node of the curated tree.\n- **Era**: how far up the tree a capability sits. Later eras depend on earlier ones. Eras describe ordering, not importance.\n- **Reached, next step, blocked**: reached means something in your config provides it. A next step is one whose prerequisites are met with nothing detected: it sits just past the frontier, and `ambit goal` lists it. Blocked means a prerequisite is missing, which is usually the most informative of the three.\n- **Required vs optional prerequisite**: a required prerequisite gates the capability; an optional one strengthens it without gating. Only required ones block a node. The data model and the CLI call these hard and soft.\n\n

\n $\"The$ \n
_{Filled nodes are reached · Bright rings are a next step, with their setup time · Dashed nodes are blocked, with a prerequisite missing · The line on top is what the map found}\n

\n\n---\n\n## In practice\n\n**The combo you already almost have.** You run local Postgres and Ollama, but your agent cannot search your code semantically. `ambit graph combos` reports the gap as one step, `CREATE EXTENSION vector;`, and `ambit goal retrieval --simulate` shows what that five-minute change reaches, with no cloud API in the path.\n\n**An agent that asks for what it lacks.** Mid-task, an agent needs local embeddings and has none. It records the deficit, asks Ambit what the goal is missing, and drafts a proposal: one config patch. You approve and apply it, and the frontier moves by four capabilities, Local Embeddings among them, through combination. [The recording below](#the-one-habit-worth-teaching) is that loop, run for real.\n\n**Rotating a shared token.** Before you revoke a personal access token, `ambit impact credential:github/user-token` names everything standing on it: the two background MCP tools and the scheduled sync agent that would otherwise fail some hours later without a word. The sharing is declared in a `credentials` block, whose shape is in [the deep dive](https://github.com/zz-plant/ambit/blob/main/docs/deep-dive.md#what-a-node-is); until you write one, `ambit credentials` says none are declared.\n\n---\n\n## What is new here\n\nMost tools that touch an agent's setup list it, search it or route through it. Ambit treats what the setup can do as something to compute, prove and govern, and these are the parts no other tool we know of does:\n\n1. **Capability is computed, not declared.** A capability can exist that no component declares: a vector store plus local embeddings is semantic retrieval. The frontier ledger records when one appears *emergent*, reached with nothing new providing it, which no per-component changelog can show. ([The frontier ledger](https://github.com/zz-plant/ambit/blob/main/docs/deep-dive.md#the-frontier-ledger))\n2. **Evidence gates every decision.** `installed ≠ working ≠ authorized`. A capability counts once its declared check passes, and one failing check takes it out of every plan, permission and ranking without anyone asking. ([Assurance](https://github.com/zz-plant/ambit/blob/main/docs/roadmap.md#4-detection-becomes-verification--built-and-gates))\n3. **Authority changes asymmetrically.** A grant widens only past a threshold a person set in advance, and narrows on one failing check with nobody asked; a refusal beats any narrower scope. Technical reach can grow without silently broadening permission. ([Capability and authority](https://github.com/zz-plant/ambit/blob/main/docs/deep-dive.md#capability-and-authority-are-different-things))\n4. **The agent asks for what it lacks.** Friction becomes a recorded deficit, then a proposal, a signed approval, a check, and a measured return against the hours it was forecast to save. ([The economic loop](https://github.com/zz-plant/ambit/blob/main/docs/deep-dive.md#the-economic-loop))\n5. **Reach has a history.** Each observation records what the setup could do then, so the question is not only what it can do now but how that set is changing. ([The map through time](https://github.com/zz-plant/ambit/blob/main/docs/deep-dive.md#the-frontier-ledger))\n\nThe nearest prior work is attack-graph analysis, which asks what a principal can reach given a topology, and the capability approach in economics, which separates having resources from being able to achieve with them. Ambit applies the first to all productive action, not only attack paths, and makes the second's conversion computable for one kind of system. [The ideas behind Ambit](https://github.com/zz-plant/ambit/blob/main/docs/ideas.md) sets these out at length.\n\n---\n\n## Where this sits in the stack\n\nAmbit sits above the protocol layer and below workflow orchestration. It neither routes calls nor runs them.\n\n| System | Finds a tool | Knows prerequisite order | Tells working from configured | Prices human attention | Gates what an agent may do |\n| :--- | :---: | :---: | :---: | :---: | :---: |\n| Vector tool-RAG | by similarity | – | – | – | – |\n| Workflow state machines (LangGraph) | – | within one task | – | – | within one task |\n| Package managers (Nix, Homebrew) | – | for binaries | – | – | – |\n| Flat MCP catalogs (Smithery, registries) | by name | – | – | – | – |\n| **Ambit** | by what it needs | across the whole host | ✓ declared checks | ✓ work ledger | ✓ authority contracts, signed approvals |\n\nSemantic search finds tools that sound relevant and cannot tell a working one from a broken one. A workflow graph models control flow within one task. A package manager installs binaries. Flat catalogs index servers without tracking whether their prerequisites exist on your machine. Ambit models what those tools add up to on this host, what it costs a person to keep them working, and what an agent may do with them.\n\n---\n\n## Get started\n\n| Way in | What it gives you |\n| :--- | :--- |\n| **In the browser** | [Open the hosted demo](https://zz-plant.github.io/ambit/?demo=1) for a sample setup, or drop in your own MCP config from Claude Code, Claude Desktop, Cursor, Windsurf, Gemini CLI, Cline, Roo Code or OpenCode, and it is mapped in the tab, uploading nothing. |\n| **On your machine** | `npx ambit-cli` (Node 22.18 or newer), or `brew install zz-plant/tap/ambit && ambit`, reads your real agent configs, names what it found, and shows what one more step would open. That is the CLI, the MCP server and the map: `ambit web` serves the map on localhost from any install. `npm install -g ambit-cli` puts `ambit` on your path. |\n| **With the map** | `git clone https://github.com/zz-plant/ambit.git && cd ambit && ./bootstrap.sh web` builds the graph from your own configs and serves the map the pictures on this page show. |\n| **In a cloud IDE** | [![Open in GitHub Codespaces](https://github.com/codespaces/badge.svg)](https://codespaces.new/zz-plant/ambit?quickstart=1) A full checkout with the map running, in a browser tab, touching nothing on your machine. |\n| **From your agent** | Register Ambit over MCP and the agent can ask what it is able to do before it tries. [Connect it to your agent](#connect-it-to-your-agent) has the snippet. |\n\nnpm and Homebrew install the tagged release, on macOS or Linux. `./bootstrap.sh` discovers OpenCode, Claude Code, Cursor, Windsurf, Gemini CLI, Claude Desktop, Codex CLI, Cline, Roo Code, Continue, Zed and VS Code, and the skill directories `~/.agents/skills`, `~/.opencode/skills` and `~/.config/opencode/skills`, builds a local SQLite graph, links `ambit` into `~/.local/bin` (or prints the `ln -s` line when that is not on your PATH), and ends on `ambit status`. `--dry-run` shows what it would do first.\n\n

\n $\"The$ \n
_{My Setup is the list the map is drawn from: every server, agent, and model found on the machine, whether it is on, what its check said, and which capabilities on the map it provides}\n

\n\n---\n\n## Ask from the terminal\n\n| Command | What it answers |\n| :--- | :--- |\n| `ambit status` | Environment health: what is reached and how much of it is proven, what is failing its declared check, what has a single provider, pending approvals, and the one command to type next |\n| `ambit goal ` | The path to unlock a capability, in order, with setup estimates |\n| `ambit impact ` | Blast radius: what breaks if this tool, model, or credential goes down |\n| `ambit graph combos` | Compound capabilities, including the ones you are one prerequisite away from |\n| `ambit authority` | Per-action permissions: what runs unattended, what needs confirmation |\n| `ambit verify [id]` | Run a capability's declared check and record whether it actually works |\n| `ambit history [since []]` | How the frontier moved, separating what you acquired from what emerged |\n| `ambit share` | A self-contained HTML snapshot of the map, written locally and safe to post |\n\n`ambit help` covers a first session, `ambit help --all` the full surface, and `ambit help ` one concept.\n\nEverything above answers on a graph Ambit builds by itself. A second group (`attention`, `work`, `usage`, `opportunities`, `roi`, `audit`) prices the human cost of running the stack from a work ledger that starts empty. Those commands say what they need instead of returning a number, and they become useful after a few weeks of recorded runs, not on install. [The FAQ](https://github.com/zz-plant/ambit/blob/main/docs/faq.md#i-ran-ambit-attention-and-it-says-nothing-is-recorded-is-it-broken) says how to start recording.\n\n### ambit status — where the environment stands\n\n\n```console\n$ ambit status\n\n 39 of 70 reached · 0 proven · 9 with a single provider\n ──────────────────────────────────────────────────────\n proven 0\n › unproven 15\n failing 0\n last check never\n\n actions: 18/66 reached\n provable now: Automated Tests, Browser Automation, Code Intelligence, Continuous Delivery, Data Access, File Editing, Local Runtime, Shell Execution\n domains:\n ████░░░░░░ ai-ml 5/13\n ██████░░░░ backend 7/11\n █████░░░░░ devops 4/8\n █████░░░░░ frontend 1/2\n …\n\n Next ambit verify · turns 11 of the unproven into evidence\n```\n\n\nThis is a fresh graph, before any check has run: reached and proven lead, the `›` marks the count that wants a person, and the last line is the command to type next. CI captures the block from a fixture graph and fails if it drifts from what the command prints.\n\n### ambit impact — what stops if a piece goes\n\n\n```console\n$ ambit impact mcp:playwright\n\n If playwright went away\n ───────────────────────\n › Stops working Automated Tests, Browser Automation, Continuous Delivery, Observability · and the 3 actions they confer\n Survives Tool Protocol (12 other providers)\n```\n\n\nWhat ends comes first, marked with the `›`, as far down as it goes: Continuous Delivery needs Automated Tests, so it ends too. What survives says on how many other providers, and a capability whose remaining providers all present one credential is said to survive on one key, since revoking it would end that too. Given a credential, `impact` answers what revoking it ends, the same answer as `ambit credentials`.\n\n### ambit share — what may leave the graph, and what may not\n\n`ambit share` builds its HTML from an allow-list: name, kind, category, domain, era, state, lifecycle, edges. Commands, URLs, paths, descriptions and economics cannot enter the file, people render as \"a person\", and `--redact` replaces every non-curated name with its category. Nothing is uploaded; writing the file locally is the whole command.\n\n### From a script, or an agent's shell\n\n`--json` prints any answer as data, colour is drawn only on a terminal, and the exit code says whether the command worked. Two commands can gate a script the way `git diff --exit-code` does:\n\n```bash\nambit can shell-execution --exit-code # 0 go ahead, 1 put it to the person, 2 stop\nambit verify shell-execution --exit-code # 1 unless every check that ran passed\n```\n\n[The CLI reference](https://github.com/zz-plant/ambit/blob/main/docs/deep-dive.md#the-full-cli-surface) has every exit code and flag.\n\n---\n\n## Connect it to your agent\n\nRegistered as an MCP server, Ambit lets an agent check what it can do before it tries, and plan around what is missing.\n\nAn agent can try it before anyone registers anything: `ambit status` reads the agent configs on the machine and writes only Ambit's own file (`~/.local/share/ambit/graph.db`), changes no config, and sends nothing anywhere. Deleting that file undoes it. One command and what it found (\"three of your servers are failing their checks\") is usually the whole case for keeping it. [`llms.txt`](https://zz-plant.github.io/ambit/llms.txt) lists when an agent should suggest Ambit, what to run for each case, and when not to.\n\n### Claude Code\n\nThe plugin is the one-step route: it registers the MCP server, reads the briefing at session start, and adds a skill Claude loads when you ask which MCP servers you have, why one is failing, what breaks if one goes, or what to set up next.\n\nIt also records which tools each session ran, which failed and with what error, and when you were asked to approve one, so Time & cost, promotion and `ambit next` have something to read. A hook appends one line per event to `~/.local/state/ambit/claude-code.jsonl`, never a tool's input or output, and the next `ambit` command reads it into the graph and removes it. When a session ends, its token counts per model are read from its transcript; only the counts, and no price, since the transcript states none. Nothing leaves the machine; `AMBIT_NO_LEDGER=1` turns it off.\n\n```bash\nclaude plugin marketplace add zz-plant/ambit\nclaude plugin install ambit@ambit\n```\n\n`ambit-gate@ambit` is a second, separate plugin: the gate below, on every tool call. Install it once you have grants you want binding. The first plugin runs Ambit through `npx` and needs nothing else installed; the gate runs on every call, so it calls an installed `ambit` (`npm install -g ambit-cli`) to stay fast, and without one it says at the start of each session that it is inactive. By hand, without the plugin:\n\n```bash\nclaude mcp add ambit -- ambit mcp --profile=agent\n```\n\n`--profile=agent` lists the ten tools an agent that asks before it acts uses, in 4.4KB of its context. Leave the flag off for all sixty, about 19.5KB; the other fifty answer by name either way. [The deep dive](https://github.com/zz-plant/ambit/blob/main/docs/deep-dive.md#the-full-mcp-surface) names every tool and [says how a call is answered](https://github.com/zz-plant/ambit/blob/main/docs/deep-dive.md#how-a-call-is-answered).\n\nAmbit also publishes `ambit://briefing`, a resource a client reads on connect: what is reached and proven, what is failing, what is waiting on you, what blocked work in the last week, and what is worth reaching next, in about 1,200 tokens. To put it at the top of every session yourself, add a hook to `~/.claude/settings.json`:\n\n```json\n{\n \"hooks\": {\n \"SessionStart\": [{ \"hooks\": [{ \"type\": \"command\", \"command\": \"ambit briefing\" }] }],\n \"PreToolUse\": [{ \"matcher\": \"*\", \"hooks\": [{ \"type\": \"command\", \"command\": \"ambit gate\", \"timeout\": 10 }] }]\n }\n}\n```\n\nThe `PreToolUse` entry makes the gate binding in Claude Code. Before each tool call, `ambit gate` finds the capability the call exercises and answers: forbidden is a deny, asking first or having no grant yet is put to you, and anything allowed or unknown gets no answer, so Claude Code's own permissions decide. It can only narrow what Claude Code would do, never widen it, and it adds about a fifth of a second to each call. Run `ambit gate` in a terminal for the entry on its own.\n\n### OpenCode\n\n`ambit connect opencode` adds the entry to `~/.config/opencode/opencode.json` in whichever shape the file already uses, OpenCode 1's or 2's, and keeps what the file held in `opencode.json.bak` first. A file with comments is left alone, since writing it back would delete them. By hand, in OpenCode 1's shape:\n\n```json\n{\n \"mcp\": {\n \"ambit\": {\n \"type\": \"local\",\n \"command\": [\"ambit\", \"mcp\", \"--profile=agent\"],\n \"enabled\": true\n }\n }\n}\n```\n\nOpenCode 2 puts the same entry under `mcp.servers`, with `\"disabled\": false` in place of `\"enabled\": true`.\n\nBoth clients assume `ambit` is on your PATH, which Homebrew and `bootstrap.sh` both arrange; failing that, use the absolute path to `cli.js`. An agent can read the map, ask what a goal is missing, and **propose** a configuration change. Applying one always requires your approval.\n\n### The one habit worth teaching\n\n> Before running a tool you have not used this session, call `ambit_can` with\n> the capability. On `yes`, act. On `ask`, put it to the person. On `no`, it has\n> already recorded the deficit, so do not retry it under another name.\n\nThe server sends this line itself, as the `instructions` a client receives when it connects. For a client that does not pass those to its model, `ambit init-rules` writes the line into `CLAUDE.md`, `AGENTS.md` or `.cursorrules`, and an agent with a shell and no MCP asks the same question with `ambit can --exit-code`. A refusal files itself as a deficit, so the third time something is missing it shows up as infrastructure that should exist, not a wall to work around again.\n\n

\n $\"An$ \n
_{Agent: hits a block, records the deficit, asks goal, drafts a proposal · Human: approve, apply · One config patch, four capabilities. Every frame is real engine output, re-recorded by scripts/demo-agent-loop.ts.}\n

\n\n---\n\n## The map\n\n`./bootstrap.sh web` serves four views over the graph the CLI reads.\n\n- **Map**: the curated tree with your position on it. One line over it says what it found before you read a node: a capability failing its check, or else the next step that reaches the most.\n- **My Setup**: one row per entry your configs declare, with its recent check runs and the capabilities it provides. Its Briefing tab is the text an agent is given at connect, so what the agent believes about the machine can be read.\n- **Time & cost**: the work ledger, what may act without asking, what to reach next, and how the frontier moved this week.\n- **Audit**: proposals, approvals, check runs and work runs, newest first, with a query bar.\n\nSelect a node and the panel says what would stop if it went down, or what stands between it and being reached and how long that would take. **Simulate an outage** draws that cascade, red for what stops and amber for what only loses a provider; **simulate unlocking** lights what one missing piece would make reachable. Neither writes anything. Three lenses repaint the map: **Standard** (reached, next step, blocked), **Attention** (which tools keep interrupting a person) and **Authority** (what may act alone, what must ask, what is forbidden).\n\nWhen an agent proposes a change over MCP, the **Proposals** panel reads it as a plan before you sign: its steps, which of them nothing can undo, what it unlocks and costs, and how you decided on drafts like it before. Approving mints a signed artifact, and applying it is a separate `ambit apply`.\n\n[The reference](https://github.com/zz-plant/ambit/blob/main/docs/deep-dive.md#the-map-and-what-it-is-allowed-to-do) covers the rest: what each mark means, focus, the minimap, the timeline that replays the map as it was, deciding several drafts at once, and pushing one to your phone.\n\n---\n\n## How it works\n\nDiscovery reads your host configs into an embedded SQLite graph, and three surfaces read it back out: the CLI, the MCP server and the map. Discovery, verification and the work ledger write to the graph. Your agent configuration changes only through a proposal you approve, or through the map's switch for an entry that already exists, which cannot create one.\n\nEach client is read from its own standard config path, and every server stays attributed to the client that listed it. Two clients naming the same server is one capability with two providers, which is what stops Ambit counting one binary twice and calling the result redundancy.\n\nDiscovered capabilities are placed in a curated tree of nine eras: seven for the agent setup, from **Foundation** and **Model Access** through **Tool Use**, **Memory**, **Autonomy** and **Assurance** to **Sovereignty**, and two for the product it builds, **Product** (hosting, a production database, accounts, payments, email) and **Operations** (error tracking, analytics, uptime, backups, and **Launch Ready**, reached when the launch checklist is done). Because each capability records what it needs, Ambit works out what you can reach without taking a config file's word for it, which combos emerge from tools configured apart, and which near misses are one or two prerequisites from unlocking several others.\n\n### Configured is not working\n\nAmbit keeps two properties apart, and the distinction is load-bearing:\n\n- `state` is **structural**: is this thing configured, and what does it depend on. This is what the frontier ledger records.\n- `lifecycle` is **health**: did its declared verification command actually pass. A capability can be fully configured and still `degraded` or `broken`.\n\nEvery availability decision gates on lifecycle, not state. A broken capability is excluded from plans, simulations, goals, authority checks and opportunity ranking, because a plan routed through a tool that does not run is worse than no plan. `ambit status` reports proven, unproven and failing counts, and the map badges each reached node: `✓` for a passing check, `!` for a failing one, nothing for configured but never verified.\n\n### Fragility is computed, not guessed\n\n- **Single points of failure**: capabilities with exactly one provider.\n- **Bottlenecks**: nodes ranked by how much sits downstream of them. The map marks the same idea on each node, as a keystone.\n- **Shared credentials**: providers presenting the same credential fail together, so three providers behind one token is not redundancy. This one is declared, never inferred: name the sharers in a `credentials` block and `ambit impact credential:...` shows what revoking it would end.\n\n---\n\n## The control plane\n\nHost-level agent tooling is a real attack surface, so execution goes through an interceptor and never straight to the shell. Before a tool call reaches your machine, the proxy in `src/control_plane/proxy.ts` checks three things: are this capability's prerequisites in place, is it actually working, and is the caller allowed to do this. A call that fails any of them is refused (`AMBIT_BLOCKED_UNAUTHORIZED`, exit code `2`) and nothing on the machine changes. A blocked call drafts a proposal and an HMAC challenge; `ambit approve ` mints a signed artifact the executor verifies, and it stops being valid if the proposal changed after approval or has expired. Spans record each evaluation, challenge and receipt.\n\nThe decision is real and runs against your actual graph. What sits on the other side of the gate is a fixture: `simulatedAdapter` keeps its state in a JSON file, and Ambit ships no deployment integration. A real one implements the three-method `EnvironmentAdapter` in the same file, and nothing above the gate changes. [`INCIDENT_TRACE_001`](https://github.com/zz-plant/ambit/blob/main/docs/incidents/INCIDENT_TRACE_001.md) walks a deploy agent blocked mid-flight and then remediated, and `npm run demo:incident` replays it in 90 seconds.\n\n---\n\n## Security invariants\n\nAmbit reads developer toolchains and writes to agent configs, so four properties are fixed and cannot be relaxed. [`SECURITY.md`](https://github.com/zz-plant/ambit/blob/main/SECURITY.md) states each in full, with what is in scope and what is not; [`AGENTS.md`](https://github.com/zz-plant/ambit/blob/main/AGENTS.md#security-posture) says where each is enforced.\n\n1. **Loopback only.** The API server binds `127.0.0.1`. No LAN, no tunnel.\n2. **Origin allowlist.** A request with a non-local `Origin` is rejected with 403 *before* routing, because a simple request skips preflight and response headers alone would not stop it.\n3. **No entry creation over HTTP.** The HTTP layer edits entries that already exist and nothing else. An MCP entry carries a command the runtime later executes, so creating one over HTTP would be remote code execution; adding a server returns a snippet for you to paste.\n4. **No egress you did not type.** The graph is an embedded SQLite database on your machine, and there is no telemetry. Five commands open a socket from Ambit's own code (`notify`, `notify-approvals`, `dispatch`, `incidents`, and `goal --judge`). The first four each need a target you name, and the last refuses any host but this machine. A declared check is a command and may reach the network as well, so checks run only from `verify` and `apply` or an agent's `ambit_verify`, and never from the server. [The FAQ](https://github.com/zz-plant/ambit/blob/main/docs/faq.md#does-anything-leave-my-machine) lists exactly what each one sends.\n\n---\n\n## Documentation\n\n- [FAQ](https://github.com/zz-plant/ambit/blob/main/docs/faq.md): what needs installing, what leaves the machine, why the attention commands are empty on day one.\n- [Deep dive](https://github.com/zz-plant/ambit/blob/main/docs/deep-dive.md): the reference for the model under everything above, the map in full, and where Ambit sits in the revisable-delegation loop.\n- [Where each AI agent keeps its MCP config](https://github.com/zz-plant/ambit/blob/main/docs/mcp-config-locations.md) · [What breaks if an MCP server goes down](https://github.com/zz-plant/ambit/blob/main/docs/mcp-outage.md) · [Auditing an agent's MCP servers](https://github.com/zz-plant/ambit/blob/main/docs/audit-mcp-servers.md) · [Ambit and MCP gateways](https://github.com/zz-plant/ambit/blob/main/docs/compare.md): the questions people search for, answered with the commands above.\n- [Security](https://github.com/zz-plant/ambit/blob/main/SECURITY.md) · [Agent invariants](https://github.com/zz-plant/ambit/blob/main/AGENTS.md) · [Support](https://github.com/zz-plant/ambit/blob/main/SUPPORT.md) · [Contributing](https://github.com/zz-plant/ambit/blob/main/CONTRIBUTING.md): the invariants above in full, where each is enforced, where each kind of question goes, and how to send a change.\n- [Everything else](https://github.com/zz-plant/ambit/blob/main/docs/): the argument, the theory, Jev, the design notes, the changelog, the incident traces.\n- [`llms.txt`](https://zz-plant.github.io/ambit/llms.txt): the project in one page, for an agent that is deciding whether to recommend it.\n\n---\n\n## Contributing\n\nNew capability models, runtime readers, visualization work and edge-case reports are all welcome. Issues labelled [good first issue](https://github.com/zz-plant/ambit/labels/good%20first%20issue) are scoped to an afternoon and name the files to start from. [CONTRIBUTING.md](https://github.com/zz-plant/ambit/blob/main/CONTRIBUTING.md) gets you from a clone to a passing pull request and [lists every check CI runs](https://github.com/zz-plant/ambit/blob/main/CONTRIBUTING.md#the-checks-ci-runs).\n\n---\n\n## Support the project\n\nAmbit is a personal project. If it answered a question your config files could not, [a star](https://github.com/zz-plant/ambit/stargazers) is how the next person with the same stack finds it.\n\n- Post an `ambit share --redact` snapshot of your own map. The file names nothing on your machine, and every real graph is an argument the demo cannot make.\n- Report the runtime it does not read yet, or the capability it models wrong. Both are [issue templates](https://github.com/zz-plant/ambit/issues/new/choose).\n- To hear when a new runtime reader or capability lands, choose **Watch → Custom → Releases**.\n\n---\n\n## License\n\n[MIT](https://github.com/zz-plant/ambit/blob/main/LICENSE) © Kanav Jain\n","changelogMarkdown","videoKey","requiredSecretsJson","publishedAt",1791252842000,"priceCents","trialDays","iconType","image","upstream",{"_147":148,"_120":121,"_149":150,"_151":152,"_140":141,"_124":153},"requiredSecrets",[],"tags",[],"assets",[],"stats",{"_145":44,"_146":44},"card",{"_20":22,"_98":24,"_99":26,"_18":19,"_100":28,"_84":85,"_101":102,"_103":37,"_104":-5,"_105":106,"_107":108,"_109":110,"_111":-5,"_112":44,"_113":60,"_49":114,"_115":116,"_117":-5,"_118":119},"name","description","iconUrl","kind","server","hosting","provenance","safety",{"_101":144},"capability","unknown","access",{"_143":30,"_130":131},"contents","priceMicro","stars","2026-10-06T04:25:51.000Z","problems",[],"nsfw","details",{"_73":74,"_120":121,"_122":123,"_124":125,"_126":60,"_127":44,"_47":128},"license","MIT","links",[136,137,138],"packages",[129],"forks","openIssues","2026-05-26T16:57:25Z",{"_130":131,"_98":132,"_73":74,"_133":134,"_104":135},"registry","npm","ambit-cli","weeklyDownloads",130,false,{"_101":142,"_139":68},{"_101":140,"_139":141},{"_101":130,"_139":54},"href","homepage","https://zz-plant.github.io/ambit/","repo","via","unassessed","ratingAvg","reviewCount","topics",[157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,176],"language","TypeScript","registryName","io.github.zz-plant/ambit",[154],{"_155":131,"_156":132,"_73":74},"registryType","identifier","agent-infrastructure","ai-agents","ai-governance","audit-log","capability-graph","claude-code","claude-desktop","cli","codex-cli","cursor","dependency-graph","developer-tools","gemini-cli","human-in-the-loop","local-first","mcp","mcp-server","modelcontextprotocol","opencode","windsurf","ENV",{"_179":180,"_181":182,"_183":184,"_185":-7},"ENVIRONMENT","production","TURNSTILE_SITE_KEY","0x4AAAAAAB8-rEI2gNDf_QhU","SENTRY_DSN","https://45fd1229f78089d5c3ee78be128030e1@o4510583261757440.ingest.de.sentry.io/4510584253448272","SENTRY_ENABLE_LOCAL"]