How We Designed a Procurement AI Agent for a Publicly Listed Enterprise

The procurement system at Tejas Networks ran on paper. Literally. Purchase requests moved through physical forms, wet signatures, and filing cabinets. This is a publicly listed enterprise with thousands of employees and a supply chain spanning multiple countries. And their approval workflow was a stack of paper on someone's desk.

We designed and deployed an enterprise AI agent that replaced that entire process. The result: a 90% reduction in paper-based approvals, processing times cut from days to hours, and a procurement workflow that actually matched how the business operated — not how a generic ERP assumed it should.

This is the story of how we built it, the architecture decisions that made it work, and what we'd do differently if we started today.

What was the actual procurement problem at Tejas Networks?

Tejas Networks manufactures optical networking equipment. Their procurement process involved hundreds of purchase requests per month across multiple departments, each requiring approval chains that varied by amount, category, and department. The existing system was a combination of paper forms, email chains, and a legacy ERP module that nobody trusted.

The symptoms were obvious. Purchase requests took 3-7 days to get approved. Approvers didn't know what was waiting for them. Requestors had no visibility into where their request sat in the chain. Finance couldn't generate accurate spend reports because half the data lived in email threads. And the compliance team was manually auditing paper trails that were, by definition, incomplete.

But the root problem wasn't speed. It was that the approval logic was trapped in people's heads. Different categories had different approval thresholds. Emergency purchases had bypass rules that existed as informal agreements. Budget checks happened manually — someone in finance would pull up a spreadsheet, check remaining budget, and reply to an email. None of this was codified anywhere.

When we started the engagement, the first thing we did was map the actual decision logic. Not what the policy document said. What actually happened when someone needed to buy something. Those are never the same thing in a large enterprise.

Why didn't off-the-shelf procurement software work?

Tejas had evaluated SAP Ariba, Coupa, and two other procurement platforms before talking to us. Each failed for the same reason: the approval logic was too specific to their business to fit a configurable workflow engine.

Here's an example. For raw materials above a certain threshold, the approval chain was: department head, then procurement manager, then VP of operations, then CFO. But if the vendor was on the preferred vendor list and the amount was under a second threshold, it skipped the VP. If it was an emergency production-line request, it went directly to the VP and CFO simultaneously. If the requester was above a certain grade level, the department head step was skipped entirely.

That's four conditional branches for one category. Multiply that across fifteen procurement categories, each with its own rules, and you get a decision tree that no drag-and-drop workflow builder can handle without turning into an unmaintainable mess.

The other problem was integration. Tejas runs a custom ERP for inventory and a separate system for vendor management. The procurement tool needed to pull real-time budget data from finance, check inventory levels before approving a purchase, verify vendor compliance status, and push approved POs to the ERP. Off-the-shelf tools expected Tejas to conform to their integration model. Tejas needed the opposite.

How did we architect the procurement AI agent?

We built the system as three layers: an intelligent routing engine, a decision-support agent, and a human-in-the-loop approval interface. The AI wasn't replacing human judgment — it was handling everything around and between human decisions.

Layer 1: The routing engine

The routing engine codified every approval rule into a decision graph. We spent three weeks mapping these rules with department heads, the procurement team, and finance. The output was a formal rule set — not a flowchart on a whiteboard, but a machine-executable decision tree that handled every branch, exception, and override we'd documented.

When a purchase request entered the system, the routing engine determined the exact approval chain in milliseconds. No human needed to figure out who should see this request next. The system knew. And when Tejas changed a rule — which happened quarterly — updating the decision graph took hours, not a vendor engagement.

Layer 2: The decision-support agent

This is where the AI earned its keep. Before a purchase request reached an approver, the agent assembled a decision package: current budget remaining for that department and category, historical spend on similar items, the vendor's compliance and performance history, whether inventory already had the item in stock, and a flag if the request looked anomalous compared to past patterns.

The anomaly detection was straightforward but effective. We trained a model on eighteen months of historical purchase data to establish baselines by category, department, and vendor. Requests that fell outside normal patterns — unusual quantities, atypical vendors for a category, amounts significantly above historical averages — got flagged. Not blocked. Flagged. The approver still made the decision, but they had context that previously required twenty minutes of manual research.

One example: the system flagged a purchase request for networking cables at three times the usual quantity. The approver checked and discovered it was a duplicate request — the same order had been submitted by two different people in the same department. Without the flag, it would have been approved twice. That single catch paid for a month of our engagement.

Layer 3: The approval interface

