Trust by Design: Governance for Agent-Run Companies

Every week a new story surfaces: an AI agent sends a thousand emails to the wrong list, racks up a four-figure API bill overnight, or publishes a social post the founder never approved. The common thread is not that the model was bad. The model was fine. The governance was missing.

Capx Casa is built governance-first. Four mechanisms sit between an agent deciding to act and the action actually happening. Every action passes through them, every time, with no exceptions.

Mechanism 1: The approval queue

Not every action should execute automatically. Publishing a blog post, sending an outbound email campaign, or making a purchase over a certain amount should require human sign-off. The approval queue holds these actions in a pending state and notifies the founder.

# content-publish
name: publish-blog-post
execution:
  mode: review          # auto | review | blocked
  notify: [email, dashboard]
  timeout: 24h          # auto-reject if not reviewed in 24h
  escalation:
    after: 12h
    action: remind

# The agent cannot bypass this.
# Even if the model "decides" to publish,
# the platform holds the action until approval.

The key insight: the approval queue is not a UI feature bolted on after the fact. It is enforced at the platform level. The agent literally cannot execute a review-mode action without founder approval. There is no prompt injection, no creative reasoning, and no edge case that bypasses it.

Mechanism 2: Spend caps

Every company has a credit budget. Credits are consumed by model inference, tool calls, and external API usage. Spend caps operate at two levels: per-action and per-period.

# company-policy
spend:
  daily_limit: 50        # credits
  monthly_limit: 800     # credits
  per_action_max: 10     # no single action can exceed this
  alert_threshold: 0.8   # alert at 80% of daily limit
  overage: block         # block | alert | soft-cap

# When the daily limit hits, all agents pause.
# No "just one more" exceptions.

This is not a suggestion to the model. It is a hard constraint. When the daily limit is reached, agent execution pauses. The founder gets a notification. They can raise the limit, redistribute budget across roles, or leave it paused until the next cycle resets.

Mechanism 3: Kill switches

Sometimes you need to stop everything. A kill switch is a single action that immediately halts all agent execution for a company. No graceful shutdown, no "finish the current task." Immediate stop.

Kill switches operate at three levels: company-wide (stops everything), role-level (stops a single agent role like marketing), and playbook-level (stops a specific workflow). Each level is independent. You can kill the marketing agent while the research agent keeps running.

Mechanism 4: Execution policy

Every playbook declares an execution policy that defines what the agent is allowed to do, what requires review, and what is explicitly blocked. This is not inferred from the prompt. It is a structured declaration in the playbook.

# outbound-email
execution_policy:
  allowed:
    - draft_email
    - schedule_send
    - read_contact_list
  requires_review:
    - send_email
    - update_contact_list
    - create_segment
  blocked:
    - delete_contact
    - export_contact_list
    - modify_billing

# "allowed" = agent executes immediately
# "requires_review" = held in approval queue
# "blocked" = rejected, no exceptions

The execution policy is the most important governance mechanism because it defines the boundary of what is even possible. A blocked action is not just discouraged. The platform will not execute it regardless of what the model outputs. This is constraint enforcement, not prompt engineering.

What happens without governance

The difference between a governed agent system and an ungoverned one is not subtle. It is the difference between infrastructure and a toy.

Auditable by design

Every action an agent takes, whether executed, queued, or blocked, is logged to an append-only audit trail. The trail includes the agent role, the playbook that triggered the action, the input context, the model output, the governance decision (approved, rejected, auto-executed, blocked), the timestamp, and the result.

{
  "id": "act_9f3a2b1c",
  "timestamp": "2026-06-01T14:32:11Z",
  "company_id": "co_abc123",
  "agent_role": "marketer",
  "playbook": "outbound-email",
  "action": "send_email",
  "governance_decision": "approved",
  "approved_by": "founder",
  "approved_at": "2026-06-01T14:30:44Z",
  "input_context": { "segment": "trial-users", "count": 142 },
  "result": { "status": "sent", "delivered": 139, "bounced": 3 }
}

The trail is not just for incidents. It is how a founder reviews what their company did overnight, how a playbook change is validated against what the old version actually produced, and how any decision can be reconstructed end to end, long after the fact. Agents are not functions: a single playbook run can involve many model calls, tool invocations, and branching decisions. When something goes wrong, a stack trace is not enough. You need the full decision context, and the trail keeps it.

Your company's data is yours

Governance also means separation. Every company on Capx Casa runs in its own isolated environment: its own execution sandbox, its own data, its own agent memory, its own budgets. One company's agents can never read another company's context, reference its customers, or apply its strategy. This is enforced at the infrastructure level, in layered defenses, not by application code promising to filter correctly.

The same isolation applies to performance. Budgets and rate limits are enforced per company, so one company's busiest day cannot slow another company down. Isolation is invisible when it works. That is the point. Every company operates as if it has the platform to itself.

Why this matters now

The conversation in AI has moved past "can agents do useful work?" to "can agents do useful work safely, repeatedly, and accountably?" The answer is yes, but only if governance is built into the platform, not sprinkled on top. Trust is not a feeling. It is a system property, and it requires mechanisms to maintain.