Agentic Skills: Procurement AI Learns & Improves How You Work

Most vendors are approaching procurement AI the same way: a growing list of narrow agents. Several for sourcing. Several for contracts. Some for supplier risk. Some for invoicing. Each one handles a defined task, and each arrives with its own data connections, its own permissions, and its own governance to keep track of.

When they need to work together, multi-agent systems and orchestrated workflows come into play. It leaves every procurement leader opening with the same question. Which agent do we start with? That is the wrong question, and answering it well still leaves most of procurement untouched.

Start somewhere else. Imagine an agent that can already do the work. Create a requisition. Launch a sourcing event and invite suppliers. Review a contract against your clause library. Match an invoice. Check a supplier’s risk profile.

Anything a person on your team could do in the system, it can do too, on day one. Once that is true, you are no longer choosing which tasks get covered.

You are deciding how your organization wants the work done, and how much of it you are willing to hand over to an autonomous system. Agentic AI skills are how the first part gets written down, and they are what makes the second part safe.

This is the third and final article in a series on agentic AI in procurement. It covers what agentic skills are, why they matter more than “agents” as a concept, and how procurement teams move from choosing use cases to deciding how much of the work runs on its own.

The Problem With How Most Vendors Approach Procurement AI

The market has largely settled on one answer, and it leaves the buyer doing the hard part.

Almost every vendor is now delivering a catalog of narrow agents, stitched together across Source-to-Pay. When their out-of-the-box agents don’t cover a need, you build more of your own. Each one handles a specific task, but each operates in its own lane, with its own data connections, its own permissions, and its own governance to manage.

The result is agent sprawl: ten bots doing ten things with no shared context between them. A sourcing agent recommends a supplier it knows nothing about from a risk perspective, because the risk agent sits somewhere else. An invoicing agent approves an invoice against the purchase order without ever seeing the contract terms that should have governed both. Orchestrator agents and workflows solve some of these problems – but just like with people, the more agents you involve to accomplish a task, the more failure points you introduce.

That leaves procurement with a shopping problem rather than a transformation. Which agent first, which one next, what gets left out, and who owns the two that overlap. You can run that program for two years and still have a team whose working day is largely unchanged, because the agents only cover the tasks somebody thought to buy an agent for.

Most conversations about AI agents in procurement stop at which tasks get covered. Procurement is not a list of tasks. It is sourcing, contracting, supplier management, purchasing, invoicing, risk and analysis, all feeding each other to deliver a continuous value-cycle that centers around how procurement ensures organizational needs are met, while optimizing the value delivered from every dollar spent.

Much of that value sits not in source-to-pay as a linear process, but in the connections between the various processes: connecting an invoice to contract terms, or launching a supplier improvement plan in response to continued poor delivery performance.

The better model is one agentic system that can do the whole job, with your way of working layered on top. Not one agent per task. One agentic system with the run of the platform, so it sees the contract when it is checking the invoice, and the risk score when it is shortlisting a supplier. Other vendors also make their platform actions available to agents.

The difference is what they do next: they divide those actions up and assign a subset to each agent, which puts you straight back to managing a roster. Ivalua gives IVA the whole surface and uses skills to direct what it should do in a given situation. Same building blocks, opposite conclusion. One agent, many skills, rather than many agents that each know a little.

What Are Agentic Skills?

An agentic skill is a set of written instructions for how a job should be done: the steps to follow, the rules that apply, and the tools the agent may use for it. They are written in plain language, and the agent picks the ones it needs at the moment it needs them, based on what was asked rather than a configuration somebody set in advance.

In addition to skills, it is important to understand the role of tools, knowledge, and workflows. Tools are the actions the agent can reach – think of this as the “buttons it can click”, even if it is not actually clicking buttons. Knowledge is the data and information the agent can access and understand – think of this as what the agent can “know”.

Skills are the instructions for which actions and knowledge to use, and when and how to use or retrieve them. Workflows, and similar capabilities like system triggers, describe the process around it: they provide process structure, sequence, review points, approvals, and clear entry and exit criteria for when an agent works autonomously.

An agent works inside the workflow or in response to a system trigger, follows the skills it needs, accesses the relevant knowledge, and calls the relevant tools to take procurement actions.

This is not an Ivalua idea. It is the model the major AI labs have standardized on, and it is exactly the model IVA is built on.

Meet IVA: One Agent, Many Skills, Across Source-to-Pay

IVA is Ivalua’s Intelligent Virtual Agent. It is not a chatbot layered onto one procurement module, and it is not a catalog of narrow bots behind a single name. It is one agentic system that works across the whole Source-to-Pay platform and takes the actions a person takes, working from the same data whichever part of the process it is in.

