Governance & Approvals

Governance is how you stay in control of an autonomous company. Capx gives you approval queues, spend caps, kill switches, execution policies, and escalation paths, all configurable in YAML and enforceable at runtime.

Why governance matters#

An agent-run company can execute hundreds of actions per day. Governance is the safety net that ensures agents operate within boundaries you define.

All governance rules are defined in the governance section of your company.yaml. They are enforced by the runtime before every action, not after. An agent cannot bypass governance rules even if a playbook explicitly instructs it to.

Approval queue#

The approval queue is the primary human-in-the-loop mechanism. When an agent encounters an action that requires approval, it pauses, writes the proposed action to the queue, and waits. The founder reviews the action in the Casa dashboard or via the CLI and either approves or rejects it.

How it works

# List pending approvals
capx approve list --company my-company

# View details of a specific approval
capx approve show act_7x9k2m --company my-company

# Approve an action
capx approve yes act_7x9k2m --company my-company

# Reject an action with a reason
capx approve no act_7x9k2m --company my-company --reason "Wrong audience segment"

# Approve all pending actions from a specific agent
capx approve yes --agent marketer --company my-company --all

Auto-approve thresholds

Not every action needs manual review. The auto_approve block lets you define thresholds below which actions are approved automatically. This keeps your approval queue manageable while still catching high-risk actions.

governance:
  auto_approve:
    max_cost: 50                # Auto-approve if estimated cost < 50 credits
    allowed_tools:              # Always auto-approve these tools
      - send_message
      - search_web
      - search_docs
      - generate_copy
    blocked_tools:              # Never auto-approve (always require approval)
      - send_email
      - deploy
      - publish_post
      - delete_resource
    trusted_agents:             # Auto-approve all actions from these agents
      - strategist

Spend caps#

Spend caps are hard limits on credit consumption. They operate at two levels: per-agent and per-company. When a cap is hit, the affected agent (or the entire company) is paused and the founder is notified.

Per-agent caps

Per-agent caps are set in the agent's budget block (see the Configuring Agents guide). They limit daily, monthly, and per-task spending for a single agent.

Per-company caps

Company-level caps limit total spending across all agents. They are defined in the governance section and act as an outer boundary even if individual agent budgets would allow more.

governance:
  spend_caps:
    daily: 5000                  # Max 5,000 credits/day across all agents
    monthly: 80000               # Max 80,000 credits/month
    per_action: 500              # Max credits for any single action
    alert_thresholds:
      - at: 0.5                  # Alert at 50% of daily/monthly cap
        notify: dashboard
      - at: 0.8                  # Alert at 80%
        notify: [dashboard, email]
      - at: 0.95                 # Alert at 95%
        notify: [dashboard, email, sms]

Kill switches#

Kill switches let you immediately stop an agent or an entire company. They are the emergency brake for situations where something has gone wrong and you need to halt all activity right now.

Agent-level kill switch

Killing an agent immediately stops all its activity. Any in-flight steps are cancelled. Queued tasks remain in the queue but are not executed. The agent's memory is preserved and can be exported, but the agent itself cannot be restarted.

# Kill a specific agent immediately (permanent)
capx agent kill marketer --company my-company --confirm

# Pause instead (reversible: agent can be resumed)
capx agent pause marketer --company my-company

# Resume a paused agent
capx agent resume marketer --company my-company

Company-level kill switch

The company freeze command stops all agents, cancels all in-flight steps, and puts the company into a frozen state. No playbooks execute, no heartbeats fire, and no actions are processed until the founder explicitly resumes.

# Freeze the entire company (reversible)
capx company freeze my-company --confirm

# Resume the company
capx company resume my-company

# Check company state
capx company status my-company

State preservation

Both agent kill and company freeze preserve all state. Agent memory, task queues, playbook execution history, and cost ledger data are retained. When you resume a frozen company, agents pick up where they left off: pending tasks are still in the queue, and the next heartbeat processes them normally.

Execution policy#

Execution policies control what agents are allowed to do, independent of approval rules. They define which tools are available, how many actions can run concurrently, and what resources agents can access.

Allowed and blocked tools

You can operate in either allowlist mode (only listed tools are available) or blocklist mode (all tools are available except listed ones). Tool restrictions apply company-wide. If a tool is blocked at the governance level, no agent can use it even if the agent's role definition includes it.

