If your organization publishes agents to Google Agent Registry, Cascade reads them there. Nothing is hardcoded, and an agent approved tomorrow is usable the same day.

CASCADE_AGENT_REGISTRY=google
GOOGLE_CLOUD_PROJECT=your-project

An agent reaches Cascade over MCP, or over REST if it has no MCP client:

{
  "mcpServers": {
    "cascade": {
      "command": "cascade-mcp",
      "args": ["--repo", "/path/to/your/repo"]
    }
  }
}

Work is routed by capability, never by agent name. You state a goal; Cascade asks the registry who is entitled to each part of it.

Refund Agent  v2.1   owner: finance@yourorg.com

  can       payments.read
            payments.refund

  cannot    customer.delete
            communication.send

Cannot is not the same as leaving a capability out. Absent means nobody has said. Cannot means somebody said no, and no grant anywhere overrides it.

Thresholds and business rules sit alongside it in plain YAML, evaluated with no model in the decision path:

- id: refund-threshold
  when:    { action: issue_refund, amount: { gt: 20000 } }
  then:    require_approval
  because: "Refunds over 20,000 need a named approver"

Your live boundary is on Fleet › Capabilities, and your rules on Control › Policies.

A system reaches Cascade through an adapter, which declares for each tool whether its effect can be taken back. That declaration is what decides whether work runs unattended, waits for a person, or can be undone at all.

Operations     connected     candidate and payment records
Suppliers      connected     verification, contracts, inventory
Communications connected     messages, irreversible once sent

Your ERP       adapter       write one, and the same boundary applies

Three adapters ship with Cascade, over synthetic systems so nothing here touches real records. The runtime knows nothing about candidates, suppliers or refunds: it knows actions, reversibility and capability, which is why the same boundary works over a payments provider and a git repository.

State a goal in the operator's words on Operations › Goals, or post one:

curl -X POST /api/goal \
  -H "Authorization: Bearer $CASCADE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"goal": "Onboard Acme as an approved supplier"}'

Each agent works in its own copy of your world. Cascade reads what actually changed there, not what the agent said it would do, and answers per action:

COMMIT   safe and recoverable, so it becomes real now
GATE     cannot be taken back, so a named person decides
BLOCK    breaks a capability, a policy, or a proven rule

Running agents needs Vertex AI credentials on the server. Without them a goal is accepted and the run fails.

247 actions judged
  231  committed          nobody was interrupted
   11  refused            with the rule and the evidence
    5  awaiting approval  nothing has happened yet

each carries  the agent and its version, who asked,
              the capability, what actually changed,
              the rule evaluated, and the decision

The ledger is written before execution, so a crash leaves a decision with no effect, never an effect with no decision. To reverse a goal, use Roll back, or:

curl -X POST /api/goal/GOAL_ID/rollback \
  -H "Authorization: Bearer $CASCADE_TOKEN"

Rollback replays each action's inverse in reverse order. Anything that could not be undone is reported as such, never quietly counted as reversed.