Purpose-aware agent spending

Under budget, and still wrong

A B2B company gives a growth agent $5,000 a month to find enterprise developer leads. One afternoon the agent decides to spend $185 on an Instagram campaign aimed at a broad consumer audience. Look at it through every control a typical setup has:

Nothing here is a limit violation. It isn’t fraud either. It is an agent that was given money for one reason and is spending it on another — the most common way a well-meaning agent wastes a budget, and the one that spending controls, as they are usually built, cannot see.

Why spending limits aren’t authority

Limits answer how much. They are necessary, precise and cheap to check. But a limit is a number, and a number has no idea what the money is for. The failures that matter with agents are rarely “too much”; they are “on the wrong thing”:

• a research agent, asked to size a market, buying a dataset about a different market because the vendor ranked first;
• a procurement agent renewing a tool nobody uses, because renewing was the path of least resistance;
• a coding agent buying a larger instance to make a failing test pass faster;
• a growth agent chasing cheap clicks from an audience the business doesn’t sell to.

You could try to encode each of those as rules — block this merchant, allow that category — and some of them should be. But a list of merchants is a guess about the future, written before the agent met the case. People don’t delegate budgets by listing every allowed purchase. They delegate a purpose, and trust the delegate to stay inside it. Spend authority for agents needs the same thing.

What a delegated purpose is

A purpose is a short, structured statement, written by the person who delegates the budget. It travels with the agent’s authority and is versioned with it:

{
  "objective": "Acquire qualified enterprise developer leads",
  "success_criteria": [
    "Leads are platform engineers at enterprise companies",
    "Cost per qualified lead under $120"
  ],
  "constraints": [
    "No consumer social campaigns",
    "Never buy contact lists"
  ],
  "context": "B2B developer-tools company, Q4 pipeline push"
}

• Objective — the outcome the spending exists to produce.
• Success criteria — how a person would judge that a spend served it.
• Constraints — what this money must never be spent on, even if it would help.
• Context — anything a reasonable delegate would need to know.

Writing it takes a few minutes, and the exercise is useful on its own: most teams discover they never wrote down what their agent’s budget was for.

How a purpose check works

Before a spend, the check looks at three things: the delegated purpose, the spend itself — merchant, category, amount and description — and the agent’s own account of how it got here, its task and its steps. It asks a small, fixed set of questions:

1. Does this purchase materially serve the objective and plausibly contribute to the success criteria?
2. Does it do something a constraint rules out?
3. Do the agent’s stated task and steps actually lead to this specific purchase?
4. Is there enough information about what is being bought to judge at all?

The answers are combined conservatively into one assessment: aligned, uncertain or misaligned. The combination can only move a result toward caution: an “aligned” judgment with a constraint conflict, a trace that doesn’t lead to the purchase, or too little information becomes “uncertain”. Nothing moves it the other way.

The rule that makes it safe: a model never blocks money

A purpose check is a judgment, and judgments can be wrong. So it is given exactly one power: to ask a person. The mapping is fixed:

So the purpose check cannot block a spend (only a deterministic rule a person wrote can), and it cannot approve one either — an aligned assessment adds nothing that the rules hadn’t already allowed. Its confidence is recorded for the audit trail but never compared against a threshold, because a confidence score is not a business rule.

One more property matters when the decision is enforced: if the check can’t run — the purpose is missing, or the assessment is unavailable — an enforced decision fails closed to review. An unready system never silently turns into an approving one.

The agent’s story is evidence, not proof

Agents explain themselves: a task, a list of steps, a description of the purchase. That account is useful — a coherent trace that ends in this purchase is a good sign; a trace about something else is a warning. But it is written by the party being checked, and it can be written by an attacker.

That is why the layers are ordered the way they are. Hard boundaries are deterministic rules that no text can talk its way past. The purpose check sits on top of them, catching what numbers can’t — and when it is fooled, the rules still hold.

Measure it before trusting it

A purpose check should earn its place with evidence from your own agents, not from a benchmark. In Shadow Mode, every spend is assessed and recorded while nothing is blocked. Reviewers label real decisions — did this spend serve the purpose? — and the labels are compared with the assessments.

What “good enough” means

Before an agent is switched to Enforce, the readiness criteria ask, among others, for:

• at least 20 human purpose labels on assessed decisions;
• human disagreement with the assessment at or below 10%;
• purpose evaluation coverage and availability of at least 99%.

These are explicit, deterministic criteria — not a confidence score. If the assessment and your reviewers disagree too often, you see it before any decision takes effect.

A worked example

The agent asks right before it pays, with its task attached:

import { Neltava } from "neltava";

const neltava = new Neltava(); // NELTAVA_AGENT_KEY

const d = await neltava.authorize({
  task: "Q4 pipeline: enterprise developer leads",
  action: {
    merchant: "Instagram Ads",
    amount: 185.00,
    currency: "USD",
    description: "Consumer social campaign, broad audience",
  },
});

if (d.proceed) {
  // pay d.amount — in Enforce, through your payment adapter with d.capability
}

{
  "decision_id": "dec_7f3c…",
  "decision": "REVIEW",
  "effective_decision": "ALLOW",
  "reason_code": "PURPOSE_MISALIGNED",
  "requested_amount_minor": 18500,
  "authorized_amount_minor": null,
  "currency": "USD",
  "mode": "SHADOW",
  "explanation": "Within every limit, but the spend is assessed as not serving the delegated purpose; a person decides."
}

decision is what Neltava decided; effective_decision is what applies now. In Shadow Mode the agent proceeds and the verdict is recorded. In Enforce, proceed is false and the spend waits for a person in the review queue — with the purpose, the spend and the agent’s trace side by side.

Examples on this page are illustrative. Every request shown is tested against the Neltava API before publication.

When you don’t need it