By Jonathan Nwosu, Product Manager
Ask anyone outside the finance team how they buy something at work and you get the same story. They needed a laptop, a subscription, a contractor. Their manager pointed them at a form, a Slack channel, or a spreadsheet. They filled something in, waited, chased, and eventually either got what they needed or put it on a personal card and expensed it. Procurement is the least loved surface in the company.
We have spent the last months in discovery calls with finance teams, and it is the same picture every time. At one global consumer marketplace, procurement runs on spreadsheets, incoming bills carry no PO number, and AP fixes the accounting on every invoice by hand. Another company has a sophisticated policy of 8 spend categories, each with its own rules about who may buy what, and it lives in a PDF and an Excel sheet the buying process cannot see. A third takes requests over Slack or face to face, with no visibility until the invoice lands. These are well-run finance teams that were failed by their tooling.
We build procurement at Light from a fact the category has spent 20 years resisting: the request form is an artefact of the past. Procurement's product was never the form. The product is a decision: should the company spend this money. Every company already owns the document that answers it, the purchasing policy. That policy has lived in a PDF nobody reads while the decisions were made in approval queues by people re-deriving it from memory. The procurement agent closes the gap. It reads the policy, and it acts on it. Once a system does that, the form is revealed for what it always was: a workaround for software that could not read.
A purchase request is intent, not paperwork
Strip procurement to its skeleton and there are only 2 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.
Procurement tools conflate the two, which is why they feel bureaucratic. If your "request" is already a draft purchase order, the requester is doing procurement's job: picking the vendor of record, knowing the entity, guessing the GL account. If your request is a message to a Slack channel, finance is doing the requester's job: reconstructing what was wanted from a thread.
Keeping intent as its own object buys you 3 things. All requested spend lives in one view regardless of how it gets executed, so a company finally sees committed-but-not-yet-invoiced money. Budgets get checked at the only moment they are enforceable: before commitment. And routing stays open: the same request executes as 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 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.
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
If your procurement runs on a PDF policy and a prayer, talk to us.