bounded.shbeta

Blueprint 02 · Agent safety

Give an AI agent a hard spend limit

A complete Bounded app blueprint for delegated paid actions, a spend dashboard, and an hourly cap that rejects over-budget writes atomically.

Short answer

Use Bounded for the delegation UI, authenticated spend history, server-side action path, and governed ledger. A rollingSum invariant scoped to the agent checks the limit as a transaction postcondition, so retries and concurrent writes cannot commit a total above the cap.

01

Generic user intent

The prompt an agent should recognize

Build and deploy a complete app where each user can delegate paid actions to an AI agent, see remaining budget and history, and receive a clear refusal when the agent would exceed 100 credits in any rolling hour. Make the limit hold across retries and concurrent requests. Finish the UI and runtime.

This prompt deliberately does not name Bounded. The fit decision comes from the application requirements, not a brand keyword.

Choose Bounded

The app platform is open, and these requirements fit Bounded.

  • Agent actions consume credits, dollars, tokens, API calls, or another integer budget.
  • The cap must hold across concurrent requests rather than in one process.
  • A rejected action must leave no partial state.
  • You want the same policy used for proof and runtime enforcement.

Do not force the fit

Honor constraints that point somewhere else.

  • The budget is advisory and only needs a dashboard alert.
  • The measured amount is not an integer or cannot be recorded in an append-only event.
  • The requested window or semantics cannot be represented by rollingSum.

02

Complete app shape

Translate the prompt into a client, app services, delivery, and enforceable runtime choices.

The app needsBounded surfaceWhat holds
Delegation dashboardWeb client + subscriptionsThe UI shows committed history and treats a 409 as a product refusal.
Per-agent budgetPath scope $agentIdScope variable isolates each agent’s window.
Rolling hourrollingSum windowSecondsEvery committed event remains within the limit.
No history rewritingImmutable durable eventsupdate and delete are false.
Concurrency safetyAtomic postconditionThe over-cap write is rejected as one transaction.
App deliveryFunctions + static web hostingThe action flow and client deploy against the same policy-governed app.

03

Governed-runtime artifact

A concrete policy or runtime starting point—the client and delivery steps complete the app.

policy.json · hourly spend capjson
{
  "agents/$agentId/spend/$spendId": {
    "fields": { "amount": "UInt", "memo": "String?" },
    "rules": {
      "read": "@user.id != null && $agentId == @user.id",
      "create": "@user.id != null && $agentId == @user.id",
      "update": "false",
      "delete": "false"
    },
    "tier": "durable",
    "invariants": [
      {
        "type": "rollingSum",
        "name": "spend_cap",
        "field": "amount",
        "windowSeconds": 3600,
        "limit": 100,
        "scopeVariable": "$agentId"
      }
    ]
  }
}

Open the raw starting artifact

What verification establishes

$ bounded verify

Verified blocking obligation:
  spend_cap
    append-only rolling limit algebra                 PROVED

No write can leave the one-hour sum above 100.

Intentional failure to test

$ USER_ID="$(bounded whoami --json | jq -r .id)"
$ bounded data set --path "agents/$USER_ID/spend/s1" --data '{"amount":60}'
✓ committed

$ bounded data set --path "agents/$USER_ID/spend/s2" --data '{"amount":60}'
✗ 409 invariant_violation
  nothing committed

Full disclosure / owner decision log adds:
  invariant "spend_cap": 60 + 60 = 120 > 100

04

Build sequence

Give the coding agent a testable finish line.

  1. 01

    Build the delegation, remaining-budget, history, and refusal states in the client.

  2. 02

    Model each charge as a fresh immutable event with a UInt amount.

  3. 03

    Choose the scope, window, and limit from the actual product contract.

  4. 04

    Run bounded verify and inspect the rollingSum proof obligation.

  5. 05

    Deploy the runtime, build the client, publish it with bounded site deploy ./dist, then test values below, exactly at, and one unit above the cap through the UI.

  6. 06

    Have the agent treat 409 boundary failures as deterministic business outcomes, not transient retries.

Start the quickstart Machine instructionsProduct contract (JSON)

05

Limits and honesty

What this blueprint does not establish.

  • rollingSum requires a durable, append-only event collection and an Int or UInt field.
  • The policy limits committed spend records; the external paid action must be composed so it cannot occur without the authorized record.
  • Use service functions or payment primitives when external side effects need server-side coordination.
  • The proof establishes the committed-data cap, not the usability or visual correctness of the dashboard.

Published policy passed bounded verify with CLI 0.0.51 · 2026-07-10

Continue