governance:
  execution_policy:
    tools:
      mode: allowlist             # or "blocklist"
      # In allowlist mode, only these tools are available
      allow:
        - send_message
        - search_web
        - generate_copy
        - create_task
        - search_docs
        - query_database
        - write_code
        - create_pr
      # In blocklist mode, all tools available except these
      # block:
      #   - delete_resource
      #   - drop_table
      #   - send_sms
      #   - format_disk

Concurrency limits

Concurrency limits prevent resource contention and keep costs predictable. When the limit is reached, new steps are queued according to the queue_strategy.

governance:
  execution_policy:
    concurrency:
      max_parallel_steps: 5       # Max steps running simultaneously across all agents
      max_parallel_per_agent: 2   # Max steps per individual agent
      queue_strategy: fifo        # fifo or priority
      max_queue_depth: 100        # Max queued steps before rejecting new ones
      max_step_duration: 30m      # Hard timeout for any single step

The prioritystrategy uses the playbook step's priority field (if set) to order the queue. Steps without an explicit priority default to medium. Priority levels are: critical, high, medium, low.

Escalation paths#

Escalation paths define what happens when an agent cannot complete a task. The rubric score is too low, the budget is exhausted, a tool fails repeatedly, or the agent is uncertain about a decision. Each path specifies a target, a notification method, and a timeout behavior.

governance:
  escalation:
    paths:
      - name: senior_agent
        target: agent:strategist
        notify: [internal]
        timeout: 1h
        on_timeout: escalate       # Forward to next path in chain
        next: founder_review

      - name: founder_review
        target: founder
        notify: [dashboard, email]
        timeout: 24h
        on_timeout: pause          # Pause the step indefinitely

      - name: urgent
        target: founder
        notify: [dashboard, email, sms]
        timeout: 4h
        on_timeout: pause

    default_path: senior_agent     # Used when no specific path is defined

Role-based access#

If your company has multiple human team members (co-founders, employees, contractors), you can assign roles that control what each person can do in the Casa dashboard and via the API.

team:
  - email: founder@example.com
    role: owner

  - email: cto@example.com
    role: admin

  - email: ops@example.com
    role: operator

  - email: analyst@example.com
    role: viewer

Roles are additive: an admin has all the permissions of an operator plus the ability to edit configuration and manage agent lifecycle. The owner role is automatically assigned to the account that created the company and cannot be removed.

Full governance configuration#

The following is a complete governance block suitable for a production company. It combines approval rules, spend caps, execution policies, and escalation paths.

governance:
  auto_approve:
    max_cost: 50
    allowed_tools:
      - send_message
      - search_web
      - search_docs
      - generate_copy
      - create_task
    blocked_tools:
      - send_email
      - deploy
      - publish_post
      - delete_resource
      - run_command
    trusted_agents:
      - strategist

  spend_caps:
    daily: 5000
    monthly: 80000
    per_action: 500
    alert_thresholds:
      - at: 0.5
        notify: dashboard
      - at: 0.8
        notify: [dashboard, email]
      - at: 0.95
        notify: [dashboard, email, sms]

  execution_policy:
    tools:
      mode: blocklist
      block:
        - drop_table
        - delete_database
        - format_disk
    concurrency:
      max_parallel_steps: 8
      max_parallel_per_agent: 3
      queue_strategy: priority
      max_queue_depth: 200
      max_step_duration: 30m

  escalation:
    paths:
      - name: senior_agent
        target: agent:strategist
        notify: [internal]
        timeout: 1h
        on_timeout: escalate
        next: founder_review
      - name: founder_review
        target: founder
        notify: [dashboard, email]
        timeout: 24h
        on_timeout: pause
      - name: urgent
        target: founder
        notify: [dashboard, email, sms]
        timeout: 4h
        on_timeout: pause
    default_path: senior_agent

team:
  - email: founder@example.com
    role: owner
  - email: cto@example.com
    role: admin
  - email: ops@example.com
    role: operator

Best practices#

• Start strict and loosen over time.Begin with low auto-approve thresholds and a short list of allowed tools. As you build confidence in your agents' behavior, gradually raise thresholds and expand tool access. The activity feed shows every action your agents take, so you can audit before you trust.
• Review your approval queue at least once a day during the first two weeks. Early approvals teach you which actions are routine (and should be auto-approved) and which are genuinely risky (and should stay in the queue). Most founders find that after two weeks, 80-90% of actions can be safely auto-approved.
• Freeze first, investigate second. Use the company freeze command as a circuit breaker during incidents. If something goes wrong, freeze first and investigate second. You can always resume once you understand the issue. The cost of a few hours of downtime is always lower than the cost of an unchecked runaway agent.

Next steps#