Rebuilding vs. Automating a Broken Procurement Workflow
Automating shadow processes makes them faster and more dangerous, not better.
Automating a procurement workflow that runs on shadow processes does not fix the workflow. It makes the shadow faster, harder to see, and considerably more dangerous to the project or the business that depends on it. The only defensible path is to diagnose where the real process actually lives, rebuild the logic that governs it, and only then let AI touch any part of it. Nothing about this requires a platform decision or a transformation roadmap. You need to find the one process that hurts and understand, in operational detail, why it hurts before you write a line of automation against it.
Why procurement workflows accumulate shadow processes in the first place
A requisition enters an enterprise system as a formal event: a line item, a cost center, an approval chain configured years ago by someone who no longer works at the company. But the decision to buy was made before that line item existed, in a hallway conversation between a project lead and a finance partner who both know the budget is tight and the vendor is reliable. The system records the decision after the fact. It never captured the judgment that produced it, because the judgment required context, like budget alignment, stakeholder trust, supplier history, that no formal system holds at the moment someone actually needs it. The workaround is the organization building, in email and spreadsheets and chat threads, the exact process the formal system was supposed to provide and didn't.
That adaptation compounds. Email approvals bury requests in inboxes until chasing them down becomes someone's unofficial full-time job. Spreadsheet tracking multiplies into competing versions, none of which agrees with the others on what spend has actually been committed. Invoices arrive through vendor portals, through email, through the mail, with no single intake point to catch them, so reconciliation becomes a forensic exercise every month. Two teams, unable to see each other's open orders, duplicate a purchase neither of them needed to make twice. Vendor onboarding drags long enough that the first sign of trouble is a payment failure downstream, long after the relationship should have been clean. And it's not that real-time visibility into committed spend fails for lack of data. The data exists. It just lives across six disconnected systems that were never designed to talk to one another.
Each of these failures feeds the next. Buried approvals push people toward spreadsheets as an informal tracking layer. Competing spreadsheets make invoice reconciliation worse. Poor reconciliation obscures committed spend, which makes duplicate purchases more likely because nobody can see what's already been ordered. This is a reinforcing loop, and it is strikingly consistent wherever procurement happens: a general enterprise finance department and a construction general contractor develop the identical pattern, because both are solving the same underlying mismatch between formal authority and real decision-making. That consistency matters, because it means the failure is structural, and a structural failure responds very differently to automation than a one-off process bug does.
What automation does to a shadow workflow
Automating a shadow workflow does not surface it. It encodes it. An automation layer built on top of this kind of process observes the sequence of system entries, the requisition, the PO, the invoice match, and speeds up the documentation of decisions that were already made somewhere else, earlier, by someone the system never consulted. The decision sequence and the system sequence were never the same thing, and automation only ever touches the second one. The shadow doesn't disappear, because the conditions that created it never changed: approval authority still doesn't match where decisions actually get made, and the data an agent needs still doesn't exist in the system at the moment it needs to act.
Two failure modes follow directly from that gap, and they are mirror images of each other. An AI agent operating on incomplete or retrospective data will treat a record of what already happened as though it were a signal of current intent, and it will act on that signal: approving, routing, or flagging a transaction based on information that was already stale by the time the agent saw it. The alternative is just as damaging. Faced with the same uncertainty, an organization builds in so much caution that every consequential decision escalates to a human reviewer, and the agent ends up doing nothing a human wasn't already going to do anyway. Either the system causes harm by acting with false confidence, or it gets neutered into irrelevance because nothing can be trusted to run without a person checking it. Both outcomes are the same broken loop, just faster.
Most procurement organizations facing this do not actually have an AI problem. They have a maturity problem. Deploying autonomous agents on top of broken master data and inconsistent approval logic doesn't produce a smarter process, it produces faster mistakes, executed with more confidence than the old, slower, human-mediated version ever had. If a procurement team cannot agree on what is true for its suppliers, its contracts, and its committed spend, introducing an AI agent will not resolve that disagreement. It will amplify it, because the agent will act on whichever version of the truth it happened to be pointed at, and the consequences will become visible only downstream, after no one has noticed. This causes the well-documented gap between AI pilots and AI systems that survive in production: the pilot works on a clean, narrow dataset assembled for the demo, while the production environment is the shadow workflow in full, uncurated form.
Terminal Use's founding premise is built around exactly this failure mode: automating a broken process makes it worse, faster, and that pattern is most visible in procurement workflows, because the gap between formal authority and real decision-making is so wide and so well-established. The firm's approach is to diagnose and rebuild the workflow end to end before any agent is deployed into it, rather than encode the shadow process into something that now runs at machine speed.
Why construction and infrastructure procurement failure becomes irreversible
In a general enterprise finance department, a broken procurement workflow produces delay: a slower close, an irritated vendor, a budget variance someone has to explain in a meeting. In construction and infrastructure, the same failure stops the project. Construction procurement is structurally fragmented in ways that make it especially vulnerable: communication runs through phone calls and email threads, purchase orders get created by hand, supplier information sits scattered across inboxes and spreadsheets, and there is limited central visibility into procurement status, material commitments, or inventory levels at any given moment. The identical shadow workflow pattern described above runs here at project scale, so you get schedule slippage instead of an approval bottleneck nobody notices for a week.
AI workflow orchestration inside a construction ERP only matters because procurement decisions in that environment depend on signals arriving simultaneously from estimating, project management, document control, and finance, not from any single application. A shadow workflow severs exactly those connections, because it routes around the system that was supposed to carry them. A material requisition gets approved informally in a site trailer, and it never updates the budget model that estimating is watching, so document control never learns that a schedule-critical material has been committed.
The stakes become concrete, and severe, in large-scale equipment procurement for energy and data-center infrastructure. Lead times for large power transformers have more than doubled since 2021. Cable procurement now routinely runs two to three years, and transformer procurement can stretch to four. Against timelines like that, a shadow workflow error in procurement isn't an inconvenience, it is a direct threat to whether the project gets built on the schedule anyone promised. A U.S. backlog for new high-voltage transformer orders means a single procurement misstep, a missed specification, a late PO, a vendor relationship mishandled, can halt a multi-billion dollar project indefinitely, with no faster alternative supplier to fall back on.
The question that actually determines project risk is rarely when the equipment will ship. It's what has to be technically closed before that shipment date means anything. If a transformer arrives without approved drawings, completed test documentation, or installation guidance, it still delays the project, regardless of what the delivery schedule said. If a control panel arrives without finalized I/O mapping, it creates a commissioning bottleneck that no amount of on-time shipping logistics can solve. Energization readiness is its own distinct, and frequently undertracked, failure mode: a facility can be fully built, transformers installed, switchgear in place, and still sit idle for months waiting on qualified testing crews who are committed to other projects. Field evidence from transmission project delivery in India confirms this same declared-versus-actual gap at scale: only a small fraction of projects awarded through competitive bidding met their original scheduled completion date, with substantial median delays, and the binding constraint was frequently land and right-of-way acquisition, a step that sits upstream of the procurement process teams typically audit when something goes wrong. In every one of these cases, the failure occurs at a step nobody was formally watching, for the same reason shadow workflows exist in the first place: the formal system tracks what was planned, while the actual constraint on the outcome is visible only on the ground.
In construction and logistics, the cost of automating a broken procurement workflow is never a slow back office, it is a stopped project. That is where the distance between rebuilding and automating turns into operational risk, so firms deploying AI agents into these environments need to rebuild the process itself first, instead of encoding fragmented decision-making and ad-hoc supplier data into autonomous systems that now operate at full project scale.
What diagnosing a broken procurement process requires
Fixing any of this starts with agreement on three things: what the real process actually is, where authority actually sits, and what the system of record needs to contain before any agent is allowed to act on it. None of that is a platform decision. It's a diagnostic one, and it has to happen before a single tool gets selected.
The diagnostic begins by mapping the shadow workflow, not the documented one. That means identifying who actually approves a purchase, at what point in the real decision sequence that approval happens, and what information that person needed, at that exact moment, that the formal system didn't have available. The six failure modes described earlier, email approvals, competing spreadsheets, scattered invoice intake, duplicate purchases, slow vendor onboarding, and the absence of real-time spend visibility, are symptoms of deeper process gaps. What matters is identifying which underlying process gap is generating each failure mode, and in what sequence they compound.
Master data is the most common condition that disqualifies an organization from safe automation. If a team cannot agree on a single version of the truth for its suppliers, its contracts, and its spend, no agent built on top of that disagreement can make a correct decision, no matter how capable the underlying model is. Master data problems are the most common reason organizations lack the maturity to automate safely. Alongside it, approval logic has to be rebuilt rather than simply documented: the real question is whether the formal approval sequence matches where organizational authority actually lives, and if it doesn't, that mismatch has to be resolved before any automation touches the process, not after.
In construction procurement, this diagnostic scope extends past the back office and into project controls and technical closeout. Workflow orchestration in that environment is only as reliable as the data connections feeding it: a material requisition that cannot be validated against budget, schedule, and supplier performance all at once is a candidate for process redesign first, not for AI-assisted routing. In infrastructure procurement, the diagnostic question is never whether an organization can automate PO creation. It's what has to be technically closed before a delivery event actually matters to the project schedule, and answering that requires mapping procurement directly to commissioning dependencies, not just to the supply chain that gets the equipment to the site.
This diagnostic moment, when an organization first sees that its procurement decisions actually happen in email threads and hallway conversations rather than in the formal system it built for exactly that purpose, is precisely where firms like Terminal Use begin. A process audit that shows how the workflow actually runs today, before any automation touches it, reveals whether the shadow process is structural, meaning authority genuinely sits somewhere other than where the formal chain says it does, or whether it is simply undisciplined and correctable without a redesign. That distinction determines everything about what happens next. None of this work is technically difficult. It's organizationally difficult, because it requires admitting that the documented process and the real one have diverged, often substantially.
How AI fits into a rebuilt procurement process
When process logic is sound and master data can be trusted, AI agents in procurement stop amplifying risk and start multiplying throughput in a way that's measurable. The operational pattern that works in practice assigns AI to requisition classification, approval routing, vendor communication triage, and delivery monitoring, treating these as execution tasks, while preserving human gateways specifically for high-value or high-risk decisions rather than making human review a default everything escalates into.
A procurement deployment inside a multinational division illustrates how that sequence plays out. What started as a project to deploy pre-programmed background agents evolved into a stateful, multi-channel orchestration platform where a sourcing agent hands context to a risk agent, which in turn escalates to a compliance agent only once defined thresholds are crossed. Human gateways are built into that architecture for the decisions that actually warrant them, not as a catch-all for every transaction the system touches.
In construction procurement, the orchestration layer connects transactional ERP data with supplier performance history, contract terms, and schedule impact, enabling AI-assisted approval prioritization based on project criticality and spend risk rather than static, one-size-fits-all rules. That prioritization only works when the underlying data connections are clean, which is exactly the condition the diagnostic phase is meant to establish before deployment begins. Governance has to be built into the agent architecture itself, not added afterward: agents that inherit a user's permissions, never exceed them, and log every action they take create the audit trail that makes AI-assisted procurement defensible to a finance team, an auditor, or a regulator. That design pattern is what separates a genuinely rebuilt process from an automated version of the same shadow workflow, just running at higher speed.
Organizations report real productivity gains from AI in procurement when they fix how the process works before putting any agent into production. Leading organizations report meaningful productivity gains because the process the model operates inside was designed to make its output trustworthy, not because the underlying model is more capable than anyone else's. In construction procurement specifically, AI creates measurable value at a narrow set of workflow intersections: requisition intake normalization, delivery risk prediction, vendor communication summarization, and invoice anomaly detection. Each of those requires clean upstream data to produce an output anyone can rely on, which is the entire argument for doing the diagnostic first.
What matters first is identifying the actual process and precisely where it breaks, not picking which AI tool to buy for procurement. A platform strategy or an enterprise-wide transformation roadmap can defer that question indefinitely, often for years, but a focused process audit answers it before a single deployment decision gets made. The first AI-first process built on a properly diagnosed workflow should be live within weeks. If it's taking quarters instead, the diagnostic step was skipped, and the organization is simply automating its way into a faster version of the same broken workflow it started with. The organizations that move slowest into AI deployment, because they insist on doing the diagnostic work first, are consistently the ones that move fastest once real operational change actually begins.
