A prompt is not a mandate

The first version of this idea was too simple.

My intuition was that APIs approve one request at a time while an agent acts across a sequence. Each call could look valid even when the complete sequence moved beyond what a person intended.

Finance has dealt with sequence-level risk for years.

Aggregate limits, repeated execution, partial fills, cancellations, kill switches, and reconciliation are established problems. The more interesting question sits above those controls:

How do we preserve a machine-verifiable relationship between a human mandate, an adaptive plan, deterministic risk decisions, asynchronous execution, and a reconciled outcome?

A prompt is ambiguous. An access token can be broader than the task. The model may revise its plan while market and order state change underneath it. One instruction can become several partially filled orders, leaving the system to decide whether the next attempt is safe, stale, or a duplicate.

The primitive I would build is a mandate-to-outcome control loop.

This is an independent design proposal for an internal, low-frequency rebalancing agent: one trust domain, restricted instruments, orders with enforceable price bounds, and an existing order management system. It does not describe an employer’s system or a deployed product.

Finance already reasons across sequences

The FCA’s COBS 9.3.2G gives a direct example: a series of transactions can be unsuitable because of its frequency even when each transaction is suitable alone.

European algorithmic trading rules are explicitly stateful too. RTS 6 covers price, order value, volume, message rates, repeated execution, and strategy positions. Submitted orders must enter applicable pre-trade limits immediately. The regulation also requires order attribution, kill functionality, and reconciliation against counterparties’ records. The FCA’s 2025 controls review found pre-trade controls at every reviewed firm, often at an internal gateway.

These are examples of existing control practice, not one universal legal baseline. Applicable duties depend on the service, instrument, client, and jurisdiction.

An OMS generally preserves an order’s lineage. I want to extend that lineage back to the mandate and evaluated plan, then forward to the outcome that consumed their authority.

What the agent changes

Conventional algorithms can already be adaptive or stochastic. An agent is not the first program that can make many requests or cause correlated failures. The additional pressure comes at the planning boundary.

A probabilistic system can interpret an open-ended goal, choose tools, create intermediate objectives, and change its route after an error. The same instruction can produce different action sequences. The plan is less stable than the authority under which it operates.

“Reduce risk without realising more than £3,000 in losses before the market closes” contains a goal, constraint, and deadline. It leaves accounts, instruments, cost basis, open orders, price tolerances, and approval thresholds undefined. It is planning context, not an authorisation policy.

The system must distinguish the asset owner, accountable regulated entity, delegating person or policy, and acting workload. The runtime has an authenticated identity. Model, prompt, and configuration versions are provenance; they are not the accountable party.

Useful building blocks already exist. OAuth Rich Authorization Requests lets an application represent fine-grained rights as structured data, but deliberately leaves comparison of domain-specific permissions to the application. Token Exchange can distinguish the subject from the actor representing it. Neither defines portfolio authority.

FAPI 2.0 supplies a high-security OAuth profile with sender-constrained tokens. Sender-constraining alone does not bind the economic payload: DPoP does not sign the HTTP body. The investment gateway still needs to verify the exact authorised action.

Open Banking’s Variable Recurring Payments model is a useful product analogy: durable consent constrains payees, amounts, frequency, time windows, and expiry. Investment mandates need different semantics, but the separation is useful. A durable resource owns authority; a credential lets a caller exercise a bounded part of it.

A control loop, not a bigger token

The design has eight stages. The agent can propose intent and a candidate plan. Deterministic services bind authority, evaluate risk, reserve capacity, and maintain the authoritative state.

1. A versioned mandate

The mandate is a durable, revocable resource. It identifies accountable parties, accounts, permitted intents and instruments, cumulative limits, approval thresholds, validity windows, and policy versions.

“No order above £2,000” and “no more than £10,000 of new exposure today” are different constraints. Both need explicit semantics. Sensitive suitability information can remain in the durable record; downstream services receive only what they need to enforce.

2. Typed portfolio intent

The model proposes rebalance, invest_cash, reduce_risk, or another supported objective rather than calling the broker directly. The intent records the target change, deadline, tolerances, portfolio and market-data versions, and agent provenance.

