AI Agent Production Deployment: What We Learned Shipping 3 Enterprise Agents

We have shipped 3 production AI agents across three industries: a contact centre quality monitor that scaled from 50 to 80+ agents in 3 months, a CRM lead scoring engine, and a manufacturing cost estimator that replaced a multi-day spreadsheet process.

This is what each build actually cost, how long it took from prototype to production, and what surprised us along the way. Most published material on AI agents is vendor benchmark or theoretical framework. This is deployment data from three engagements we delivered ourselves.

We are publishing the numbers because most of what circulates about AI agents in 2026 skips from demo straight to case study, with nothing in between. Nobody publishes what the build actually cost, where the weeks went, or what broke in week 6 of a pilot that looked flawless in week 2. That gap is what this piece fills.

What are the 3 production agents we shipped?

Each agent runs inside a different business function, for a different type of client, on a different data source. What they share is that all three replaced a manual, judgment-heavy process with an automated one that runs continuously, not on a batch or nightly schedule.

The contact centre quality monitor listens to call transcripts, scores them against a rubric the operations team already used manually, and routes flagged calls to a supervisor queue. It replaced a process where 2 QA staff could realistically sample 5-10% of calls per week.

The mechanism behind the monitor is not a single model call. It chains transcript segmentation, rubric-matching against the specific quality criteria the operations team already used, and a confidence check that routes low-confidence scores to a human reviewer instead of auto-publishing them.

The CRM lead scoring engine reads every inbound lead — form fill, firmographic data, and behavioral signals from the website — and assigns a fit score before a sales rep ever touches the record. It replaced a manual triage process a sales ops manager ran by hand every morning.

The fit model behind the CRM agent was trained on the client's own closed-won and closed-lost history, not a generic ICP template. That distinction mattered more to accuracy than any prompt engineering we did afterward.

The manufacturing cost estimator takes part specifications and matches them against a database of historical jobs, material costs, and machine time, then produces an estimate with a confidence range. It replaced a spreadsheet-based process that pulled a senior estimator off the floor for 2-3 days per quote.

The estimator does not generate a number from scratch. It retrieves the closest historical jobs by specification similarity, adjusts for current material pricing, and flags any part with no close match for manual estimation instead of guessing.

What did each cost to build?

Cost ranged from $40,000 to $80,000 per agent, and the variance had almost nothing to do with the AI model itself. It came from integration complexity and how clean the underlying data was before we started.

The cheapest agent to build was not the simplest agent conceptually. It was the one with the cleanest data and the fewest systems to integrate against. The manufacturing estimator cost the most because roughly half the budget went into data cleanup before the model ever saw a production job.

None of the three budgets broke down as mostly-model-work. Across all three builds, model prompting and evaluation logic accounted for 20-30% of engineering time. Integration, data cleanup, and building the review-and-override interface humans needed to trust the output accounted for the rest.

Team composition looked similar on all three engagements: one engineer focused on the model and evaluation layer, one or two engineers on integration and pipeline work, and a part-time reviewer from the client's own operations team checking output quality during the pilot. The client-side reviewer was not optional — every build that skipped this role in an early internal draft took longer to reach production, not less.

The manufacturing estimator is the clearest case of cost following data quality rather than model complexity. Roughly $35,000 of its $70,000-$80,000 budget went into reconciling 6 years of job records against 3 different naming conventions the client had used for materials over that period, before the retrieval logic could run against them reliably.

A full breakdown of what changes the number up or down is in our AI agent development cost and timeline guide, including what happens to cost when there is no clean historical dataset to start from.

How long from prototype to production?

Every agent followed the same three phases: a working prototype in 2-3 weeks, a supervised pilot in 4-6 weeks, and a hardening period of 4-8 weeks before we called it production. Total time ranged from 10 to 18 weeks depending on integration complexity.

Production hardening took the longest on the manufacturing estimator because the ERP integration surfaced edge cases the prototype never saw — part numbers that did not match any historical record, materials that had been renamed twice in the source data, and machines that had been decommissioned but still appeared in job history.

The supervised pilot phase is not optional on any of these three builds. Every agent ran alongside the existing manual process for weeks before we let it operate independently, with a human checking every output against what the old process would have produced.

On the contact centre monitor, the supervised pilot caught a scoring drift in week 3 that would have gone unnoticed for months without a human comparing agent scores against manual QA scores side by side. The rubric had an ambiguous clause that the model interpreted more strictly than the human QA team did, and we rewrote it before the agent went fully live.

