Building a Governed Procurement Agent

A procurement agent should be good at exploring options and bad at inventing its own authority.

Evidence boundary: This article is part of Independent Product R&D and documents a Target Reference Architecture. It describes an intended control flow, not measured performance or live operation.

Illustrative Reference Project — not a deployed customer system. The architecture below is a teaching design for examining trust boundaries, policy decisions, and evidence.

All numbers and names in this example are illustrative.

The core separation is simple: the agent can translate a request, discover suppliers, compare terms, and propose a purchase. Deterministic controls decide whether those exact terms fit policy or require approval. An isolated purchasing workload performs the external action, and reconciliation closes the record with provider evidence.

Define the responsibility boundaries

A governed procurement flow needs distinct actors even when one user interface makes them feel continuous:

• Requester: states the business need, delivery context, and acceptable constraints.
• Approver: supplies exact approval when policy requires separation or step-up.
• Procurement agent: structures requirements, gathers options, and proposes terms.
• Policy decision point: evaluates supplier, category, amount, budget, validity, velocity, and authority mode.
• Authorization boundary: binds approval or delegation to the exact proposal and reserves applicable capacity.
• Isolated purchasing executor: submits only the authorized order.
• Credential broker: makes downstream access available to the executor without exposing it to the agent.
• Outcome reconciler and evidence ledger: determine what happened and link request to receipt.

Do not collapse requester and approver merely because the same person can hold both roles in a low-consequence policy. The model should represent the roles explicitly so higher-consequence categories can require separation without redesigning the workflow.

Illustrative procurement reference architecture

Conceptual target design. This diagram communicates intended trust boundaries and control flows; it is not a deployment topology or claim of production operation.

The diagram is a responsibility map. It intentionally omits internal services, storage choices, routes, and provider-specific objects. Those details do not establish the security properties. The meaningful questions are which component may propose, decide, approve, execute, see credentials, and declare an outcome.

Normalize the request before sourcing

Natural-language requests mix goals with assumptions. “Get ten ergonomic keyboards for the new team by next Friday” leaves open budget, layout, compatibility, supplier eligibility, delivery location, return terms, and whether equivalent products are acceptable.

The agent can help turn that statement into typed requirements, but unresolved material fields must remain explicit. It should not fill an unknown delivery site from conversational memory or infer that a lower-cost substitute is acceptable. A clarification state is a valid outcome.

Once requirements are stable enough for discovery, the agent can compare options using non-sensitive catalog access. Sourcing remains outside transaction authority. The agent forms a proposal only after selecting exact supplier, item, quantity, price ceiling, delivery terms, and any renewal or cancellation condition.

Evaluate policy against the proposal

Policy should return an explainable decision such as:

• allow under active bounded delegation;
• require exact approval from a named role;
• deny because a hard constraint is violated;
• request clarification because a decision-relevant fact is missing or conflicting.

The decision includes its policy version and reasons. A model-written explanation can make those reasons readable, but the model does not choose the result. Unknown categories, suppliers, constraints, or policy versions fail closed.

Step-up approval presents the exact proposal. If the cart changes after approval, the binding fails. The agent may suggest a new option, but it must create a new proposal and repeat the required decision.

Purchase sequence

The sequence has a deliberate pause before execution. “Policy allows” is not itself an external action. Authorization consumption, capacity reservation, execution creation, and evidence handoff form the local commit. The provider request happens afterward and has its own outcome semantics.

Worked example

The fictional Northwind Design group needs twelve monitors for a temporary studio. The requester specifies ergonomic stands, a delivery deadline, and a total ceiling of USD 4,800. The agent discovers two eligible options.

Option A comes from an approved supplier for USD 4,560 with standard returns. Option B is USD 4,320 from a supplier that has not completed onboarding. Deterministic policy denies B under the current supplier rule rather than treating the price advantage as authority to bypass onboarding.

Option A fits the category and per-action ceiling, but it would raise the illustrative monthly equipment total above USD 12,000. Policy therefore requires exact approval from a budget owner. The approval view shows supplier, item, quantity, delivery site, total ceiling, return condition, and expiration.

After approval, the supplier reports only eleven units in stock. The agent cannot silently order eleven under an approval bound to twelve, nor substitute another model. It creates a revised proposal. Policy might decide that the reduced quantity remains within a delegation, or it might require a new approval because partial delivery changes the business outcome.

Once the exact cart is authorized, the isolated executor obtains the appropriate supplier credential from the broker and submits the order. If acknowledgement arrives, reconciliation compares supplier, line items, amount, delivery destination, and request identity before marking the outcome confirmed. If acknowledgement is lost, the transaction becomes uncertain and the budget reservation remains visible.

Design the evidence chain with the workflow

Evidence is not a log export added later. Each stage should produce an artifact or decision record linked by stable identities:

The record should omit reusable provider credentials. Retention and visibility should follow the sensitivity of purchase details, not the convenience of one broad application log.

Handle cart drift explicitly

Procurement proposals change frequently: inventory moves, prices expire, shipping changes, taxes appear, and suppliers offer substitutes. Define which differences are material before they occur.

A lower total may still need a new decision if supplier, licensing, cancellation, quantity, delivery site, or data terms change. Conversely, a bounded delegation may permit limited price movement if every other constraint remains fixed. The authorization envelope and policy—not the agent’s prose—decide.

Record the proposal version used for policy and approval. At commit, compare it with the executable cart. A mismatch returns to evaluation; it does not trigger an automatic “accept latest terms” option.

Plan recovery before granting autonomy

For each supplier adapter, document how to answer:

• Did the provider receive this request identity?
• Can the order be retrieved without placing another one?
• Which acknowledgement or receipt fields prove a match?
• How are delayed, duplicate, or conflicting events handled?
• Can cancellation be observed independently?
• Who reviews an outcome that remains uncertain?

If the adapter cannot support credible outcome evidence, keep the action in prepare-and-approve mode or require a human to complete it outside the automated executor.

Failure modes

Implementation checklist

• Model requester, approver, agent, policy, executor, and credential responsibilities separately.
• Normalize decision-relevant requirements and represent missing facts explicitly.
• Keep supplier discovery outside purchase authority.
• Evaluate supplier, category, amount, cumulative budget, validity, and role rules deterministically.
• Bind step-up approval to the exact cart and reject material drift.
• Commit authority consumption, reservation, execution intent, and evidence handoff together.
• Give only the isolated executor brokered provider access.
• Reuse stable request identities across submission and reconciliation.
• Preserve receipt evidence without preserving reusable credentials.
• Test inventory changes, price drift, partial fulfilment, concurrent budgets, and ambiguous acknowledgement.

The prior article, Where Secure Agent Transactions Fit: A Use-Case Map, explains why procurement is the primary example. Continue with Designing Spend Policies for Autonomous Buyers for the deterministic decision model. The project overview and full case study connect this example to the generic architecture. To discuss private implementation access, request repository access.