Spend Control

elizon-demo/spend-control · version 1.0.0 · entry point agents.reviewer

What it does: reads one purchase request and answers APPROVE, HOLD or ESCALATE, with the rule it applied and one sentence of rationale. Four ordered rules:

1. R1: at or above 5,000 escalates on size alone.
2. R2: anything that would take quarter-to-date spend over budget holds (read from the operator's own ledger).
3. R3: anything without an actionable description holds.
4. R4: everything else approves.

Why a single Agent

There's one actor and one step. Wrapping it in a Team would add a lead's model call per request and nothing else. A Package doesn't have to be big, and this is the demo that shows it.

entryPoint: agents.reviewer

compatibility:
  requiredCapabilities: []

agents:
  - name: reviewer
    ref: ./agents/reviewer.yaml
tools:
  - name: ledger
    ref: ./tools/ledger.yaml

slots:
  - id: reasoning
    type: llm
    required: true
  - id: ledger-access
    type: credential
    scheme: api_key
    required: true
    boundTo: [tools.ledger]

triggers:
  - id: run-manually
    type: manual
  - id: review-request
    type: api

The Tool, with an API key as a header

toolType: mcp
name: Spend Ledger
identifier: spend-ledger
url: https://ledger.example.com/mcp
authType: none
credentialSlot: null
headers:
  - name: X-Ledger-Key
    valueType: credential
    slot: ledger-access
requestTimeoutMs: 15000
sseReadTimeoutMs: 30000

The URL is part of what the Package is. The key is the operator's, resolved from their Secrets vault at call time and never stored in the Package. For a real ledger, change the URL and rebuild.

Triggers

• manual: paste a request into Studio. This is how most operators will use it.
• api: the operator's purchasing system calls it and gets the answer back. manual and api work with a single-Agent entry point; a schedule or webhook would need a Workflow.

Compliance, as declared

Personal and financial data (a requester's name and an amount), EU, conversations kept 90 days, advisory, EU AI Act limited risk: the output is a recommendation about a named employee's request, and a person approves every request either way.

What "working" looks like

1. The evaluation passes: a large, well-described request escalates under R1 (so R1 beats R4), a request described as "stuff" holds under R3 and says what's missing, and a small ordinary request approves under R4.
2. Paste a request in Studio. The answer starts with the decision in capitals, names the rule, and reads as a recommendation.
3. Ask for something that would break the quarter's budget. It holds under R2, having actually read the ledger. If the ledger doesn't answer, it says so and escalates rather than guessing, which is how you know the credential is bound correctly.