Should you build your own PO-tracking agent?
Updated August 2026
The tools available to a supply-chain team have changed rapidly: general AI agents put real automation in anyone’s hands, and they are genuinely good at two jobs. As a personal assistant, one buyer can point an agent at a mailbox and get drafted responses and status summaries in ten minutes. As a prototyping tool, a capable engineer can build PO tracking over email in a weekend: read the inbox, extract the promised dates, draft the chases.
Here in this guide, we discuss: when an internal build works, and when a team should onboard a vertical product like Cronwell.
In fact, the two are never rivals — Cronwell uses MCP, the open protocol agents use to connect to tools, so the agent your team already uses, like Copilot or Claude, can work with the record Cronwell keeps — but a shared record is a different kind of thing to build. Here is how you could think about the decision.
The three paths teams can consider
A general agent over the inbox. Claude, or an agent platform, talks to a buyer’s mailbox with a prompt. Fastest to a demo; works best as one person’s assistant rather than a team’s system.
An internal build. Engineering time on your own extraction, your own tables, your own notifications. Contained, compliant, and shaped exactly to how you work today.
A vertical product. Someone else’s opinionated system for this one job, integrated to your ERP, improved by every customer’s edge cases.
When building makes sense
- The workflow is genuinely unusual — your process is different from any vendor’s model of how POs work.
- You have a one-person procurement team. A personal agent that drafts chases for a single buyer is a fine build, and a good way to learn the problem.
- You have engineering capacity that would otherwise idle, and the discipline to maintain the project after the original owner moves on.
- No shared record is needed: nobody downstream depends on the data being complete, current, and queryable.
When buying makes sense
When the data is shared. PO tracking is not a personal productivity problem. Planning/production depends on the promised dates, receiving checks the shipping notices, managers pull the report, the ERP wants the writeback.
A shared corpus of data needs a schema — PO to line to release, supplier aliases, date semantics, status taxonomy, append-only history. Schema, not the AI, is most of the product.
When reliability is a must. An assistant that finds most confirmations is impressive; a system of record that misses one in twenty is a liability, because the misses can be invisible until kitting. Retrieval over an inbox degrades quietly. A system has to own state, deduplicate, and notify — without anyone remembering to prompt it.
When you want other people’s scar tissue. The edge cases in this domain are learned, not derived: which of four dates a supplier actually agreed to; suppliers who answer in their own part numbers and units of measure. Mature tools in this category encode hundreds of those lessons. A first-principle internal build re-learns each one on live orders, at your expense.
A supply-chain director at an aerospace components manufacturer, who had an in-house AI build on the table, put it better than we can: with homegrown systems “you become too provincial, too insular… we would build something to do things the way we do them today.” He wanted the vendor’s accumulated best practice, not a mirror of his own process.
The 12-month picture
The real cost of an internal build shows up over the first year, not the first month.
By month twelve it needs: extraction that survives every supplier’s reply style, the ERP writeback and its failure modes, dedup and threading, notification routing, permissions, an audit trail, and a maintainer who is still interested. None of it is impossible. All of it is payroll spent building a second product next to the one your company actually sells.
We say this as people who did it to ourselves: we once built our own CRM rather than buying one. The working answer turned out to be structured CRM infrastructure with an agent as the interface — the agent is a great interface and a poor record database.
Prototype vs. the production system.
If you build anyway
Genuine advice for the internal-build path:
- Design the record first, not the prompts: PO, line, release, supplier alias table, and an append-only change log with the source email attached to every change.
- Decide date semantics per supplier up front — due date, promise date, ship date — or every on-time metric you produce will be arguable.
- Build an evaluation set from your own history: a few hundred real replies with known-correct extractions, re-run on every change.
- Treat silence as a first-class event. The hardest signal is the email that never arrived.
- Gate every outbound and every record write behind a human approval from day one; trust arrives later, and the audit trail has to exist from the start.
If that list reads like a roadmap you’d rather not own, that is the honest signal to buy.
Sources — Evaluation criteria and edge-case examples from public product documentation in this category (accessed Aug 2026) · customer and prospect remarks quoted with roles; company names withheld · our own CRM build story is first-hand. More: SourceDay alternatives · how Cronwell works alongside EDI · security at Cronwell.