What a procurement workshop taught me about where AI should stop

From 20 to 22 October 2026, Pupuk Indonesia Group held a focus group discussion in Batam on agentic and generative AI for procurement. I went with my team: Dommy Asfiandy, our VP, Windiarta, an AI engineer, and Laugiwa, a forward deployed engineer.

Most days I write code. That week I sat at the same table as the people who would use it.

Why we were there

PINTER is the internal AI agent platform we build at Pupuk Indonesia. Teams use it to build agents that search documents, call tools, and run multi-step workflows.

Procurement already has its own system for requests, tenders, and contracts. The question for us was simple: which of the users' ideas could run as agents on PINTER, and which belong in the procurement system itself?

We introduced PINTER to the room, then spent most of the time listening.

How procurement works, from the user's side

Before this, I knew procurement as a set of screens. In the room, I saw it as a long chain of people and documents.

A user raises a request for a material or a service. Someone writes the specification. Someone estimates the price. Someone drafts the tender documents. Then come vendors, bids, negotiation, the contract, delivery, and the invoice. Each step has its own owner and its own rules.

What surprised me was how much of the work is searching. What did we pay last time? Is this item the same as one we already stock under another name? Which vendor can supply it? Which regulation applies? People spend hours finding things before they can decide anything.

Sorting the ideas

Participants worked in four breakout rooms and wrote a long list of ideas. Our job was to map them.

The first cut was the most useful one: is this really an AI problem? Many ideas were not. A missing notification, a clearer form, a better report. Those are digitisation work, and they belong in the procurement system. Calling them AI would only make them slower to ship.

The AI ideas fell into a few families: contracts and tender documents, sourcing and vendors, bid evaluation and negotiation, pricing and specifications, receiving and invoices, and a helpdesk that answers questions.

Most of the parts already exist in PINTER: multi-agent workflows, search over a knowledge base, document parsing, scheduled agents, chat channels, structured output, and guardrails. The main missing piece is connectors to the systems where the live data sits.

We also looked for quick wins. The rule we were given scored no AI idea as a quick win. So we used a different filter: it runs on uploaded documents with no integration, it uses parts PINTER already has, and many people asked for it. A helpdesk that answers vendor questions from the SOPs and FAQs, day and night, came out on top.

Breakout room 4: the users

I spent most of my time in the user room. These are the people who raise requests, not the procurement team.

Their problems came down to three things:

• Finding references. Prices, specifications, and vendors.
• Writing documents. Tender documents and price estimates.
• Knowing where a request is. Who has it now, and why it is stuck.

Before we talked about fixes, I explained how PINTER works under the hood: how agents search documents, call tools, and hand work to each other. It helped people see what an assistant could and could not do.

Many of their ideas pointed to the same place: the request form. So instead of many separate agents, they need one assistant that sits next to the form while they fill it in. It can find equivalent materials, draft tender documents, and suggest prices and vendors.

Finding equivalent materials was my favourite. The same item is often written in different ways. Search by meaning, not by exact words, finds them. It also helps one subsidiary borrow stock from another.

Price references can start from uploaded price data and move to live data later. Vendor references wait on live data from the procurement system.

Where AI should stop

This was the most important part of the discussion for me.

Some answers have legal or financial weight. For those, a model should never be the source:

• The price estimate formula stays in the procurement system. The user and the pricing team must get the same number, so it has to be a fixed formula. AI can only suggest reference prices.
• Vendor status comes from the system of record. Whether a vendor is blacklisted or suspended is a fact, not a guess.
• Local content percentage uses a fixed formula. AI helps find the references, nothing more.

I liked this because it is also good engineering. A fact that someone could be audited on should come from a database, not from text a model generated.

A problem that was not on the list

Not every useful problem was on the agenda. While we talked through requests in breakout room 4, people kept bringing up a topic that none of the workshop themes covered.

That topic was contract management: a database of contracts and purchase orders, digital contracts, and clause review.

That sounded familiar. I had built something close for logistics: a tool that keeps carrier contracts and tariffs in one database instead of spreadsheets, with a preview before any import overwrites data. The same approach fits procurement contracts. Keep them in one place, check imports before they land, and let an agent help review the clauses.

I shared that, and suggested the group decide who owns contract management before two teams build it twice.

What I took home

• Not every problem is an AI problem. Sorting AI from plain digitisation first saved the most time.
• Users want fewer tools, not more agents. One assistant in the right place beats many clever ones.
• Draw the boundary early. Deciding what AI must not do made the rest of the design easy.
• Listen past the agenda. A problem one team raises is often one another team already solved.
• Engineers should be in these rooms. I learned more about procurement in three days than from any spec.

Next

We are writing up the results with the other teams and helping set priorities. The first agents will be the ones that work on uploaded documents, so users can try them before any integration is ready.

Thanks to Pak Dommy, Windiarta, and Laugiwa, and to everyone in breakout room 4 for their patience with my questions.