We built a clean web interface and a mobile-responsive version that worked on the approvers' phones. This mattered more than it sounds. The previous process required approvers to be at their desks with the physical form in front of them. The new system let a VP approve a purchase request from an airport lounge in thirty seconds.

The interface showed the decision package, the approval chain (who approved before, who comes after), and one-tap approve/reject/escalate actions. Comments were structured, not free-text emails that disappeared into inboxes. Every action was logged with timestamp, user, and device — giving the compliance team an audit trail that was actually complete.

What technology stack powered the procurement agent?

The backend ran on Node.js with a PostgreSQL database. We chose PostgreSQL specifically for its JSONB support — the approval rules were stored as structured JSON documents that could be queried and updated without schema migrations. The decision graph engine was custom-built in TypeScript.

The anomaly detection model was a Python service running alongside the main application. We used scikit-learn for the statistical models — nothing exotic. The patterns we needed to detect were statistical outliers, not complex image recognition or NLP tasks. A well-tuned isolation forest model handled 90% of what we needed.

The frontend was React with a component library we built for Tejas. The mobile experience used responsive design rather than a native app — faster to ship, easier to maintain, and good enough for an approval workflow where the interaction is tap-approve-done.

Integration was the hardest part. Tejas's ERP exposed a SOAP API that hadn't been updated since 2015. The vendor management system had a REST API but with inconsistent response formats. We built an integration layer that normalized data from both systems and cached it aggressively to avoid depending on their uptime for every approval action.

What were the measurable results?

After three months in production, the numbers told a clear story.

Paper-based approvals dropped by 90%. The remaining 10% were edge cases involving external vendor contracts that required physical signatures for legal reasons. We later digitized most of those too.

Average approval time went from 4.2 days to 6 hours. For standard requests within budget, the average was under 2 hours. The longest delays were still human — approvers who didn't check their phones.

Duplicate and anomalous requests caught: 23 in the first quarter. Each one represented either a duplicate purchase, an out-of-policy request, or a vendor compliance issue. The estimated cost avoidance was significant enough that finance started tracking it as a metric.

The compliance team reported that their quarterly audit, which previously took two weeks of pulling paper records, now took two days of running reports. The audit trail was complete, timestamped, and searchable.

But the result that mattered most to the CTO wasn't a number. It was that the procurement team stopped being a bottleneck. Departments that used to wait a week for approvals now got them the same day. The relationship between procurement and the rest of the company changed because the friction was gone.

What would we do differently building this enterprise AI agent in 2026?

We built this system before the current generation of large language models matured. If we were starting today, three things would change.

First, the anomaly detection layer would use an LLM for explanation generation. Our current system flags anomalies and shows the statistical reason — 'quantity 3.2x above category average.' An LLM layer could generate plain-English explanations: 'This request is for 500 units of Cat6 cable. Your department typically orders 150 units quarterly. The last order of this size was placed by [name] in March for the building expansion project.' That context makes the flag actionable without the approver having to investigate.

Second, we'd add a natural language query interface for procurement analytics. Right now, getting answers like 'how much did we spend on networking equipment from vendor X in Q3' requires running a report. A conversational interface over the procurement database would let finance and department heads ask questions directly. The data is already structured and clean — it's a straightforward RAG application.

Third, we'd use AI to suggest approval rule changes. After eighteen months of data, the system knows which rules create bottlenecks (the VP approval step that adds two days for low-risk purchases) and which rules are never triggered (the emergency bypass that's been used once in a year). Surfacing those patterns to the procurement team would let them optimize their own process continuously.

What does this mean for enterprises evaluating AI agents?

The Tejas Networks project taught us something that applies to every enterprise application deployment: the AI is the easy part. The hard parts are mapping the real business logic (not the documented business logic), integrating with legacy systems that weren't designed to be integrated with, and getting organizational buy-in from people whose workflow is about to change.

If you're evaluating enterprise AI agents for procurement or any operational workflow, here's what we'd tell you. Start by documenting what actually happens, not what's supposed to happen. Build the integration layer before the AI layer — if you can't get clean data in and push actions out, the intelligence doesn't matter. And plan for a three-month adoption curve where you're running old and new processes in parallel.

We've built production AI agents for procurement, call quality monitoring, CRM lead scoring, and manufacturing cost estimation. The pattern is consistent: the agent's value isn't replacing human decisions. It's eliminating the forty-five minutes of research that used to precede every human decision.

The procurement agent at Tejas Networks has been running for over two years now. It processes hundreds of requests monthly, and the approval rules have been updated dozens of times by Tejas's own team without calling us. That last part — the system being maintainable without the team that built it — is what separates an enterprise AI agent from an expensive proof of concept.