What scaling metrics looked like

The contact centre quality monitor is the clearest scaling story. The client scaled from 50 to 80+ agents in 3 months without adding a single QA headcount, because the monitor scores 100% of calls instead of the 5-10% a manual team could sample.

Call coverage went from roughly 400 sampled calls a week to over 9,000 scored calls a week across the same period, with the QA team's role shifting from sampling and scoring to reviewing the flagged subset and running coaching sessions.

The CRM lead scoring engine processes every inbound lead the moment it arrives, instead of waiting for the next morning's manual triage. Sales reps now see a fit score attached to a lead within seconds of the form submission, not a day later, which shortened average first-touch time from same-day to under 10 minutes during business hours.

The manufacturing cost estimator cut estimate turnaround from 2-3 days to under an hour for roughly 70% of incoming quote requests. The remaining 30% — parts with no close historical match — still route to a senior estimator, by design, rather than forcing the agent to guess.

None of these three scaled by getting smarter over time in a dramatic way. They scaled because they removed a human bottleneck from a process that had a fixed daily capacity, and the underlying model performance stayed roughly flat after the first month in production.

Score agreement between the contact centre monitor and the QA team's own manual scoring stabilized at roughly 92% within the first month, and held there through the scale-up to 80+ agents. That number mattered more to the client's trust in the system than any accuracy figure we could have quoted from a benchmark, because it was measured against their own historical judgment, not a generic test set.

The 5 things that surprised us

1. The model was never the bottleneck. On all three builds, the language model or scoring logic worked well within the first few prototype iterations. The weeks of delay came from data cleanup, API rate limits on legacy systems, and mapping business rules that existed only in one person's head. We budgeted for model tuning and spent the time on plumbing instead.

2. Accuracy plateaus fast — the gains after that come from workflow redesign. Each agent hit its steady-state accuracy within the first 2-3 weeks of the pilot. Every improvement after that came from changing how the output was used, not from retraining the model. The lead scoring engine got more useful when we changed where the score appeared on the sales rep's screen, not when we adjusted the scoring weights.

3. Users trust an agent faster when they can see its reasoning. The contact centre monitor shipped with a one-line justification attached to every score — the specific moment in the call transcript that drove the flag. Supervisors started trusting flagged calls within days. An earlier internal version that only showed a numeric score took weeks longer to get adopted, with no change to the underlying accuracy.

4. The simplest-looking agent took the longest to get adopted. The lead scoring engine had the smallest technical footprint of the three, but sales reps ignored the score for the first month because nobody had explained why a lead scored the way it did. Adoption only moved once we added the top 3 factors behind each score directly next to the number.

5. Production monitoring takes more ongoing attention than the build did. All three agents needed a monitoring retainer after launch, not because the model degrades on its own, but because the businesses around them keep changing. The manufacturing client renamed a materials category 3 months after launch, and the estimator silently misclassified every job using the new name until a monitoring alert caught it.

Taken together, these five surprises point at one pattern: the risk in production AI agents is almost never the model failing to reason well. It is the business context around the model shifting without anyone telling the agent.

When are AI agents ready for production — and when are they not?

An AI agent is ready for production when three conditions are all true: the process it replaces is already documented and repeatable, the decision volume is high enough to justify the build cost, and structured or semi-structured historical data already exists to build against.

All three of our agents met all three conditions before we started. The contact centre client already had a written quality rubric. The manufacturing client had 6 years of job records, even if they were messy. Messy but existing data is a very different starting point from no data at all.

An AI agent is not ready for production when the process changes week to week with no fixed rubric, when decision volume is too low to justify months of integration work, or when the judgment involved is genuinely one-off rather than a pattern repeated hundreds of times.

We turn down more agent projects than we take on for exactly this reason. If a client's process fails any of the three conditions above, the honest answer is to fix the process first. Our AI agents work and broader AI software development engagements both start with this same check before a single line of code gets written.

A process with high judgment variance is not automatically disqualified — but it needs to be narrowed first. The manufacturing client's original ask was to estimate every job type in the shop. What actually shipped covers roughly 70% of job types, the ones with enough historical precedent to support a confident estimate. The other 30% stayed with the senior estimator, and that split was a design decision, not a limitation we ran into by accident.

None of these three agents shipped correctly on the first attempt. Each went through a phase where we rebuilt the core mechanism after the first version did not hold up under real usage. That rebuild is normal, and the cost and timeline ranges above already account for it.