In June 2026, an AI employee went live inside the procurement division of a global biopharma enterprise, fully automating the review of purchase requests (PRs) before they become purchase orders (POs). This is a real account of what the first seven weeks looked like: a rough start, a specific technical fix, and the numbers that resulted, published as evidence rather than a pitch.

The problem: purchase requests bottlenecked on manual review

When someone at the company needs something outside standing approvals, research equipment, a new vendor contract, they file a purchase request. Once approved, it becomes a purchase order, the actual authorization to buy. Reviewing a PR means checking it against the company's procurement rules and supporting documents: purchase amount and currency, whether a cited quote has expired, whether the purchase falls under an existing multi-year contract, and which tax rules apply. Done manually at volume, this is slow and inconsistent, exactly the kind of process, structured but full of exceptions, that AI employees are built for.

How the agent works

The agent reviews each incoming PR against the company's procurement rules and supporting documents, then gives a human reviewer its findings and a recommendation. Where it isn't confident, it sends the case to manual review instead of guessing, which is what made it safe to run against live requests from day one rather than a sandboxed pilot.

Week one: a rough but safe start

In its first week live, the agent handled 205 requests. It recommended approval for just 8.3% of them and sent 64% to manual review while the team continued refining the rules. That high manual-review rate wasn't a failure mode, it was the safety mechanism working: when the agent wasn't confident about a request, it sent it to a person instead of auto-approving. That's what made week one, running against real live PRs rather than a synthetic test set, an acceptable place to start.

The fix: restructuring exceptions before scaling

Based on every case from the first few weeks where the agent's decision and the human reviewer's decision didn't match, the team re-did how the agent worked through procurement rules and their exceptions, breaking them into clearer, more predictable steps rather than one large judgment call per request.

With that change, the agent's approve-recommendation rate rose from 8.3% to 30.4% of all requests, and manual review fell from 64% to 36%. That shift gave business stakeholders enough confidence to let volume grow: weekly PRs processed climbed to 1,327, then to 2,389 by the end of week five.

By this stage, the agent was also writing its full reasoning for each decision directly inside SAP Ariba, the software the company uses to manage purchasing. A reviewer could read why the agent approved or flagged a request and check that reasoning directly, instead of re-checking every underlying detail themselves.

How cost per request dropped 90%

Once live, the agent had enough real data to self-optimize. The problem it was solving for wasn't accuracy at this point, it was that the agent was doing too much redundant work and making too many model calls per request. Two changes fixed that. First, procurement rules and their exceptions got automatically broken into clearer, smaller steps, handled in a more predictable order. Second, anything predictable, checks already run, information already known, was made deterministic instead of being re-derived by the model fresh on every request.

With those two changes in place, the workflow could support switching from a frontier model to a smaller, cheaper model without losing accuracy. Model choice alone didn't produce the result, the workflow had to be restructured into small, focused model calls first; switching to a cheaper model before doing that would have cost accuracy instead of saving money.

Cost per PR processed across the first seven weeks:

Net result: cost per request dropped from $11.57 to $1.21, a 90% reduction, while weekly volume grew more than 13x. The lesson wasn't that a cheaper model produces the same accuracy for free. It's that restructuring the work into many small, focused, mostly deterministic steps is what made a cheaper model viable without a quality tradeoff. Switching models first, without doing that, would have cost accuracy.

What's next: a customer-owned, fine-tuned model

The agent continues to process more requests, and continues to learn and improve from each one. As it gathers more data over the coming months, the goal is to fine-tune a small, open-source model deployed within the customer's own environment. That would cut costs by roughly another 90% while improving accuracy further, and let the customer own the intelligence powering its own operations rather than remain dependent on frontier models from AI labs, a concrete, in-progress proof point for the BYOC deployment model. See On-Prem, BYOC, or SaaS: How Enterprise AI Employee Deployment Works.

The pattern behind the numbers

This deployment is a working example of Zamp's broader architecture, not an exception to it. The self-learning loop that took approve-recommendations from 8.3% to 30.4% is the same mechanism described in How Zamp's AI Employees Work. The reasoning written directly into SAP Ariba is the audit trail described in Zamp Trust & Security. And the ramp from 205 to 2,712 requests a week, on the same underlying deployment, without a re-platforming project, is the "start narrow, expand on internal pull" adoption pattern that shows up across Zamp's regulated-industry rollouts: prove a narrow scope is safe, then let internal demand pull the scope wider.

For related reading on procurement software and AP automation more broadly, see Best Coupa & SAP Ariba Alternatives and AI Employees in Healthcare & Pharma: HIPAA, FDA & US Compliance Guide.