Archive | Upgrade to Premium | Sponsor

Hi {{FIRST_NAME|readers}},

There's a lot of talk about AI agents in procurement right now. A lot of frameworks. A lot of vendor decks. A lot of LinkedIn posts about the agentic future of work.

But there's considerably less content showing you how to actually build one.

Tonight we fix that.

In this issue's Deep Dive, we walk through exactly how to build a Procurement AI agent on Claude. Step by step, no complex license required, no developer required, no IT ticket needed.

Just Claude Code, an afternoon, and a spreadsheet you probably already have.
(Don’t have Claude premium? No problem. You can use this guide with MS Copilot, Chat GPT, Gemini or any other LLM model at your disposal)

But we're not going to pretend the build is the final destination...

We'll show you how to do it, and we'll be honest with you about when doing it yourself makes sense and when a purpose-built platform is going to get you somewhere your homemade agent never will (and why that is….)

Onwards!

📰 In this week’s edition:

Note: Some of the content listed above is only available in the email version of this newsletter. Don’t miss out! Sign up for free to get the next edition.

This guide will teach you how to build a procurement AI agent on Claude. It works. We've done it, and Section 2 shows you every step.

But we'd be doing you a disservice if we buried the headline: for most procurement teams, building is the detour and buying is the destination. The self-built agent is worth doing, as a prototype, a teacher, and a way to understand what you're actually shopping for. What it usually isn't is the thing you run your business on.

By using this guide to build your own agent, you'll see the following split come into focus:

There's something about that second list: it describes what you need in any business when needing to scale functionality to dozens, hundreds or thousands of people. When processes are data- and benchmark-dependent, business-critical, audit-sensitive, and evolve over time, self-built agents are toys where you need tools.

