Agent Spend Approval Before Provider Selection

Agent spend approval before provider selection moves the human decision to the policy boundary. A person approves what the agent may buy and under which limits; the agent then selects a reviewed API provider that fits those limits.

This avoids two weak extremes. Unbounded autonomy lets the agent create spend from an unclear instruction. Vendor-by-vendor approval makes the person perform the selection and turns every paid request into a manual queue. A spend envelope keeps the approval meaningful while leaving routine provider choice automatic.

Approve an envelope, not a vendor name

A useful approval describes the permitted transaction before discovery produces a winner. It does not say “use Provider A.” It says which capability is needed, what one request may cost, which inputs may leave the workflow, and which operating requirements apply.

The approved envelope should contain concrete fields:

• The capability or job the request must perform.
• The maximum price permitted for one request.
• The inputs available and whether every input must be accepted.
• The maximum latency and minimum reliability, when those are hard requirements.
• The required settlement mode, if the workflow restricts it.
• The ranking preference: price, latency, reliability, or balanced.
• The expiry, request count, or workflow scope that ends the approval.
• The conditions that require a person to review the request again.

This envelope is narrower than a general company budget. It is also different from budget-bound API selection, which explains how `max_price` filters candidates. Approval establishes who accepted the complete set of limits and how long that authority remains valid.

Separate permission from selection

Permission answers whether the workflow may spend inside the envelope. Selection answers which eligible provider should receive the call. Combining them makes the decision difficult to operate and audit.

After approval, `GET /v1/discover?q=…` can receive shared requirements such as `max_price`, `max_latency_ms`, `min_reliability`, `settlement`, `require_all_inputs`, and `optimize_for`. Reviewed results have stable `candidate_id` values. The agent can pass those identifiers to comparison and decision without asking the person to rank a fresh list.

`GET /v1/compare?candidates={id},{id}` shows price, measured latency, measured success rate, and input compatibility side by side. Its 0–100 scores are relative to that one candidate set. The response includes the weights and each candidate's contribution, so approval does not depend on an unexplained “best” label.

The final rule remains deterministic. `GET /v1/decide?candidates={id},{id}` returns one provider, the rule that selected it, each rejected candidate with the exact constraint that removed it, and the eligible runners-up in order. This is the operating boundary described in deterministic provider selection: a model may interpret a task, but declared rules commit the spend.

Define when approval must stop

An envelope is only a control if the workflow refuses to stretch it. The agent must stop when the current request falls outside the approved scope.

A new approval is required when the capability changes, the proposed price exceeds `max_price`, a required input cannot be supported, or the workflow needs a different settlement mode. The same applies when the approval has expired or its allowed request count has been consumed. The agent should present the failed constraint rather than silently edit it.

No eligible reviewed provider is a valid result. It gives the operator a clean choice: raise a limit, change the requested job, provide different inputs, or stop. Automatic relaxation would turn a hard constraint into a preference after the person had already approved it.

External discovery also stays outside the envelope. Apiosk can return external x402 hits in a separate `external_candidates` block, but those entries have no `candidate_id`. They are unreviewed, unmeasured, and cannot chain into comparison, decision, or settlement. Finding one does not authorize the agent to treat it as an eligible substitute.

Keep approval evidence separate from execution

The approval record and the provider decision answer different questions. Keep both.

The approval record should retain the policy fields, approver or authorizing system, scope, and validity window. The decision record should retain the candidate set, applied constraints, winner, rejected candidates, and ordered runners-up. A downstream request can reference both records so an operator can trace a charge to the authority and the selection evidence that preceded it.

`POST /v1/decisions` records which provider was chosen and which alternatives were rejected. Your workflow can connect that record to its own approval, request, payment, and outcome identifiers. An audit trail for agent API selection then shows whether the purchase was inside policy without rewriting the evidence from current catalogue data.

Do not store only a sentence generated after the call. “The provider looked suitable” does not reveal the price ceiling, failed constraints, comparison weights, or validity of the approval. Structured records let an operator test the decision instead of accepting a narrative.

Escalate exceptions without discarding the rule

Some purchases need a human decision after selection. A provider may expose a term that is not represented in the measured fields, or a task may involve data that the standing envelope does not cover. Apiosk does not measure result quality or provider terms, so those concerns cannot be smuggled into its comparison score.

The workflow should pause with the automated result intact. Show the winner, rejected candidates, runners-up, active constraints, and the specific unmeasured concern. If a person selects a different eligible provider, record that action as an override rather than editing the original decision. The process for overruling an automated provider choice preserves both the rule's output and the human exception.

This produces a practical human-in-the-loop design. People define boundaries and handle exceptions. The agent handles repeated choices that remain inside those boundaries. Providers compete on published terms and measured operation rather than on being manually preselected.

Where Apiosk fits

Apiosk supplies the reviewed candidate and decision layer inside an approved spend envelope. The agent sends the same requirements through discovery, comparison, and decision. Hard constraints remove ineligible providers first; `optimize_for` orders the survivors; the decision response names the rule and every exclusion.

Over MCP, the same flow is available through `apiosk_discover`, `apiosk_compare`, and `apiosk_decide`. The agent integration page shows the current connection path, while the gateway's live responses remain the source for payment terms.

For an API provider, agent spend approval before provider selection means a buyer does not need to approve your name in advance. Your endpoint enters the decision when its capability, inputs, payment terms, and measured operation satisfy the approved envelope. You can list an API for reviewed discovery; Apiosk makes the later selection inspectable without claiming to measure result quality or provider terms.