Ambit glossary
Every word the map, the CLI and the MCP server use, defined once. The same file is what the app’s Docs overlay, its term popovers and ambit help <term> read, so a definition here is the one the interface shows.
#Ambit
What you, your agents and your machines can jointly do. Your ambit is everything your setup can actually do, which is more than any config file says: capabilities compose from pieces configured separately, and only count once they are proven to work. The frontier is its edge, the next steps just past it are how it widens, and the capability graph is the model that computes it. The theory documents call the same object the affordance frontier. Widening it is what the product is for; checks, authority and approvals are what make each widening safe to lean on.
#Capability
One thing your agent setup can do. Every MCP server, agent, skill, provider, model and command in your config becomes a capability. So do the nodes of the curated tech tree. A capability is the unit everything else is measured against.
#Era
How far up the tree a capability sits. The tech tree runs through seven eras: Foundation, Model Access, Tool Use, Memory, Autonomy, Assurance, Sovereignty. Later eras depend on earlier ones — you cannot run fully offline before you have a local runtime. Eras describe ordering, not importance.
#Reached, next step, blocked
Where you are on a tech tree node. Reached: something in your config provides this, and the graph records which capability proved it. Next step: prerequisites are met but nothing was detected — these sit just past the frontier, and `ambit goal` lists it. Blocked: you have the tooling but a prerequisite is missing, e.g. retrieval configured with no vector store. Blocked is usually the most informative of the three.
#Required vs optional prerequisite
Whether a dependency gates a capability, or only helps. A required prerequisite must be in place or the dependent capability cannot work — a model cannot run without its provider. An optional one strengthens something without gating it. Only required prerequisites block a node from being reached; both are drawn, with optional ones fainter. The data model and the CLI call these hard and soft.
#Keystone
A capability many others depend on. Ranked by how many capabilities would be affected if it disappeared. High-leverage to invest in, and risky to leave unmaintained. `ambit impact <id>` shows exactly what falls over. The map marks a node with three or more dependants; `ambit status` reports the same idea under the heading bottlenecks, counting only the combos a capability unlocks, so the two lists overlap without being identical.
#Combo
A capability several others unlock. The tech tree nodes are combos, and you can define your own in a `combos` block for things specific to your work. A combo is a judgement about what composes into something new, which is why the tool never invents one from your config.
#Tool server
A tool your agent can call. An MCP server, which is the protocol agents use to reach tools. Everything the server exposes — reading a file, opening a page, querying a database — becomes something the agent can do, which is why one server switched off can take a row of capabilities with it.
#Verified
Proven to work, not just configured. Detection proves a name appears in a config file. Verification runs a declared read-only check and records the result, so a capability can be said to work rather than to exist. Reliability is the share of recorded runs that passed, which is why the history is kept: one success is a weaker claim than forty-seven of fifty. Checks execute, so they live in the repository and run only when asked — never on seed.
#Maturity
A 0-1 estimate of how established a capability is. Seeded from what kind of thing it is and whether it is enabled, then adjusted as your config changes. It is a rough ordering signal, not a measurement — treat a 0.8 as 'more settled than a 0.5', not as a score that means anything on its own.
#Domain
The area of work a capability belongs to. infra, devops, backend, frontend, ai-ml, quality, security, or meta. Inferred from the capability's name, which means a stack unlike the keyword table's assumptions will land more things in the meta fallback — that table is the first thing to edit.
#Attention
Time you spent stepping in so an agent could continue. Every recorded moment where a person had to step in — approve, correct, copy something across — priced at what an hour of your time is worth. The Attention lens shades the map by how often each capability demanded it; Time & cost ranks what removing it would save. Judgment and knowledge are never counted as reducible, however often they recur.
#Proposal
A change to your setup, drafted for a person to approve. An agent that finds a gap drafts a proposal rather than acting: the steps, their inverses, and what the frontier would look like afterwards. Approving it mints a signed artifact that expires; `ambit apply` verifies that signature before anything runs, and refuses if the proposal changed after approval.
#Authority
Whether it may run, not whether it can. Being technically able to perform an action is not permission to perform it. Authority is tracked separately per capability — observe and execute, each autonomous, confirm, or forbidden — so a reached capability can still require approval. A reached capability no grant names is refused until someone grants one, and the map says "no grant yet" apart from a refusal somebody wrote. This is what lets a larger technical surface stay governable: the limits are explicit rather than implied.
#Joint capability
One the agent cannot supply alone. Some of what a setup can do exists only when a person or a machine takes part. The engine derives it from structure, not from names: a person who must approve a capability makes it institutional, one who supplies it makes it cognitive, a provider running on a device makes it physical, and a person and a machine supplying it together is the case where the ability sits in the loop and in neither half. A recurring acquisition cost is economic. The map marks the joint ones with a person or a device; the panel names who.
#Frontier
The edge of your ambit, as of a moment. The frontier is where your ambit ends: everything reached, with the next steps just past it. Every seed records it, so the graph can answer what was reachable at a past date and not only now. `ambit history since` compares two of those observations. Its useful column is the emergent one: capabilities that became reachable although nothing providing them was added, which happens when prerequisites are satisfied by something else entirely. A per-component changelog cannot show those, because no single change explains one.
#Decay
What you have stopped tending. `ambit decay` ranks capabilities by how long since their configuration last changed. It tracks configuration decisions, not how often you invoke something — a server you use daily but never reconfigure will look static, which is intentional. The question it answers is 'what have I stopped tending', not 'what do I use least'.