.png)
Let me guess. Your in-house procurement and sourcing teams are bogged down with routine, repetitive tasks performed through email and phone calls. The data in your ERP (updated delivery dates, order quantities, etc.) is inaccurate or latent because your team is updating it manually. You could be managing a higher percentage of your spend if your procurement team had more time for strategic sourcing. You're frustrated. You know there's a much better way. The problem sounds like a perfect use case for AI agents. You're thinking: let's go build some agents.
I just described my worldview three years ago, my motivation for co-founding Didero. I was an operator just like you, equally frustrated with the state of affairs in our purchasing group. I knew AI agents were well-suited to solve the problem, so I set off to build a world-class solution. And I pulled in two of the smartest people I knew to help.
Three years later, after investing significant time, money, and resources in building an agentic AI framework to automate procurement, here's some hard-earned advice.
A theme that keeps coming up in conversations with procurement and operations leaders: teams are getting serious about building AI agents internally. The energy makes sense. The tooling is accessible, the prototypes are convincing, and owning the capability feels like the right call. What tends to become clear over time is the gap between one working agent and what procurement automation actually requires underneath it. Not a single agent, but a network of them, coordinated, context-aware, and operating within governance rules that hold up against real supplier variability. Understanding that architecture early is what separates a successful expansion from one that stalls after the second agent.
A purchase order acknowledgment doesn't exist in isolation. It connects upstream to sourcing context and supplier history, and downstream to AP records, inventory status, and production scheduling. When a supplier returns a confirmation with a quantity change and an unannounced tariff surcharge, the right response isn't just logging the update. It means flagging the line-item variance, applying cost tolerance rules, routing it for review, holding the AP ledger, and updating the supplier record. That's a coordination problem across several agents, not one.
Most procurement workflows are built the same way. Each one connects to others, shares context, and depends on decisions made upstream. Teams that build one agent to handle one workflow tend to discover this structure not through planning but through expansion: when the first agent works well enough that the next workflow gets assigned, and then another, and the question of how they share context and who coordinates them becomes the next design challenge.
That's the architecture question worth thinking through before the build starts, not after.
Enterprises are deploying AI agents faster than they're governing them. According to Salesforce's 2026 Connectivity Benchmark, which surveyed 1,050 IT leaders, the average enterprise runs 12 AI agents today and expects to reach 20 within two years. Half of those agents currently operate in isolated silos, with no shared context, no unified governance, and no coordination between them.
That's not an AI capability problem. It's an architecture problem. And in procurement specifically, the stakes are concrete.
A February 2026 CIO analysis walked through a useful illustration: a global logistics firm deployed two autonomous agents, one for inventory procurement and one for dynamic warehouse pricing. A data lag caused the procurement agent to see a low-stock signal and over-order high-value components. The pricing agent, seeing the incoming surplus, cut prices to move volume. Both agents performed exactly as designed. What didn't exist was an orchestration layer to reconcile their conflicting outputs. The result was $2M in premium freight to ship components the firm was selling at a loss. The lesson isn't that the agents failed. It's that agent coordination needs to be part of the design from the start.
In direct procurement, where physical spend, BOM components, and production-critical inventory are involved, coordination is the core design problem.
There's a second dimension that tends to surface later in an agent build, and it's worth thinking through early.
Physical procurement runs on operational logic that accumulates over years. What counts as an acceptable quantity variance on a critical component. How to read a supplier acknowledgment that groups line items under an aggregate index rather than listing them individually. When a spot-buy price drift needs escalation and when it falls within tolerance. How push-out and pull-in signals interact with production scheduling without creating inventory whipsaw effects.
None of that logic is native to a general-purpose LLM. A SupplyChainBrain analysis published earlier this year described what happens when teams run into this in practice: "The agents IT departments built lacked supply chain intelligence. They couldn't tell detention from demurrage, and things like cross-dock timing, on-time/in-full penalties and multimodal logistics were all foreign concepts." Teams that have been through the expansion phase tend to put it plainly: the gap between general-purpose reasoning and domain-specific procurement judgment is real, and encoding it takes time.
An internal build has to encode that logic from scratch. Someone has to document it, translate it into agent behavior, test it against real supplier variability, and maintain it as the business changes. That's an ongoing knowledge transfer project running in parallel with everything else engineering owns.
The prototype solves one workflow well. Production procurement automation (the kind that moves OTIF, working capital, and COGS) means a coordinated network of agents sharing context across sourcing, order management, quoting, AP, master data, and exception handling, with a human oversight layer across all of it.
Building that internally means taking on the orchestration layer that routes context between agents and resolves conflicts when outputs disagree. The exception management interface that lets buyers review and override agent decisions without routing everything back to email. The audit trail infrastructure that makes every agent action traceable for AP compliance. The domain logic layer that encodes how the business handles real edge cases: partial deliveries, multi-line pricing splits, tariff variances, supplier format changes. And then maintaining all of it as the supplier base changes, ERP configurations update, and underlying models shift between versions.
Each is a substantial engineering project. Together, they describe the infrastructure a purpose-built agent network carries as its baseline. Teams starting from the first agent aren't just building that agent. They're taking on the whole stack underneath it, and understanding the scope of that upfront shapes what a sensible build-vs-buy decision looks like.
None of this argues against internal development across the board.
Bounded automations for specific internal workflows (a notification trigger, a spend categorization tool, a read-only semantic search over legacy specifications) are exactly the right use of internal engineering capability. Narrow scope, static data, low operational stakes. The failure mode is recoverable, the maintenance surface is contained, and the team retains full ownership of what they built.
The distinction that matters: are engineers building logic that only your organization can know, or are they building the infrastructure plumbing that any production-grade agent network requires? The first is where internal development creates genuine, compounding leverage. The second is what grows into a permanent maintenance commitment that competes with every other priority on the roadmap.
When a procurement or operations leader asks whether to let their IT team run with an agent build, the most useful follow-up isn't whether they can build it. It's what the organization is actually building toward.
A network of coordinated agents handling the full procurement cycle (reading supplier communications, writing back to the ERP, routing exceptions, maintaining the audit trail, sharing context across sourcing, AP, and master data) is the operational outcome that moves the numbers that matter. Getting there from a single-agent prototype is a longer road than the demo suggests. Trust me, I know. Knowing the shape of that road before the first sprint is what makes the journey faster.