Which brings us back to skills, because IVA has two types of them, and the difference is the whole point.

The Skills Included with IVA

The first type are the skills an agent needs to use a source-to-pay platform. IVA comes with these from day one, meaning it knows how to use Ivalua just like an expert user would. Nobody has to teach it what a requisition is, how a sourcing event is structured, what to do when an invoice does not match the order, or how your approval workflows behave. That knowledge comes with it, which is why day one gives you a working agent rather than an empty one.

That means IVA can go to work on the day you switch it on. For example, IVA can:

• Supplier Risk and Performance: Onboard and qualify suppliers, refresh risk and performance scores, launch mitigation plans, and tie risk back to contracts and spend.
• Sourcing: Build sourcing events and RFx, invite suppliers, score and compare bids, and draft award rationales.
• Contract Lifecycle Management: Capture clauses and obligations, flag off-library language, track renewals and consumption, and enforce terms against actual spend.
• eProcurement: Turn requests into compliant requisitions, code and route approvals, create and track purchase orders, and steer buying on-contract.
• Accounts Payable: Match invoices to purchase order, contract, and receipt, enforce SLAs and not just price, flag fraud and duplicates, and time early-payment discounts.
• System Support: Answer questions from live Source-to-Pay data, generate reports and interfaces on the fly, give in-context help, and handle configuration and administration.

And more. No agent or use-case needs to be built or configured for IVA to perform any of these actions when prompted. They are the result of an agentic system that already knows how to use a source-to-pay platform.

That last point matters. A lot of procurement AI requires weeks of setup, integration work, and data mapping before anyone sees value. IVA is designed to work out of the box because of the architecture covered in the first two articles in this series.

It operates on Ivalua’s unified data model, the single source of procurement truth discussed in Blog 1. It reasons from complete, connected data: supplier records, contract terms, spend history, risk signals, performance data, all in one place. And it operates within the governance framework from Blog 2, inheriting user permissions, logging every action, maintaining human accountability for every outcome.

Users do not need to pick from a catalog of separate agents or work out which bot handles which task. They tell IVA what they need. IVA works out which skills and tools the job calls for, loads them, and drops them again as the work moves on, so it only ever carries the instructions the task needs. If the job calls for sourcing expertise, the sourcing skills load. If it turns into contract analysis, those come in instead. For complex work, IVA runs temporary sub-agents in parallel, inside the same governance.

It also means IVA can work across the boundaries between those areas, which is where a catalog of separate agents runs out of road. Ask IVA whether an invoice matches the contract, and it reads the contract. Ask it to shortlist a supplier, and it already has the risk score and the performance history.

Ask what your exposure is when a supplier fails on the morning you hear about it, and it pulls the affected contracts, the open orders, the pending invoices, and the qualified alternatives in one pass. No feature was built for any of those. They are possible because one agent can reach all of it, and because nothing has to be handed between agents that each hold a different piece.

The Skills You Write

The second type are the skills your organization creates, and this is where the approach gives you a mechanism to improve procurement continuously and make it your own competitive advantage. IVA knows how to run a sourcing event. It does not know that your team weights supplier quality above price in direct materials, or that anything above a certain threshold goes to a second reviewer, or which market sources you actually trust. That is not capability. It is judgement, and it is specific to you. Writing it down is what a skill is for.

The examples below illustrate what that looks like in practice. In each case IVA can already do the work. Your skill is what makes it happen your way, every time.

1. Benchmarking bids: Ask IVA to compare submitted bids against your historical data and external market pricing and it will do it. Your version decides what good looks like: which internal history counts, which external sources you trust, what variance is worth flagging, and how the result reaches a category manager. Without it you get a capable answer. With it you get your answer, and the same one every time.
2. Reading contracts for unusual terms: IVA can read a supplier agreement and flag language that looks unusual. Your legal team is the one that decides what unusual means. Written down, that definition holds steady across every contract, not just the ones somebody had time to read closely, and it stays current when the clause library changes.
3. Scoring supplier risk: IVA can pull financial health, ESG data, operational signals, and market context into a single profile on request. Your weighting, your thresholds, and your escalation rules are what make a score mean the same thing in every region, and let you change it in one place when your risk appetite changes.
4. Watching for spend anomalies: IVA can spot pricing outliers, volume spikes, off-contract spend, and duplicate payments. Your version is what turns that into a standing check rather than a question somebody remembers to ask, against your tolerances rather than a generic idea of unfamiliarity.

