An agent is only as useful as what you let it touch, and only as safe as what you keep out of its reach. Capability is the discipline of connecting your agent to the systems the task calls for: the test runner that proves its work, the PR tooling that carries a change toward review, the staging environment where it can try things without consequence. The other half of the discipline is deliberate withholding: production, the credentials that open it, and the destructive commands are kept where no prompt can reach them.
Get that surface right and your team moves fast on the work that matters, while the actions that could wreck something are simply not reachable: fewer incidents from a confident agent reaching too far, and a much smaller mess to clean up when something does slip.
What Capability owns is the reach itself, the call about whether a tool or command is connected at all and whether a dangerous one is taken back off the table. The judgment of which actions an agent may take on its own is Delegation, and the harness of checks it has to clear is Environment. The question it leaves you with is how much of your safe surface lives in one careful engineer's local setup, and how much is written down where every agent inherits it by default.
Exploratory
The agent has whatever access the tool shipped with, and no one chose it.
- Enables
- A fast start, and a live read on which tools the work actually leans on. What you reach for and what you never touch is what a scoped surface later gets built around.
- Deficiencies
- Nothing scopes the surface, so a destructive command or a wrong-account push is one prompt away.
- Cost to maintain
- Incidents and cleanup when the agent does something it should never have been able to do.
Techniques
None yet. Manual and ad hoc.
Expert-led
One security-minded engineer hardens their own setup, and only theirs.
- Enables
- A safe surface for the people who copy that engineer's config.
- Deficiencies
- A single point of failure. Their posture is not written down, and everyone else still runs the defaults.
- Cost to maintain
- That engineer's time tuning the allow-list and fielding “why can't the agent do X” questions.
Techniques
- . A settings file that enumerates exactly which commands an agent may run, started from zero and widened only as the work needs it, so its reach is a reviewed decision rather than a default.
- . Scripts that wrap standard CLI tools with guardrails (credential routing, identity checks, confirmation on destructive operations) so the safety lives in the tool rather than in the prompt.
Documented
“Don't give it prod” is a written rule the team follows by convention and review.
- Enables
- A shared posture new people inherit from the doc rather than from one person's laptop.
- Deficiencies
- Still enforced by humans. A missed review or an ignored line and the rule does nothing.
- Cost to maintain
- Writing the policy, plus the human attention to catch breaches before they ship.
Techniques
- . Explicit do-not lines written into skills and orientation docs, ruling out whole classes of action without asking the agent to weigh the alternatives.
- . A settings file that enumerates exactly which commands an agent may run, started from zero and widened only as the work needs it, so its reach is a reviewed decision rather than a default.
- . Scripts that wrap standard CLI tools with guardrails (credential routing, identity checks, confirmation on destructive operations) so the safety lives in the tool rather than in the prompt.
Structural
Allow-lists and scoped connections are checked into the repo. The agent cannot exceed the posture without a tracked change.
- Enables
- The posture survives turnover and applies to every agent automatically, and breaches need a reviewed commit.
- Deficiencies
- An over-tight list blocks real work, loosening it has friction, and the rules need upkeep as tools change.
- Cost to maintain
- Upfront engineering to build the controls in, plus tuning the surface as the work evolves.
Techniques
- . A settings file that enumerates exactly which commands an agent may run, started from zero and widened only as the work needs it, so its reach is a reviewed decision rather than a default.
- . Scripts that wrap standard CLI tools with guardrails (credential routing, identity checks, confirmation on destructive operations) so the safety lives in the tool rather than in the prompt.
- . Config plus install scripts that propagate a skill or doc from one place to every project, so an update in one repo lands in all of them.
- . Standardized host scripts (lint, test, e2e) the agent runs and reads the exit code from, so checks fire before a human sees the output.
Capability rarely stands alone. Where it overlaps a sibling discipline, an investment on one side quietly depends on the other. The Control domain page lays these out in full.
- Capability and Delegation
Capability sets what the agent can reach; Delegation sets what it is trusted to decide on its own. Connect a tool but reserve every call about it and you have a locked drawer; hand over a decision for a system the agent cannot touch and you have named a responsibility it has no way to exercise.
Buy both in step, and reach and judgment cover the same work; buy one ahead of the other and you pay for a surface no one is cleared to use.
- Capability and Environment
Every tool you connect through Capability raises the stakes Environment has to hold. A wider reach is more the agent can break, and the harness of gates and isolation is what turns that reach into throughput instead of cleanup.
Grow the surface faster than the guardrails and each new connection is one more unwatched way to cause damage; grow the guardrails with no new reach and you have hardened a cage around work the agent cannot do anyway.
The agent has what it needs to act.
- CollectionGetting context in: gathering the artifacts an agent needs to orient.
- ManagementKeeping the context your agents read current as decisions and conventions change.
- DisclosureFeeding context in efficiently: routing the agent to the slice it needs, not a data dump.
The agent can only do what it should.
- Capability (current page)What the agent can do: the tools you connect, and the ones you deliberately withhold.
- DelegationWhat the agent should do: the responsibilities you hand over, and the ones you reserve.
- EnvironmentThe system the agent works within: the tests and gates its work must clear, and the points where a human takes over.
The human can see what happened.
- CaptureMaking sure every run leaves a raw record.
- AvailabilityPutting the record of agent work where your team can query and review it.
- TraceWalking back through a single run, end to end, with the reasoning alongside the decisions.
The team gets better over time.
- EvaluationMeasuring whether your processes work, by the numbers and by gut-check.
- PrioritizationChoosing what to change and where to invest next.
- ConvergenceMaking a change stick across the team.