But build the prototype anyway (We'll show you how step-by-step in this guide). It costs an afternoon, and it will teach you exactly what to look for when you evaluate a platform to replace it.

Most procurement AI agent projects fail before a single line of code gets written.

Not because the technology doesn’t work. Not because the use case isn’t real. They fail because the team starts with the tool (“we’re going to build this on Claude”) without first mapping out what the process actually does.

Here’s the problem: an AI agent isn’t a chatbot you point at a problem and hope for the best. It’s a trigger-driven automated process that navigates ambiguity to produce a defined outcome. If you can’t describe the process clearly, the agent can’t execute it reliably.

The question isn’t “what can AI do?” It’s “What does this process actually require?”

The answer to that second question is what goes in your Process Scope Diagram.

The Process Scope Diagram is a one-page blueprint you complete before you write a single prompt or choose a single tool. It forces you to answer four questions that most teams skip entirely:

If you can answer all four clearly, you’re ready to build. If you can’t, no amount of Claude API access will save you.

We recommend using the IGOE format (Inputs, Guides, Outputs, Enablers), a standard process scoping tool that maps cleanly onto agent design. Guides and Inputs flow in from the left. Outputs and Enablers flow out to the right. The agent process sits in the middle.

Notice what the diagram forces you to confront. The agent needs specific inputs to function. That data comes from different systems (CLM, ERP invoice data) and is guided by different company policies. You also need a clear definition of “done”.

Working through this is the difference between an agent you can trust in production and one that sends a premature commitment to your SaaS vendor at 2am.

Get the Process Scope Diagram right and building the agent is a mechanical exercise. Skip it and you’ll spend three times as long debugging edge cases you should have anticipated.

Here’s where most guides lose you. They either go full developer (API keys, system integrations, IT procurement cycles) or stay so high-level you finish reading and still have no idea what to actually do.

This section is neither. You don’t need your IT team. You don’t need a developer. You need Claude Code, an afternoon, and a contract tracker in Excel.

Claude Code is Anthropic’s command-line tool for building AI agents. You talk to it in plain English. It reads your files, follows your instructions, and executes the process you define. Think of it as a new hire who has read every procurement playbook ever written and never sleeps... but only does exactly what you tell it to do.

Note: If you don’t have one, that’s ok too. You can ask Claude for help to build one as part of this project if needed. In fact, that’s what we’ll assume going forward in this guide. Claude might also ask you to download GIT before beginning based on your machine and OS system. If so, just install with recommended settings.

The claude.md file is the single most important thing you’ll create. It’s a plain-text document that Claude reads at the start of every session. Think of it as the standing brief you’d give a new team member on day one... except you only have to write it once.

There are two types of content that go into it. Instructions tell the agent how to behave: what it can do, what it can never do, how to handle uncertainty, and where to escalate. Context gives it the background it needs to do the job: what data source it’s reading from, what the process is, who the output is for. Together, they replace the back-and-forth briefing you’d otherwise repeat at the start of every session.

For the software renewal agent, your claude.md looks something like this:

That last instruction matters more than it looks. Without it, the agent fills gaps with confident-sounding output. That’s how a plausible-looking recommendation brief gets built on a misread contract term.

The skill file is where you define exactly how the agent executes the renewal analysis process. Where claude.md tells the agent who it is, the skill file tells it what to do, step by step.

Here’s the thing: you don’t have to write it from scratch. Claude can help you build it.

Once your Claude.md file is configured, open up a new Claude chat box to tell it to create a skill.md file. Walk it through what you do when a software contract comes up for renewal. What do you look at first? What signals tell you to renegotiate vs. renew? Where do you go when data is missing? What does the output need to look like for whoever reviews it?

Claude will turn that conversation into a structured skill file. Your job is to review it, correct anything that doesn’t match how you actually work, and push back where the logic is off.

A prompt to get you started:

The skill file Claude produces will cover: what to read from the spreadsheet, what signals to assess (utilization, contract value, auto-renew flag, last review date), the decision logic for renewal vs. renegotiation vs. termination, the output format, and what to flag when data is missing or uncertain.

Once it looks right, save it as renewal-analysis.md in your project folder. That’s your skill file.

With both files in place, drop a you now tell Claude Code how they work together. In your Claude Code chat session, reference both explicitly:

This is the moment the agent becomes a process, not just a set of files. Claude reads the standing brief, loads the skill, reads the spreadsheet, and starts working through each contract according to the logic you defined.

The first time you run this, expect it to be imperfect. That’s not a failure... it’s the start of the iteration loop.

Don’t start with your full contract portfolio. Start with five contracts where you already know what the right recommendation should be.

Run the agent. Read every output carefully. You’re checking three things:

When something’s wrong, the fix is almost always in the skill file. Tighten the language. Add an explicit instruction for the edge case. Re-run. Repeat.

This iteration loop is normal and expected. The goal of the first run isn’t a perfect output... it’s identifying where your process definition has gaps. Three or four iterations on five contracts typically produces something you’d trust at scale.

That’s it. You now have a working software contract renewal agent running in Claude. It reads your tracker, follows your process, and produces structured recommendations. No developer, no IT ticket, no system you don’t already own.

But here’s the thing: right now, it just works for you. It lives on your machine, reads your spreadsheet, and follows your process logic. What happens when you want to roll this out to the rest of the team? What happens when the business wants oversight, auditability, and a connection to the actual source of truth?

That’s Phase 2.

Getting the agent working for you (an individual) is the easy part. Getting it working consistently for the entire business is a different conversation. It involves your IT team, your data governance policies, and a few new stakeholders who’ll have questions you need to be ready for.

Here’s what that journey could look like.

The Excel tracker works as a starting point, but it’s a manual export (which means it’s already out of date the moment you download it). The natural next step is a live connection to your CLM, ERP or benchmarking data via MCP connectors: pre-built plug-ins that let Claude read directly from your source systems without a manual export step. Leading procurement system providers have already started shipping MCP servers. The others are playing catch-up. This step requires IT involvement: authentication, access controls and security review. Bring them in with a working prototype, not a concept.

An agent that nobody owns is an agent that nobody trusts. Before this goes anywhere near the broader business, one person needs to be accountable for the agent’s outputs and responsible for keeping the skill file current as the process evolves. Not a team. One person/role.

Updates to the skill file are updates to your procurement process. Treat them accordingly: documented, tested on a sample before going live and reviewed by the process owner before deployment. This is what separates a trustworthy production agent from a well-intentioned experiment that quietly drifts out of alignment with policy.

Every recommendation the agent produces needs to be saved, timestamped, and attributable. When a vendor disputes a renewal outcome (and eventually one will), you need to show your work. This is non-negotiable at the business level in a way it isn’t when you’re the only user.

“Works in demo” and “works in production” are separated by a gap most teams don’t see coming. Here are the failure modes to design for before you go live.

Claude will occasionally produce output that is fluent, structured, and wrong... not obviously wrong, plausibly wrong. A contract value slightly off. A renewal date transposed. The agent won’t flag it. Your human-in-the-loop checkpoints are the only defence. Remove them to speed things up and you’ve removed the only thing standing between probabilistic output and a vendor commitment.

A vendor acquired mid-term. A non-standard auto-renew clause that your CLM doesn’t flag. A spend record that exists in two systems with conflicting values. Your agent will encounter all of these. Without explicit handling, it either produces a recommendation anyway (dangerous) or drops the contract silently (also dangerous). Every agent needs a confidence threshold, a fallback path to a human queue, and a hard stop list for conditions that always trigger review.

Your CLM updates its schema. A policy changes. A vendor sends a renewal notice in a format the agent hasn’t seen. The agent won’t tell you when its inputs have changed in a way that invalidates its outputs. That’s your responsibility. Prompt tuning, integration upkeep, output auditing, policy synchronisation: this is the ongoing cost of ownership most teams don’t factor in at the build decision.

Teams account for the build cost (the days spent writing prompts, connecting systems, running tests). They rarely account for the full ongoing cost. The true TCO of a custom agent is not the cost of building it. It’s the cost of keeping it trustworthy ... and most teams are not honestly factoring that in when they make the build decision.

Everything in Section 3 is solvable. The question is whether it’s the right use of your team’s time. Particularly when the use case is software contract renewals, a category with enough nuance and commercial complexity to justify a harder look at what purpose-built actually means. And that question gets sharper still when you zoom out. One custom agent is a project. A dozen custom agents (each with its own system prompt, integration dependencies, maintenance cycle, and edge case backlog) is a second job. Most procurement teams didn’t sign up for that.

DIY wins in two situations.

The first is when you have a highly specific, proprietary process that no platform has productized. Think commodity-linked contract escalation clauses with supplier-specific triggers, or any process where the logic is entirely your own and no vendor will ever build it for you because the addressable market is too small. That said, a market-leading configurable platform should be able to solve for most of your custom requirements.

The second is where most practitioners should actually start: small, simple, repeatable tasks you can prove out yourself. A single-process proof of concept (like the software renewal agent we built in Section 2) costs an afternoon and a few dollars in API usage. It teaches you how agents actually behave, where your process definition has gaps, and what "good enough" looks like before you make any larger commitment. That hands-on experience is genuinely valuable, regardless of what you decide to do next.

The honest path for most teams is to start here. Build one agent. Run it. Learn from it. Then make the build vs. buy call with real data rather than vendor promises.

In most other situations, and for software renewals specifically, the gap is significant. The failure modes in Section 3 aren’t primarily AI problems. They’re domain problems. Hallucination risk drops when recommendations are grounded in verified benchmark data. Edge case handling improves when the platform has processed thousands of renewals across hundreds of organizations, not just yours. The maintenance burden shifts from your team to the platform.

Still on the fence? Take a look at the list of pre-packaged AI agents Vertice has already released. Can you imagine yourself realistically building and maintaining all of these agents in-house? Do you even have the data to make them successful?

Your DIY agent knows nothing about software pricing norms, typical discount ranges, or renewal timing patterns until you teach it. And your teaching is limited to your own data. A platform like Vertice starts with a dataset that no single organization can get close to replicating:

That’s not a marketing number... It’s the training surface that determines how good the agent’s recommendations actually are before you’ve fed it a single contract from your own portfolio. The agent already knows what a reasonable renewal outcome looks like for your specific vendor, at your contract size, with your billing structure.

The three failure modes from Section 3 map directly onto what a platform solves structurally:

The DIY approach gives you an AI that follows your process. Vendors like Vertice gives you an AI that brings procurement intelligence to your process (intelligence your team couldn’t build from your own data alone, on a timeline that makes commercial sense).

For most teams running software contract renewals, that’s not a close call. For teams with ambitions beyond a single use case (procurement agents across renewals, supplier onboarding, tail spend, requisition approvals, contract review)... building in-house isn’t just inefficient. It’s folly. Every agent you build is an agent you own, maintain, and troubleshoot indefinitely. A platform like Vertice scales with you. Your custom agent doesn’t unless you’re willing to do the scaling yourself.

Building a procurement AI agent on Claude is genuinely within reach for most teams. The technology isn’t the barrier but the process clarity is.

If you’ve read this far, you already know more than most. You know that the Process Scope Diagram comes before the system prompt. You know that human-in-the-loop checkpoints aren’t optional. You know that “works in demo” is a low bar. And you know that the true cost of a custom agent isn’t just the build... it’s everything that comes after.

Three things you can do tomorrow: