ProcurePilot Voice Autopilot

Background

Industrial spare-parts procurement is a market that still runs almost entirely on the telephone. There's no online pricing, no transparency, and when a machine goes down, the person responsible has to call three to eight suppliers, describe the same broken part every time, sit through evasive pricing, and hope they didn't just accept a 50%+ markup on top of an already stressful day. Real quotes for identical parts routinely range 2-6x apart, and nobody under production-downtime pressure has the time to actually gather enough calls to compare properly.

I built ProcurePilot Voice Autopilot for "The Negotiator," a challenge set by ElevenLabs at Hack-Nation's Global AI Hackathon (hack-nation.ai). The brief left the market open, B2C or B2B, any vertical where pricing still gets decided over the phone instead of online. I picked industrial spare-parts procurement specifically because of the urgency angle: when production is stopped, every minute a buyer spends on hold instead of comparing prices is a minute the business is losing money twice over, once to downtime, once to whatever markup the first friendly-sounding quote happened to include. The whole thing was built solo, in under 24 hours.

How It Works

ProcurePilot is a three-agent voice AI pipeline built entirely on the ElevenLabs Agents Platform, where each agent owns exactly one part of the job:

• Intake Agent — Builds a confirmed job specification either through a voice interview or by reading an attached photo/PDF of the broken part. Two intake paths, one shared schema, always confirmed by the buyer before anything downstream happens.
• Caller Agent — Phones each supplier, describes the job identically every time, and negotiates using real leverage: the actual best offer collected from a previous call, never a scripted or invented number. It holds firm against overpricing by citing the ERP baseline explicitly, declines unrequested upsells, and handles stonewalling suppliers gracefully with a hard cap on repeated questions so it never loops.
• Closer Agent — Reads the final, ranked comparison back to the buyer in plain language, explaining the recommendation without executing any purchase itself.

The part I'm proudest of technically is how the Intake agent reaches its data. It connects directly to ERPNext through a Model Context Protocol (MCP) server, no middleman API, no stale cache, and that connection isn't limited to pricing. It pulls the full product record: specs, tolerances, whatever the master data holds. That matters because a buyer doesn't have to describe the part in painstaking detail; they can just name it and let the agent pull everything it needs straight from the ERP. That same direct link is what makes the negotiation credible in the first place: every price the Caller agent cites as leverage traces back to a number it actually pulled from the ERP or from a previous, real supplier call, never generated text. And because ERP access lives entirely in that one connection, the whole architecture is backend agnostic; point the same MCP link at a different ERP and the negotiation logic doesn't change at all. A lightweight n8n layer sequences state between the separate agent calls, computes red flags against the ERP baseline, and builds the ranked report, but it deliberately never touches ERPNext itself, that boundary belongs entirely to the agents.

In testing, a supplier's price moved from €6.00 to €5.00 purely because the agent cited a second supplier's real, verified offer as leverage, then held that price when the same supplier tried to upsell an unrequested mounting kit on the callback. Three distinct negotiation personas (an aggressive overpricer, a stonewaller, an upseller) and all three required structured call outcomes (quote, callback, decline) were demonstrated end to end, from voice intake all the way to a plain-language recommendation.

Challenges

Twenty-four hours is a brutal constraint for a three-agent system with a live ERP integration, and most of the pressure showed up in the negotiation logic itself rather than the plumbing. Getting the Caller agent to actually push back on an inflated quote, instead of politely accepting the first number it heard, took several rounds of tightening the prompt with explicit numeric thresholds rather than vague instructions like "negotiate firmly." The same was true for stopping it from looping forever against a stonewalling supplier; the fix ended up being a hard cap of two follow-up questions before the agent is required to close the call as a decline, which also directly satisfies one of the brief's required structured outcomes.

The other real challenge showed up right at the end: the Caller and Closer agents' public share links started failing for anyone outside my own workspace, connecting for a fraction of a second and then dying with a generic "WebSocket already in CLOSING or CLOSED state" error, in both voice and text chat mode. I went deep into browser WebSocket frame inspection to rule out every configuration explanation I could think of, security settings, dynamic variable values, voice model, LLM choice, STT settings, workspace and branch consistency, all identical to the one agent that did work. The connection opens cleanly (HTTP 101), streams the first message perfectly, and then simply stops mid-stream with no close frame and no error payload at all, which points at something on the platform side rather than anything in my own configuration. It's a good reminder that shipping on someone else's infrastructure, however good the product idea is underneath it, comes with a dependency you don't fully control.

What I Learned

This was my first time building on ElevenLabs, and it left a strong impression of how far voice agents can be pushed once you give them real tools and real data to reason over instead of just a scripted persona. The gap between "an agent that sounds convincing" and "an agent whose every claim is traceable to a real, stored fact" turned out to be almost entirely a data-architecture problem, not a prompting problem, and solving it is what actually made the negotiation feel real instead of staged.

It also pushed me to think past the demo and toward the venture question underneath it: an MCP connection to an ERP isn't a moat by itself, it's an open protocol anyone can use, but the structured negotiation history that accumulates from actually using a system like this over time is. A year of real, itemized supplier calls for a given region and part category is something a competitor can't replicate overnight, and that's a very different kind of defensibility than "we built an AI that calls people." Between the deep technical debugging and that shift in how I think about what's actually valuable in an AI product, this ended up being one of the more useful 24 hours I've spent building something from scratch.