Pactum's Intake Agent puts autonomous indirect procurement to work

Indirect procurement involves a lot of work between someone asking for something and the business buying it. There is the incomplete request, the policy check, the existing agreement nobody remembered, the quotes to collect and the negotiation someone needs time to do. Making the first form easier helps. Having that work carried out is a much bigger change.

That is the application behind Pactum's Intake Agent. It is an entry point to a wider system of autonomous digital workers that check, source and negotiate indirect purchases. The procurement team sets the strategy and operating limits. The digital workers execute the buying activities within the configured scope, with buyers involved where the work requires them.

Disclosure: I work for Pactum. This article draws on public product information checked on 25 October 2026. The practical assessment is my own. It is not an independent product test.

Pactum describes its Intake Agent accepting requests through Teams or a procure-to-pay system, extracting details from attached quotes and preparing a coded requisition. It identifies whether an existing catalogue or agreement applies, or whether the requirement needs another buying route.

The wider indirect procurement system then supplies the execution. Pactum describes digital workers checking policy, selecting the commercial route, collecting quotations, running sourcing activity and negotiating. This is software carrying out procurement tasks, including decisions within the authority the customer configures.

For example, its Single-Source Negotiation Agent can negotiate and agree terms within configured limits before the purchase order. Requests outside those limits go to a buyer. Pactum describes options ranging from advisory to autonomous operation, so the actual scope depends on the customer's deployment.

That distinction matters. If we describe the product as capturing a request and passing it to procurement, we leave out the reason a procurement leader would be interested in it.

Consider a hypothetical marketing team needing a translation agency for a product launch. They have a supplier's quote, a deadline and a budget. They want the translations delivered, not a new hobby in purchase requisitions.

The procurement work starts with understanding what they need. Which languages? What volume? Does the price include specialist review? Is the delivery schedule realistic? Those details affect whether an existing agreement is suitable and whether two offers are actually comparable.

In an autonomous buying workflow, the team should be able to define how that type of requirement is handled, then have digital workers carry out the applicable work. Where an agreement covers it, use the agreed route. Where a competition is warranted, run the sourcing activity. Where a permitted single supplier is appropriate, there may still be commercial terms worth negotiating.

This example illustrates the operating model, not a reported Pactum customer deployment. The scope, supplier eligibility and authority for each action need to be established in the implementation.

What interests me is the work that would otherwise remain undone. A team may know perfectly well that a purchase could benefit from negotiation and still have more urgent work to deal with. Giving that team another recommendation does not create the time to act on it. Executing the negotiation can.

The same principle applies to chasing missing information and collecting offers. The value is the completed activity and its effect on the purchase, not the number of messages generated along the way.

The operating model needs clear category decisions, usable agreements, an approved supplier base and commercial limits that make sense. Procurement owns those choices. A system cannot compensate for a team that has never decided what a good outcome looks like.

But that does not mean a buyer has to approve every individual step forever. The useful question is which activities can be completed autonomously in the agreed scope, which require a checkpoint and which exceptions genuinely need a person's judgement.

I would establish that division of work before presenting a capacity saving to the business. If buyers still repeat every check, rebuild every event and redo every negotiation, the intended operating model has not been achieved.

For an initial deployment, I would choose a defined set of indirect purchases and record what happens to every eligible request, including the awkward ones.

Measure how much work completes without buyer intervention, why the rest needs help, and whether the agreed terms reach the order. Check the requester's total journey as well. Saving buyer time while leaving colleagues wondering where their purchase has gone is an unfinished improvement.

Commercial results need a credible baseline. A lower price for less scope is not automatically a saving. Compare specification, quantity, delivery, service and payment terms, and include supplier participation and failed negotiations in the review.

The point of intake here is to get the business's need into a system that can act on it. The point of autonomous indirect procurement is to carry that buying work through. That is the proposition I would evaluate, and the outcome I would hold it to.

No. Intake starts the request. Pactum describes a wider group of digital workers for alignment, sourcing and negotiation. Assess the deployed combination against the buying work you need completed.

No. Procurement sets the commercial objectives and operating boundaries. Digital workers can carry out buying activities and make decisions within the configured authority. Buyers handle work outside that scope and exceptions that need their involvement. Autonomy should remove work, rather than make people repeat it.

A traceable journey from request to the agreed buying outcome, showing the actions completed, interventions, exceptions and resulting terms. A polished demo is a starting point. Your own representative requests provide the useful test.

Product descriptions are Pactum's claims. The worked example and evaluation recommendations are WOP analysis. Sources checked on 25 October 2026.