Typing the intent forces the product to define what it supports. It creates a stable surface for simulation, approval, explanation, and failure messages. A natural-language rationale helps a reviewer understand the proposal. It grants no authority.

3. A canonical order plan

A deterministic planner, or deterministic validation of an agent-produced plan, turns intent into explicit actions. Money, quantity, price bounds, and permitted tolerances need fixed representations so every service hashes the same economic object.

Where approval is required, a trusted surface displays the material facts and binds approval to that plan hash. A material change creates a new plan version. Ordinary partial fills within approved tolerances need not trigger another approval; changing the economic plan does.

A hash proves nothing useful if the agent can change both the payload and the expected hash. A trusted control-plane component must anchor the approved value.

4. Deterministic policy and risk evaluation

The policy engine checks mandate scope, applicable account restrictions and suitability controls, cash, holdings, open orders, turnover, concentration, restricted lists, data freshness, and approval requirements.

It returns a structured result: APPROVAL_REQUIRED, STALE_PORTFOLIO, or NO_CAPACITY, tied to the mandate version, plan hash, policy version, and reason. Those are different product states with different recovery actions.

This evaluation can power a preview. It is not a voucher against future state. Before issuing authority, the service revalidates the plan, bound approval, mandate, and state-dependent controls, then commits the final decision and reservation together. Otherwise the race merely moves between “evaluate” and “authorise”.

5. Atomic reservation

My first design put remaining headroom inside the signed permit. The two-worker example killed that idea.

A mandate has £10,000 left. Two workers independently request £6,000. If both hold a token saying “£10,000 remains”, each can pass a local check and jointly commit £12,000.

An idempotency key recognises a retry of one action. These are two different actions. They need an atomic reservation against shared state: check capacity and reserve it in one conditional transition. A serialisable transaction is one implementation.

The shared limit must include human trades and other systems affecting the same account. Serialising only the agents creates a precise ledger of an incomplete portfolio. Every competing execution path must participate in the control, or have capacity partitioned from it; an unobserved path breaks the guarantee.

Real capacity spans cash, exposure, turnover, and other constraints. These are not all additive counters: concentration and leverage depend on the resulting portfolio. Reserve for permitted partial-fill outcomes, including one leg executing alone, not just the desired final allocation. “Worst case” requires defined instrument and order bounds, fee buffers, and treatment of market moves. A reservation cannot guarantee that subsequent market movement never breaches a portfolio limit.

Permit expiry does not release capacity attached to submitted or ambiguous orders. Nor does a cancellation request. Abandoning a plan releases only capacity for actions confirmed never to have been submitted; working orders retain their reservations until their state permits release.

6. A short-lived execution permit

The permit references the mandate version, exact action and canonical payload, plan hash, policy decision, reservation, bound approval, audience, authenticated workload, expiry, and one-time identifier.

I would issue one permit per state-changing command, not a reusable permit for a mutable plan. Reserve the bounded plan, issue its first action permit, then authorise later legs against updated state without reserving the same capacity twice.

For this internal pilot, I would use an opaque permit backed by the ledger. The gateway verifies the sender, audience, payload, expiry, and current status, then consumes it once. Each workload obtains authority centrally; agents cannot mint permits for each other. Portable signed tokens become useful when independent verification across trust boundaries justifies the complexity.

7. Existing execution rails

The control plane should not rebuild order management. FIX’s order-state scenarios already model fills, cancellations, replacements, and the awkward case where a fill crosses a pending cancellation.

Add mandate, intent, plan, decision, reservation, and permit identifiers above existing OMS identifiers. One stable action ID identifies one command; the logical order chain remains distinct from its new, cancel, and replacement commands.

At the trusted gateway, permit consumption, the durable action record, and an outbox event share one local transaction. The adapter sends from the outbox. This established transactional outbox pattern makes the internal action durable before crossing an uncertain network boundary. It does not make a venue execute exactly once.

Retries reuse the action identity. After an ambiguous acknowledgement, recovery follows the broker’s deduplication and status contract; blindly resending can duplicate an external effect. Execution reports need duplicate handling, ordering rules, gap detection, and authoritative status queries.

8. Reconciliation and closure