None of these is a product you switch on. They are the kind of thing an organization writes down once it knows how it wants the work done. Some of it your team will write. Some will arrive from Ivalua or an implementation partner as a starting point you then change. The point is not the length of any list. It is that the list is not where the capability comes from.

Because a skill is written down and evaluated as its own unit, it can be tested before it goes live, checked again once it is running, and improved without disturbing anything else the agent does. That is the practical difference from an opaque model, where the method is inferred rather than inspected, and from an agent catalog, where changing the method means changing the agent.

That is AI procurement software that works on day one. And it is just the starting point.

Pro Tip

Download the Enterprise AI solution brief to see how Ivalua applies agentic AI across procurement.

Ask, Delegate, Automate: Three Ways to Put IVA to Work

So how do people actually use it? There are three ways, and the difference between them is how much you hand over. None of them asks you to build anything first.[C6]

Ask. You want to know something and you do not want to go hunting for it. Which categories are running over budget this quarter. What you actually paid a supplier last year against what the contract says. Which of your top suppliers have agreements expiring in the next ninety days. Today that means opening three dashboards, exporting to a spreadsheet, and asking someone in analytics to check your working. With IVA you ask, and the answer comes back from live data. You stay in the conversation, and you decide what happens next.

Delegate. Something lands on your desk and you do not have the afternoon. A key supplier goes into administration on the morning you are due to present the category strategy. You tell IVA to map the exposure: every affected contract, every open order, every pending invoice, and a shortlist of qualified alternatives already sitting in your supplier master. Then you go to the meeting. The work is waiting when you come out. You are not watching each step, you are picking it up when it is done, the way you would with a capable colleague. Your own systems and agents can hand work to IVA the same way.

Automate. Nobody starts it at all, because IVA is already inside the process. A requisition gets checked against the supplier’s risk score and contract status before it becomes an order. An invoice gets matched against the contract terms buried in the document, not just price and quantity. Purchase orders get screened overnight for duplicates and fraud signals. Supplier scorecards refresh on a weekly schedule. Your team stops working the queue and starts working the exceptions.

Same agent, same permissions, same audit trail in all three. What changes is how much you hand over. And at every level you set how far IVA goes before a person weighs in: draft and hand back, act and notify, or stop mid-task and ask a named person when something is ambiguous, irreversible, or high-impact. That is a policy decision, not a build decision, and it is the one that determines how much capacity your team gets back.

IVA Studio^TM: How IVA Gets Better at the Way You Work

IVA works across Source-to-Pay on day one. IVA Studio is how it gets better at working the way you do, and how you decide where it runs on its own.

IVA Studio is the agentic engine IVA runs on and the control tower for how it operates: the skills it uses, the tools it can call, the systems it connects to, and the models it runs on. Those connections work in both directions, so IVA can call your other systems and your own agents can call into Ivalua. IVA fits the AI architecture you already have rather than asking you to run a separate one. IVA Studio is also where your team shapes how IVA works, with no specialized engineering required.

Refine how it works: Take an existing skill and tune it to your context. Adjust the benchmarking method to your category thresholds. Weight risk scoring toward the factors that matter in your industry. Change what gets escalated, and to whom. This is where adoption usually accelerates, because IVA starts producing what your team would have produced. Nothing new is being built. An existing method is being made specific to you.

Write down what only you do: Most work does not need a new skill, and adding one where IVA already performs well makes the system harder to govern for no gain. Repetition on its own is not the trigger either. If you want the same thing done the same way every time, you can fix the instruction to a workflow step, a scheduled job, or a button, and get that consistency without writing anything. A skill sits at a different altitude. It is for method and judgement that has to hold wherever the work turns up, whoever is doing it, and in whatever order the steps arrive. Your indirect sourcing playbook. Your direct materials qualification standard. Your region-specific compliance rules. That is when writing it down pays for itself, and it is the exception rather than the routine.

Let it check its own work: This is the part that compounds. IVA can review a job it has finished: what the outcome was meant to be, the path it should have taken, the path it actually took, and where the two diverged. From that it proposes fixes, which might be a change to a skill, a new skill for a step nobody had written down, a clearer description of a tool it picked wrongly, or a different sequence. Those proposals go to your people, who decide what to accept. It can also run the same task with and without a skill and compare the results, so an improvement is measured rather than assumed. New and updated skills are checked against a standard before they go live. Nothing changes how IVA works without someone approving it.

Keep what your best people know: When your best category manager’s approach is written into a skill, their evaluation criteria, negotiation tactics, and compliance checkpoints become a reusable organizational asset. It does not leave when they do. A new hire works with the benefit of the team’s accumulated judgement from their first week. Individual expertise becomes team capability, and that is what builds quarter after quarter until you trust it enough to raise the dial.

