By Jonathan Nwosu, Product Manager
Ask anyone outside the finance team how they buy something at work and you will get the same story. They needed a laptop, a subscription, a contractor. They asked their manager, who pointed them at a form, a Slack channel, or a spreadsheet. They filled something in, waited, chased, waited again, and eventually either got what they needed or put it on a personal card and expensed it. Procurement, for most employees, is the least loved surface in the company.
I have spent the last months in discovery calls with finance teams about exactly this, and the picture is remarkably consistent. At one multi-entity company, a global consumer marketplace, procurement runs entirely on spreadsheets and almost zero percent of incoming bills carry a PO number, so nothing can auto-match and AP fixes the accounting on every invoice by hand. Another has a genuinely sophisticated policy, eight spend categories, each with its own rules about who may buy what, and it lives in a PDF and an Excel sheet that the buying process cannot see. A third told us their requests happen over Slack or face to face, with no visibility at all until the invoice lands. These are well-run finance teams. The tooling is what failed them.
I run procurement at Light, and we are rebuilding it around a premise the category has resisted for twenty years: the request form was never the product. The product is a decision, should the company spend this money, and every company already has a document that answers it: the purchasing policy. The problem is that the policy lives in a PDF nobody reads, while the decisions get made in approval queues by people re-deriving it from memory. The procurement agent closes that gap. It reads the policy, and it acts on it.
A purchase request is intent, not paperwork
Strip procurement to its skeleton and there are only two objects. There is intent: someone wants the company to spend money on something. And there is execution: the mechanism that spends it, a purchase order sent to a vendor, or a card issued for the subscription.
Most procurement tools conflate the two, which is why they feel bureaucratic. If your "request" is already a draft purchase order, the requester is being asked to do procurement's job: pick the vendor of record, know the entity, guess the GL account. If your request is a message to a Slack channel, finance is being asked to do the requester's job: reconstruct what was actually wanted from a thread.
Keeping intent as its own object, the purchase request, buys you three things. All requested spend lives in one view regardless of how it will be executed, so a company finally sees committed-but-not-yet-invoiced money. Budgets can be checked at the only moment they are enforceable, before commitment. And routing stays open: the same request can still become a PO or a card, decided by policy rather than by which form the requester happened to find.
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, this is 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 will touch 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 are department heads working from a finance-issued coding sheet with the 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 also 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 wanted requests routed differently under and over a five-thousand 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 the same 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 can be 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 stops re-deriving policy from memory and starts doing the only thing humans should do in this flow: judging 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, then the purchase order, then the invoice, usually by the same people, looking 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 in most systems the first approval does not bind anything: 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 to us 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, and any material change sends the request back through approval with the change named in the log. When the vendor's invoice later arrives and matches the approved order within the tolerance your finance team set, it needs no second judgment; it was already judged. Only a genuine discrepancy, an invoice meaningfully over the order, 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 case still gets flagged.
Policy as something the system runs, not something it stores
The deeper shift is what a policy is. In every procurement tool I researched for this work, 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 also 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 stops being a reconstruction from emails and becomes a byproduct of the work, which is the same property my colleague Chris described for agentic accounting on the ledger side. Procurement is simply the same idea applied one step earlier, before the money leaves.
Procurement earned its reputation as the least loved surface in the company because it made employees do the system's work: find the form, guess the codes, chase the approver. The system can do its own work now. The form was never the product. The decision is, and the policy already wrote most of it.
We are building this with our customers now. If your procurement runs on a policy PDF and a prayer, talk to us.