A successful API response is not a completed investment outcome.

Fills must update authoritative state as they arrive. Ignoring price changes and fees, a £6,000 notional reservation with a £2,000 fill becomes £2,000 consumed plus £4,000 still reserved. Confirmed cancellation releases the unfilled part, not the consumed part. Cash, exposure, and turnover each need their own accounting rules; later trade corrections produce explicit adjustments.

Reconciliation compares this accumulated state with orders, fills, fees, cash, positions, and settlement records. It verifies agreement and drives repair or an exception; it is not the first time a fill becomes visible.

Closure can therefore be staged: EXECUTION_RECONCILED, BOOKING_RECONCILED, then SETTLEMENT_RECONCILED. An intent closes only when its outcome is accounted for, or becomes an explicit exception. A correlated trace helps investigation. It is not, by itself, tamper-evident audit evidence.

Failure is part of the product

Authorisation limits what an agent may do. It cannot prove that an in-scope action is wise or that its input was trustworthy. Narrow tools, data provenance, anomaly detection, and meaningful approval boundaries still matter.

Revocation needs a precise boundary. It blocks new permits and rejects unused ones at action admission. That admission and revocation must share a serialised check. Already admitted but unsent work needs a dispatch policy; an order handed to a broker may still fill. Revocation cannot promise to reverse history.

Cancel and kill paths should remain available when planning fails, but cancellation is not automatically risk-reducing: cancelling a hedge can increase net exposure. Emergency actions still need identity, stable action IDs, and a separate governing policy.

Approval should happen at meaningful boundaries: expanded scope, a material plan change, a threshold breach, or an unresolved exception. The screen should show what changed, which constraint triggered, and the exact plan being authorised. Asking someone to approve every order is not a substitute for defining those boundaries.

The smallest useful version

Existing OAuth scopes plus OMS controls may be enough for a tightly bounded internal agent. I would add this loop where mandate lineage, changing plans, and shared limits create an actual gap.

Self-contained tokens simplify offline verification but cannot keep changing headroom current. A central ledger can enforce shared limits, at the cost of an availability boundary. Human approval for every action adds friction without resolving either problem.

The hybrid has a clear division of responsibility: the ledger owns authority and reservations; the permit admits one command; the OMS owns execution state; reconciliation checks external outcomes against the internal account of them.

The API can stay small:

POST /intents
POST /intents/{id}/plans
POST /plans/{id}/evaluate
POST /plans/{id}/authorise
POST /plans/{id}/actions/{index}/authorise
POST /actions
GET  /actions/{id}
GET  /intents/{id}/outcome

These are the core workflow endpoints, alongside mandate administration, approvals, and cancellation. Creating an intent does not trade. Evaluation previews. Authorisation revalidates and reserves. An action consumes one permit into a durable command and returns its identifier, not a promise that the market outcome is complete.

I would judge the pilot on effects outside the mandate that reached execution, duplicate external effects, oversubscribed or leaked reservations, reconciliation exceptions, and time to reconstruct lineage. Before live use, a replay suite should exercise concurrent workers, stale approvals, lost acknowledgements, duplicate reports, partial fills, and revocation races. Passing it would establish evidence for those scenarios, not general correctness.

The most useful test is concrete: given a surprising fill, can an authorised reviewer reconstruct the accountable party, mandate version, model provenance, approved economic plan, policy decision, reservation, exact command, external events, and resulting constraint state?

Where the argument stops

A signature cannot establish suitability. Idempotency cannot manufacture exactly-once execution across a venue. A reservation cannot make market risk disappear.

Cross-account reservations, policy changes during working orders, cross-domain delegation, and independently verifiable audit evidence need further design and testing. A read-only assistant does not need this whole architecture.

The proposal is narrower: let the agent form a useful plan, while deterministic infrastructure preserves what it may do and what actually happened.

After every action, the loop should answer five questions:

1. Who was accountable?
2. What authority existed at that moment?
3. Which exact plan was evaluated?
4. What did the external system actually do?
5. How did that outcome change the remaining authority?

A prompt cannot answer those questions. A generic access token cannot either.

That is the job I would give a mandate-to-outcome control plane.