Capabilities
What Capabilities controls
The Capabilities panel (sidebar → Capabilities) is where you toggle individual agent abilities on or off. Some capabilities are safe and always available; others interact with external services, modify files, or control hardware — and these have risk levels and optional confirmation requirements.
Think of this as the master switch panel for what the agent is allowed to do at all — more specific than your Authority Policy, which governs who it may act toward.
Run modes
At the top of the Capabilities panel:
| Mode | Description |
|---|---|
| Docker | Agent runs code in isolated containers — recommended, safer |
| Native | Agent runs code directly on your host machine — faster but less sandboxed |
Some capabilities are only available in one mode. The panel shows which ones are available given your current run mode.
Capability categories
Each capability has:
- Label — what it does
- Risk level — Safe / Low risk / Medium risk / High risk
- Enable toggle — on/off
- Value (some capabilities) — a URL, path, or token the capability needs
- Confirmation required (some capabilities) — whether a HITL approval fires before each use
Safe capabilities (always available)
| Capability | What it does |
|---|---|
| Web search | Search the web via DuckDuckGo and fallback engines |
| Web fetch | Fetch and read web pages |
| File read | Read files from the workspace |
| Memory search | Search episodic and vector memory |
| Knowledge base search | Query uploaded documents (RAG) |
| Document generation | Create Excel, Word, PPTX, PDF, HTML files |
| Chart generation | Create Mermaid and chart.js visualizations |
Low-risk capabilities
| Capability | Risk | Notes |
|---|---|---|
| File write | Low | Write files to the workspace directory only (sandboxed) |
| Run a Python script | Low | Runs in an isolated sandbox, with a memory cap and a short time limit |
| Run a Node script | Low | Runs in an isolated sandbox, with a memory cap and a short time limit |
| Execute shell | Low | Sandboxed allowlist — only pre-approved commands |
| Query a database | Low | Read-only against a connected database — PostgreSQL, MySQL, Oracle or a local file. It cannot write back. |
| arXiv search | Low | Read-only academic paper search |
| RSS feed | Low | Read-only feed parsing |
Medium-risk capabilities
| Capability | Risk | Notes |
|---|---|---|
| Browser automation | Medium | Navigates real websites; may trigger bot detection |
| GitHub write | Medium | Can create issues, PRs, comments in your repos |
| Notion write | Medium | Can create and modify pages in your workspace |
| Jira write | Medium | Can create and update issues in your Jira |
| Slack send | Medium | Sends messages to channels or DMs |
| Email send | Medium | Sends email from your account |
High-risk capabilities
| Capability | Risk | Notes |
|---|---|---|
| Stripe write | High | Financial operations — charges, refunds, subscriptions |
| HubSpot write | High | CRM data modification — contacts, deals |
| AWS S3 write | High | Cloud storage modification — uploads, deletes |
| Phone calls (outbound) | High | Places real phone calls via Twilio |
| Host desktop control (T4) | High | Full host OS control — native apps, keyboard, mouse |
| Database write | High | Production database modifications |
High-risk capabilities have Confirmation required enabled by default. Even if your authority policy says auto, a high-risk capability will still require an explicit confirmation unless you turn off the confirmation requirement for that specific capability.
Enabling a capability
- Go to sidebar → Capabilities
- Find the capability you want to enable
- Toggle the switch to On
- If the capability requires a value (e.g., a Twilio account SID), fill in the field
- If prompted with a confirmation dialog, review and confirm
Some capabilities also need the relevant service connected first. If it isn’t, the toggle tells you which credential is missing — rather than letting the capability fail later, mid-task.
Confirmation dialogs
Capabilities marked Confirmation required show a dialog before every single use:
⚠️ High-risk action
The agent wants to:
Place an outbound phone call to +91-98765-43210
This action cannot be undone.
[Cancel] [Confirm]
This is separate from, and additional to, the approval request that reaches your messaging channel. This dialog appears in the app before the action runs; your authority policy may then ask you as well, depending on the action and who it affects. Two gates, not one.
Capability values
Some capabilities need a configuration value to work:
| Capability | Value field | Example |
|---|---|---|
| Outbound phone calls | Your phone service account | The account the calls are placed from |
| Running commands | Which commands are allowed | A pattern, so nothing outside it can run |
| Desktop control | Which applications are allowed | Only the apps you list can be driven |
These values are held encrypted in the credential vault, never in plain text.
Ask the agent about itself
You can ask the agent directly what it can do — "what can you do?", "can you act as a company brain?", "are you reachable by other agents?" — and it answers from its own current capabilities rather than generic assistant boilerplate. This is the fastest way to discover what's available on your instance.
What it can describe
The agent groups its answer into two kinds of capability:
Agent capabilities — things it does for you (any user):
| Surface | What it means | Where to learn more |
|---|---|---|
| Goal execution | Run multi-step goals end-to-end and return verified deliverables | Goal Execution |
| Company Brain | Search your organisation's shared knowledge, kept current from connected sources | Knowledge & Mindmaps |
| Human Proxy | Act as you across email, Slack, Telegram, and phone — approval-gated | Human Proxy |
| Meeting Proxy | Join meetings, respond in your voice, deliver a summary and action items | Meeting Proxy |
| AI-Native Services | Run serviced workflows end-to-end and deliver the actual outcome | Service Pilot |
| Proactive Engine | Monitor your goals and act on a schedule without being asked | Proactive Engine |
Admin / operator features — how the instance is run (admin-only):
| Surface | What it means | Where to learn more |
|---|---|---|
| Accounts and membership | Who may sign in, and what stays private to each person | Accounts & Sign-in |
| Agent API | Make the instance discoverable by and callable from other agents | Agent API · Agent Mesh |
| Shared knowledge sources | Sources that sync into everyone's knowledge base | Knowledge Base |
What to expect
- Every user sees the same description, but admin/operator features are clearly labelled admin-only — the agent will not tell a regular user they can perform an admin-gated action.
- The agent describes what the platform offers; toggling a specific capability on or off is still done in the Capabilities panel and the relevant guide above.
If a capability you expect isn't mentioned, check that it's enabled in the Capabilities panel and that any service it needs is connected. Admin-only surfaces are configured by whoever administers the instance.
The difference between Capabilities and the Authority Policy
| Capabilities | Authority Policy | |
|---|---|---|
| Controls | Whether a tool can be used at all | Who the agent can act on behalf of, and with what approval |
| Granularity | Per-tool type (e.g., "Stripe write") | Per action + counterparty class (e.g., "reply_email to client") |
| Where | Capabilities panel in UI | workspace/AUTHORITY.md |
| Example | "Stripe write: Off" → agent can never call Stripe write tools | "payments.* → Block" → agent refuses all payment actions |
Use Capabilities to control what tools exist. Use Authority Policy to control the approval flow for those tools.