Project-bound purchasing for AI studios
Your agents can run. Your budget stays yours.
Give an agent a client project, not a blank cheque. Bind each purchase to approved terms and bounded authority. Then see what was paid, provisioned and checked.
Credential-free demo. No wallet connection or money movement.
Awaiting preview / approval · no passage authorized
A project. Not a blank cheque.
Every request belongs to the work. Every balance has a meaning.
Automated Booking Website
One project. One Client Work Capsule. A visible spending boundary.
- Allocated
- 3.00NEAR
- Settled
- 0.50NEAR
- Reserved
- 0.20NEAR
- Committed future
- 0.00NEAR
- Available now
- 2.30NEAR
- Available to commit
- 2.30NEAR
Purchases & requests
| Resource / purpose | Due now | Full commitment | Decision | Payment | Inspect |
|---|---|---|---|---|---|
| Database instanceStore booking requests | 0.50 | 0.50One-time | Approved | Settled | |
| Website hostingServe the booking website | 0.20 | 0.20One-time | Approved | Settlement pending | |
| 12-month hosting planAlternative hosting proposal | 0.20 | 2.4012-month minimum | Denied | Not attempted |
Database instance
Store booking requests
- Due now
- 0.50 NEAR
- Full commitment
- 0.50 NEAR
- Decision
- Approved
- Payment
- Settled
Website hosting
Serve the booking website
- Due now
- 0.20 NEAR
- Full commitment
- 0.20 NEAR
- Decision
- Approved
- Payment
- Settlement pending
12-month hosting plan
Alternative hosting proposal
- Due now
- 0.20 NEAR
- Full commitment
- 2.40 NEAR
- Decision
- Denied
- Payment
- Not attempted
A spending limit is only the start.
The question isn’t just “Can the agent afford it?” It’s “Does this purchase still belong to the job?”
The agent has an instruction and a spending cap.
The owner defines project-bound authority.
booking-demo-01 · revision 1Explanation, not a chain run. An external message never changes trusted project authority.
- 1
Give the agent a job.
A fictional studio authorizes infrastructure for a client booking website. One project, one assigned agent, one immutable capsule policy.
- 2
Pin the commercial terms.
A registered provider publishes a one-use quote. Recipient, service, amount and fixed-term obligations belong to that quote—not to the agent’s explanation.
- 3
Then the work changes.
The owner withdraws the project’s authority. The agent’s earlier instruction still exists, but it is no longer current authorization.
- 4
An old request reaches the Gate.
Being under a cap is not enough. The Gate checks current project state, canonical terms, agent identity, uniqueness and full commitment before any reservation.
- 5
No new payment. A clear reason.
A hard denial cannot be overridden by owner approval. Existing scheduled transfers are a different matter: withdrawal cannot recall them or discard their pending records.
Illustrative workflow, not a claim that every unbounded agent overspends. The Rust contract enforces only authenticated state and supported terms.
Give the boundary a test.
Change the quote. Push the budget. See which rule keeps the latch closed.
Client Work Capsule
BROWSER_FIXTUREFictional booking website · one agent · infrastructure scope
Frozen fixture clock: 7 Nov 2026 12:00 UTC. Active quotes expire 8 Nov 2026 12:00 UTC. Historical test data, not a live quote.
Three representative cases
Open the full Gate Lab: 14 scenariosA fresh database quote within this capsule's scope.
Expected rule APPROVED · changing any input re-evaluates the local preview.
Already settled: 0.50 NEAR. Reserved: 0.20 NEAR. These are fixed demo inputs, not funds in a wallet.
All-inclusive one-time fixture price. Quantity: 1. Provider identity, recipient and terms come from the canonical demo quote.
TypeScript preview · BROWSER_FIXTUREEvaluating quote…
Computing the local canonical hash. No payment is submitted.
Browser fixtureSeeded values and TypeScript preview · no contract call, signer, transfer or paymentBROWSER_FIXTURE
TypeScript explains. Rust enforces.
No signature, transfer, reservation or owner approval is performed here.
A small first charge. A long commitment.
A Client Work Capsule checks what is due now—and what you are agreeing to later. Fixed term only: no auto-renew or supplier cancellation.
Client Work Capsule
HypotheticalBooking website · infrastructure only
- Settled
- 0.50 NEAR
- Reserved
- 0.20 NEAR
- Available now
- 2.30 NEAR
- Available to commit
- 2.30 NEAR
available_now = allocated − spent − reservedavailable_to_commit = available_now − committed_future- Allowed providers
- Database & hosting fixtures
- Scope
- Infrastructure · one assigned agent
- Fixture clock
- 7 Nov 2026 12:00 UTC · quotes expire 8 Nov 2026 12:00 UTC (historical, not live)
- Authority
- Immutable policy · current project revision
Same first charge. Different obligation.
- Due now
- 0.20NEAR
- Full commitment
- 0.20NEAR
The 0.20 NEAR price is all-inclusive for this one-time fixture quote.
Shared with the Gate preview, not the seeded project ledger. Canonical fixture quotes, native NEAR; monthly fixed term, no auto-renew, cancellation terms represented by a fixture hash. Unknown usage, uncapped fees and indefinite renewals are unsupported and denied. No renewal collection or supplier cancellation.
Paid is a fact. Delivered needs evidence.
Follow one purchase from human authority to an explicit record of acceptance. Approval, settlement, provisioning, objective checks and human acceptance stay separate.
A successful transfer does not prove a database exists. A fixture check does not prove a client is satisfied.
A purchase is not one success state.
Select any lifecycle node to see what it records and what it cannot prove. A scheduled transfer or RPC inclusion is not confirmed settlement.
Financial authority & payment
Delivery & acceptance
Scheduling a transfer or seeing RPC inclusion does not prove the native payment succeeded. The reservation remains pending.
Stage explanation, not progress. Selected record is shared with the Outcome Receipt below; no live event stream.Database instance
purchase-db-demo-01- Due now
- 0.50 NEAR
- Full commitment
- 0.50 NEAR
- Project revision
- 1 · demo
- 1AuthorizationApproved
Within the seeded capsule's rules
- 2PaymentSettled
Seeded settled state, not a chain observation
- 3ProvisioningFixture observed
Controlled resource-manifest fixture, not a real database
- 4Objective checkFixture passed
Seeded website-resource-fixture-v1 check; no endpoint contacted
- 5Human acceptanceNot recorded
A separate authenticated decision, never implied by a check.
Inspect the evidence layer
Mandate · seeded source, not live evidence
- Project
- Fictional booking website
- Capsule / revision
- Demo capsule · project revision 1
- Authority source
- Seeded browser data; Rust requires owner-authenticated state
- Policy
- Immutable per capsule; agent cannot amend it
Seeded observation: 7 Nov 2026, 12:02 UTC
Inspect source & exact amounts
- Quote ID
database-demo-01- Amount due now, yoctoNEAR
500000000000000000000000- Source
- Browser demo data · fictional project
- Transaction / evidence digest
- Unavailable; no fabricated reference
- Seeded observation time
- 7 Nov 2026, 12:02 UTC
- Policy reference
- Demo capsule · immutable authority in Rust
A clear account of the work.
Run Intelligence starts with project costs and inspectable outcomes, not an opaque score.
Choose what to disclose.
The implemented report reducer is read-only and selected by the owner. This preview uses public, fictional fixtures to show that idea.
No account identities, private prompts or artifacts in this demo export.
Automated Booking Website
7 November 2026 · one fictional project · native NEAR
Nothing selected to share.
Financials and expenses stay out by default. Select the details you want this demo report to include.
Browser fixtureSeeded values and TypeScript preview · no contract call, signer, transfer or paymentBROWSER_FIXTURE
No share link or client account system. This demo does not authenticate a human owner.
Built to be checked.
Concrete enforcement. Explicit limits. Local evidence you can reproduce.
Recorded checkpoint · 11 November 2026 · Node and browser counts re-run today; the Rust/SDK count is the last recorded Linux run. Not a live test counter.
The Rust contract checks
- Current project authority
Owner-authenticated status, revision, expiry and exact capsule binding.
C / P cases - Canonical quote
Registered provider, pinned recipient, hash, asset, terms and one-use quote.
Q / G cases - Full commitment
Checked integers; immediate reservations and future authority remain separate.
P-06–13 - Replay & resource duplication
Unique requests and atomic canonical project-resource claims.
G-09–11 / P-10–11 - Actual settlement outcome
Private callbacks inspect the native transfer and resolve at most once.
S cases
The boundary is the architecture.
The model proposes. The contract authorizes. Evidence says only what it can prove.
- Proposal
AI / scripted agent
References the task and quote. Cannot raise its budget or approve itself.
- Authority
Rust Gate on NEAR
Loads canonical terms, checks current policy and reserves before a supported transfer.
- Observation
Outcome evidence
Private settlement callback, off-chain fixture checks and explicit owner records.
What can I try right now?
Choose a way in. No wallet, private key or payment is needed for these previews.
Inspect recorded testnet setupChallenge the Gate
Alter a recipient, reveal a hidden term or push the budget. Inspect the exact rule that stops the request.
Browser simulationInspect a project
Explore the fictional workspace, or choose a LOCAL Sandbox file to inspect its purchase and outcome records.
Fixtures or selected LOCAL recordsExplore project costs
Load the labelled sample or your LOCAL records. See settled costs, pending amounts and the evidence behind each outcome.
Read-only sample or LOCAL report
A simulation is not a chain call. LOCAL records are not public testnet evidence. The recorded public purchase remains unresolved.
Clear boundaries. Including our own.
Useful questions before you delegate.
LOCAL prototypeCan the agent increase its own budget?
No. The human defines authority. Policy is immutable per capsule; changes require a new owner-reviewed capsule. AI explanations cannot activate policy or override a hard denial.
Does paying prove the purchase was useful?
No. Approval, native settlement, provisioning evidence, objective checks and human acceptance are separate facts. A fixture check or a hash cannot make external delivery true.
What happens when a project is withdrawn?
Owner-authenticated state prevents future authorization. It cannot recall an already-scheduled transfer. Pending records and future commitments are not discarded on withdrawal, expiry or a timeout.
What if a payment outcome is unknown?
The reservation remains fail-closed. A private callback must inspect the actual transfer outcome. No timer, browser error or owner-supplied outcome can trigger an automatic release or resend.
Is this a deployed NEAR or mainnet demo?
This interface is credential-free and seeded. On NEAR testnet a human completed four separately reviewed setup transactions: a 0.30 NEAR project, one task capsule, one one-use 0.05 NEAR quote and a submit-only agent key. One restricted purchase was then signed exactly once and has no on-chain record at three independent sources; it is unresolved and is never resent, re-signed or released. The end-to-end purchase-to-acceptance walkthrough here is LOCAL Sandbox. No mainnet execution or fiat peg is claimed.
Are private client files stored on-chain?
Full prompts, artifacts and sensitive client material stay off-chain. Bounded references or hashes detect changes, not truth or confidentiality. The report shares only fields the owner selects.