Agenomics Agent Spend Console

Agenomics uses WebMCP to let AI agents inspect bounded spending authority, evaluate untrusted requests, and stage proposals, while approval remains visible and exclusively human.

Comment

Inspiration

AI agents are becoming increasingly capable of acting inside websites, but access to a tool can easily blur several very different ideas: understanding a request, recommending an action, preparing an action, authorizing it, and executing it.

We built Agenomics Agent Spend Console around a simple question:

How can an AI agent participate meaningfully in an economic workflow without silently acquiring the authority to spend?

Our answer is an explicit authorization handoff. The agent may inspect, reason, and prepare. A human remains solely responsible for the consequential decision.

What it does

Agenomics Agent Spend Console is a self-contained browser demonstration of bounded authority for AI agents using native WebMCP.

Through four structured WebMCP tools, a browser agent can:

  1. Inspect its declared spending authority and policy constraints.
  2. Evaluate an untrusted spending request rule by rule.
  3. Stage an idempotent, expiring proposal for human review.
  4. Verify the local decision receipt after the human approves or rejects it.

The agent cannot approve a proposal, override policy, sign a transaction, execute a purchase, or move funds.

Only a human using the visible interface can make the final decision.

The interaction follows one clear sequence:

Agent inspects authority
        ↓
Agent evaluates an untrusted request
        ↓
Agent stages an expiring proposal
        ↓
Human approves or rejects it in the visible UI
        ↓
Agent verifies the resulting decision receipt

This makes the project an authorization-handoff demonstration, not a payment application.

The demonstration scenario

The seeded scenario features Atlas Research Agent, which has:

  • A daily budget of $30
  • $8 already reserved
  • Permission to purchase inference services
  • A $10 human-review threshold
  • A request for $18 from Helios Compute
  • A proposal lifetime of 30 minutes

The proposed expense would bring total exposure to $26, which remains within the daily budget. However, the amount exceeds the human-review threshold and Helios Compute is a new counterparty.

The correct result is therefore:

REVIEW_REQUIRED

The agent may explain the policy result and stage the proposal, but it cannot make the final decision.

Why WebMCP

WebMCP allows the agent and the human to work with the same live application state.

Instead of guessing from screenshots, clicking through an interface, or relying on a separate backend integration, the agent receives a narrow set of structured tools that correspond directly to the workflow presented in the page.

The application exposes exactly four tools:

  • inspect_agent_authority
    Reads the agent's budget, reservations, categories, counterparties, approval threshold, policy version, and evidence classifications.

  • evaluate_spend_request
    Evaluates an untrusted request against deterministic policy without saving or changing application state.

  • stage_spend_proposal
    Creates an idempotent, expiring proposal for human review. It cannot approve or execute the proposal.

  • verify_decision_receipt
    Validates the local bindings between the request, policy, proposal, human decision, and audit sequence.

Three tools are read-only. The only state-changing tool can create a proposal, but it cannot cross the human approval boundary.

The agent can inspect, reason, and propose. It cannot approve or spend.

How we built it

We designed the application as a browser-only, deterministic demonstration with no required login, backend, wallet, private key, blockchain connection, or external payment rail.

The implementation separates the system into several focused components:

  • A seeded authority and policy model
  • A deterministic rule-evaluation engine
  • Typed WebMCP tool contracts
  • An idempotent proposal lifecycle
  • Proposal expiry and reservation tracking
  • A visible human approval interface
  • An append-only local audit sequence
  • Hash-bound decision receipts
  • Resettable local demo state

The WebMCP tools are deliberately thin adapters over the same domain logic used by the interface. Policy enforcement does not depend on the agent following natural-language instructions.

We also distinguish between different classes of evidence:

  • Authoritative policy, which may affect the decision
  • Untrusted request data, which is evaluated but cannot redefine policy
  • Display-only information, which may be shown but is forbidden from influencing authorization
  • Declared identities, which are presented honestly as declarations rather than cryptographic attestations

This prevents a request from smuggling authority into the workflow through persuasive language or misleading metadata.

Challenges we faced

The hardest challenge was not calculating whether a request fit within a budget. It was preserving the boundary between recommendation, proposal, approval, and execution.

We had to ensure that:

  • No agent-facing tool could approve or execute a proposal
  • Duplicate staging calls could not create duplicate reservations
  • Expired proposals could not be treated as active authority
  • Untrusted request fields could not modify policy
  • Read-only tools did not mutate persisted state
  • Receipts described exactly what they proved
  • The interface never implied that approving a proposal moved money

Receipt semantics required particular care. The application validates consistency within local demo state, but it does not claim cryptographic identity, an independent timestamp, or proof of an external transaction.

Every receipt therefore reports its limitations explicitly:

External execution:       NOT_EXECUTED
Funds moved:              false
Browser-agent identity:   UNAVAILABLE
Human identity:           NOT_ATTESTED
Integrity scope:          LOCAL_DEMO_STATE

What we learned

WebMCP is most valuable when it does more than expose convenient page functions. Its deeper value is allowing a human and an agent to collaborate through the same visible state while retaining different capabilities.

We learned that strong agent safety boundaries should be represented structurally, not merely described in a prompt. The agent does not refrain from approving a proposal because we asked politely. It cannot approve because no such capability exists in its tool surface.

We also learned that a trustworthy receipt must explain both its evidence and its limits. A hash can demonstrate local consistency without proving identity, intent, time, or external execution.

What's next

The challenge build focuses narrowly on the authorization handoff.

Future versions could connect the same model to authenticated users, cryptographically identified agents, organizational procurement policies, cloud-service budgets, payment APIs, x402, or on-chain settlement systems.

Those execution rails are optional. The core Agenomics principle remains the same:

A request is not policy. A proposal is not approval. Approval is not execution.

Built With

  • axe-core
  • gitlab
  • localstorage
  • node.js
  • playwright
  • pnpm
  • react
  • testing-library
  • typescript
  • vercel
  • vite
  • vitest
  • web-crypto-api
  • webmcp
  • zod
Share this project:

Updates

Submission history