The procurement agent killed the intake form

The intake is a sentence, the policy asks the questions

A purchase at Light starts with a sentence to the assistant, in Slack, Teams, or the web app: "I want to get 10 Figma seats, monthly cost is $12 per seat." The agent works out the rest: it recognizes the vendor, infers whether this wants a purchase order or a vendor card, and then does the part that matters. It consults your purchasing policy to decide what else it needs to know.

If your policy says software vendors need a data-sensitivity check, the agent asks whether the tool touches customer data, and attaches the answer to the request. If your policy requires accounting details at intake, the way the marketplace above does because its requesters work from a finance-issued coding sheet with GL accounts and tax codes already on it, the agent asks for exactly those fields. If your policy says nothing about small purchases, it asks nothing at all. The questionnaire is not designed by an admin dragging fields onto a form; it is derived from the rules the company already wrote.

This is where the real requirements diverge from what procurement vendors assume. The company with the eight-bucket policy does not gate purchasing by job title; it gates by group membership: this team may buy this category up to this amount. Another customer routes requests differently under and over a 5,000 threshold, with a second approver joining above it. None of that is exotic. All of it is just policy, and a system that executes policy handles all of it with one mechanism instead of eight hard-coded workflows.

The failure mode we design against is the twenty-one-question intake. Every additional mandatory question is a tax on the person least equipped to pay it, and the result is the thing every procurement lead dreads: people routing around the system. The best procurement tool is the one people actually use when nobody is watching.

The agent decides what it can, routes what it cannot

Here is the substance of "making decisions on policy." Most of a purchasing policy is mechanically checkable. Is the amount under the department threshold? Is the vendor already approved? Is there budget left? Does this category require a security review? A human approver checking these things is not exercising judgment; they are being a slow rules engine.

So the agent executes that layer directly. A request that is in-policy, in-budget, and under threshold is cleared for its outcome the moment it is submitted, with every check it passed written to the audit log. A request that trips a rule is not rejected by a robot; it is routed to the person the policy names for exactly that situation, with the evaluation attached: what passed, what needs their judgment, and why. The approver does not re-derive policy from memory; they do the only thing humans should do in this flow: judge the cases the rules cannot.

That is also why one approval gate is enough. In the standard flow, spend is approved three times: the request, the purchase order, the invoice. The same people look at the same numbers, weeks apart. When we asked customers to walk us through their ideal flow, the ask was unanimous: one approval process, not two, with bills that belong to an approved order skipping the queue. The extra gates exist because the first approval binds nothing: approve a request for 5,000 and someone can edit the resulting order to 9,000 without anyone being asked again. One controller put it plainly: approval can be circumvented whenever a critical field is edited mid-flow. She was right, and the answer is not a third gate.

Our model locks the fields that mattered to the decision: amount, currency, vendor, entity. Any material change sends the request back through approval with the change named in the log. When the vendor's invoice arrives and matches the approved order within the tolerance your finance team set, it needs no second judgment; it was already judged. Only a discrepancy beyond that tolerance earns human attention. The same customers who asked for fewer approvals asked for exactly this caveat, and they were right to: skipping is safe precisely because the mismatch still gets flagged.

The same policy, one step later

Everything above happens before money is committed. The approval workflow most finance teams actually argue about happens after: an invoice arrives, and somebody has to say yes.

The 2 halves are the same problem, and separating them is what makes both worse. If the purchase was approved against a policy the invoice never sees, then invoice approval degenerates into a second, weaker check: does this look about right, and did somebody senior enough click it. That is not a control, it is a signature.

When the policy runs at both points, invoice approval becomes an exception process. The bill matches its purchase order by amount. The person who ordered confirms the goods arrived. Duplicates are caught before approval rather than after payment. Everything that reconciles simply posts, and what reaches a human is what genuinely needs a decision.

That changes what the approver is for. Stephen Grist, CFO at Puzzel, puts the requirement precisely: "I'm not interested in knowing everything it approved, but I am interested in knowing if it approved some big things or some things out of policy." An approvals feed that surfaces everything trains people to approve without reading, which is the same as having no control at all.

It also changes where approval happens. At All Gravy, approvals and reimbursements run through Slack, and the Head of Finance and Ops clears them on the metro, which is the honest test of whether an approval flow fits a working day rather than interrupting it.

The failure mode to watch for is upstream. Too Good To Go has almost no bills carrying a purchase order number, so nothing auto-matches and the approval step has nothing to check against. A workflow cannot validate a commitment that was never recorded, which is why the intake question and the approval question are the same question asked twice.

Policy as something the system runs, not something it stores

The deeper shift is what a policy is. In every procurement tool we researched for this piece, policy is configuration: an admin translates the PDF into workflow conditions, and from that day the two drift apart. In an agentic system, the policy document is the source. Finance writes rules in plain language; the agent applies them at intake, at approval, and at matching; and when the policy changes, the behaviour changes with it. No implementation project, no drift.

That changes the audit conversation. When a controller asks why a purchase was cleared, the answer is not a shrug at a workflow diagram; it is the agent's evaluation, attached to the request: the rule, the evidence, the outcome. The audit trail is not a reconstruction from emails; it is a byproduct of the work, the same property our colleague Chris described for agentic accounting on the ledger side. Procurement is the same idea applied one step earlier, before the money leaves.

Procurement earned its reputation because it made employees do the system's work: find the form, guess the codes, chase the approver. That era is over. The form was the workaround, and the constraint that demanded it is gone. A policy is not something a system stores. It is something a system runs. Next to a system that runs it, a tool that merely stores it is impossible to defend. The form belongs to the past; the decision is the product, and your policy already wrote most of it.

Jonathan Nwosu, Procurement Product Manager at Light

Read what to look for in procurement software and how three way matching holds on every invoice. If your procurement runs on a PDF policy and a prayer, talk to us.