Tools & permissions

During task execution each agent gets a set of tools, gated by a capability policy — an allow / ask / deny model inspired by opencode. Capabilities map to the claude binary’s tool flags (and a couple of runtime directives).

The capabilities

capability	grants	default
code	Bash, Read, Write, Edit, Glob, Grep — run commands, write and execute code	allow
consult	Task — spawn sub-agent consultants	allow
web	WebSearch, WebFetch — research the open web	allow
delegate	hand a subtask down to a report via DELEGATE[<id>]: (a runtime directive)	allow
hire	employ a new specialist via HIRE[<role>]: (lead/managers; a runtime directive)	allow
schedule	book a future goal via SCHEDULE[<when>]: — see Triggers (a runtime directive)	allow
crm	shared contacts (reserved for a future org CLI over the CRM)	ask

The built-in base is allow for everything except crm (ask).

The three decisions

decision	effect on tool exposure
allow	tool added to the binary’s --allowedTools
deny	tool withheld (--disallowedTools)
ask	tool withheld (like deny) plus a REQUEST[capability:<x>] raised for you to grant next cycle

Why ask withholds rather than pauses

A headless task run streams a single, non-interceptable agentic turn, so there’s no point at which the runtime could pause mid-call for an approval. Rather than silently upgrading ask to allow — which would make a configured approval gate a no-op — ask withholds the tool and surfaces a request. The enforced model is honest allow/deny at runtime, with ask routed through you. When you grant it, the originating task re-opens and retries next cycle with the capability in hand.

Resolution order

A capability is resolved per-agent → org default → built-in base:

1. The agent’s own capabilities frontmatter, if set.
2. Otherwise the org’s defaults.capabilities.
3. Otherwise the built-in base.

# org-wide default
- defaults: { "capabilities": { "crm": "allow", "hire": "ask" } }

### Engineer
# this agent overrides the default for itself
- capabilities: { "hire": "deny", "delegate": "deny" }

Reading vs. writing shared data

Agents read the shared org data directly — it’s just files — and produce their work as files and artifacts. But the structured stores (goals, tasks, crm) are owned and written by the runtime, not hand-edited by agents. That keeps those stores schema-valid, atomic, and fully audited. See Internal systems.

Common patterns

• A read-only researcher — { "code": "deny", "web": "allow" }: can search the web and write findings, but not run commands.
• A locked-down junior — { "hire": "deny", "delegate": "deny" }: does the work it’s given and nothing more; can’t grow the team or route around review.
• A gated CRM owner — give one agent { "crm": "allow" } and leave the rest at the ask default, so only that role touches customer relationships.