All of this happens inside the controls IT already set: the models IVA runs on, the permissions it inherits, and the audit trail behind every action. IVA is model-agnostic, with OpenAI, Anthropic, Google, Mistral, and Meta available out of the box, or your own model if you would rather run on your own enterprise LLM contracts. Governance stays centralized. The work of making AI useful gets distributed.

What This Changes for CPOs and CIOs

The shift is not really about skills. It is about which question your organization gets to ask.

For CPOs, the opening question stops being which problem to solve first. If IVA can already work across Source-to-Pay, day one is not a pilot on one process. It is your team working differently on all of them, with IVA doing the research and the assembly and your people making the decisions.

From there, the work is not buying more capability. It is your team, in the loop, teaching IVA how your organization actually operates: the sourcing approach that wins, the checks that cannot be skipped, the way an exception should be handled. That is what skills capture. And as that knowledge builds, you get to make a different decision entirely, which is where you are now comfortable letting the work run without you.

It also makes AI measurable in procurement terms. Instead of asking “are we using AI?” the team can ask which processes IVA is running, how well it is performing against the standard you set, and where the dial should move next.

For CIOs, the appeal is that all of this is written down. Skills are versioned, tested before deployment, and reviewed once live, so what the agent does can be inspected rather than inferred. Underneath that sit the controls IT asks about first. IVA inherits the permissions of the person it is working for, enforced by the platform rather than configured agent by agent. If a user cannot see a record, IVA cannot see it for them. Every action is logged against a responsible owner.

One permission model and one audit trail, however many skills are in play. New and updated skills also pass a review before they go live, so letting procurement shape how IVA works does not mean unreviewed changes reaching production. IT provides governance without becoming the bottleneck for every new AI procurement implementation, and generative AI in procurement becomes governed AI rather than shadow AI.

For both, the question shifts. Not “should we use AI in procurement?” and not even “which agent do we start with?” but “how do we want this work done, and how much of it are we ready to hand over?”

The Future Is Not More Agents. It Is a Platform That Is Agentic From Top to Bottom.

Picture what that looks like on an ordinary Tuesday. A category manager preparing to re-source an expiring contract can ask IVA to pull the contract, benchmark it against comparable agreements, identify stronger suppliers, set up the RFx, and launch the event. One conversation. Nothing was re-explained between steps, no context was dropped handing off from one agent to the next, and nothing stalled waiting on the bot that owns the next task. An AP team can have IVA check invoices against price, purchase order, and the contract terms buried in documents nobody has time to read.

The procurement AI market is producing a lot of agents. Sourcing agents, contract agents, risk agents, invoice agents, analytics agents. Plenty of them are impressive individually. But deploying ten different agents with ten different data connections, ten different permission models, and ten different audit trails is not a strategy. It is a management problem dressed up as innovation.

The organizations that get the most from agentic AI in procurement will not be the ones with the longest list of agents. They will be the ones with a platform where AI operates inside the system rather than on top of it, connecting data, workflows, governance, skills, tools, and institutional knowledge. A platform where the foundation is unified, governance is enforced by design, and the way the work gets done is set, tested, and improved by the people closest to it.

That is the argument this series has been making. The data foundation determines whether AI creates trust or amplifies problems. Governance has to be structural, with human accountability built into the architecture. And the real differentiator is not the agent itself but the ability to build, refine, and evolve the capabilities that make the agent useful for your organization specifically.

The future of procurement AI is not more agents. It is a platform that is agentic from top to bottom. And the question that matters is not “do you have AI?” It is whether your team can use AI to better achieve the goals that actually count.

Read the business case for agentic AI to see how procurement teams are building that case today.

Conclusion: Foundation, Governance, Capability

This series covered the three layers that determine whether agentic AI in procurement actually works at enterprise scale.

The first article made the case that agent quality starts with data quality. A unified data model is not a technical detail. It is the foundation that determines whether AI agents create trust or amplify problems. The second article argued that governance cannot be an afterthought or a configuration option.

Human accountability needs to be baked into the architecture so that every agent action has a person responsible for the outcome. This article covered the capability layer: the skills, tools, and no-code building environment that turn agentic AI from a vendor-delivered feature into something your team owns and improves over time.

Together, these three layers form the operating model for AI-powered procurement. None of them works without the others. Data without governance is a liability. Governance without capability is overhead. Capability without a trusted data foundation is a demo that never makes it to production.

Agentic AI in procurement is not a product you buy. It is an organizational capability you build on the right platform. IVA knows your data, follows your rules, and gets work done. What your organization decides is how it does that, and how much of it you hand over.