"We Rolled Agents Out to 400 Reps": An Operations Lead on What Actually Broke

The 400-Rep AI Agent Rollout That Almost Failed

Six weeks into a six-month AI agent rollout, the operations lead at a 900-person B2B software company pulled up the usage dashboard and saw a problem no launch plan had prepared her for. Of the 400 sales reps who had been given access to the new agent platform, roughly 60 were using it on any given day. A hundred more had tried it once and abandoned it. The remaining 240 had logged in, clicked around, and quietly gone back to their old workflow.

The model was working fine. The prompts were good. The vendor's demos had been flawless.

Everything else was on fire.

This is the story of that rollout, told through a practitioner interview with the operations lead who owned it. We're calling her Dana R. — she asked that her company not be named, but she was direct about the numbers, the failures, and the rebuild. What follows is not a vendor success story. It's an honest account of what breaks when you put AI agents in front of a large sales org, and what a second attempt actually looked like.

If you're planning an enterprise AI agent rollout in 2026, this is a version of the story worth hearing before you sign the contract.

The Setup: 400 Reps, One Agent Platform, Six Months

The company sells mid-market SaaS with an average deal size in the low five figures. Before the rollout, the sales org ran on a standard stack: Salesforce as the system of record, Outreach for sequencing, Gong for call intelligence, and a patchwork of spreadsheets and Slack threads filling the gaps.

The problem wasn't a lack of tools. It was the manual glue work between them — the triage of inbound leads that sat in a queue overnight, the CRM fields that went stale within days of a deal closing, the follow-up drafts that reps wrote from scratch every single time.

Dana's team scoped three agent use cases for phase one:

Inbound triage — an agent that scored and routed inbound leads based on firmographic fit, prior engagement, and territory rules, then drafted a first-touch email for the assigned rep.
CRM hygiene — an agent that flagged stale records, proposed field updates based on recent activity, and surfaced accounts with missing ownership.
Follow-up drafting — an agent that pulled from call transcripts and email threads to draft post-meeting follow-ups for rep review.

Success criteria were set upfront: 70% weekly active usage by month three (defined as a rep triggering at least one agent action in a given week, measured against eligible seats), a 15% reduction in time-to-first-touch on inbound, and a measurable improvement in CRM completeness. Ownership sat with Dana's ops team, with an engineering partner handling integration and a sales enablement lead handling training.

On paper, it was a clean plan. In practice, three assumptions were wrong from the start.

What Broke First (Spoiler: Not the Model)

Here's the finding that recurs across enterprise rollouts, and it's the one worth internalizing: the LLM performed within spec on nearly every task it was given. The failures were almost entirely in the layers around it.

The team knew this because they had measured it. Before launch they built a small offline eval harness: a golden set of roughly 500 historical inbound leads with human-labeled routing decisions, plus 200 past follow-up threads with rep-approved drafts. On that set, routing precision was high — the agent agreed with the human label on the large majority of leads — and on follow-up drafts, reps rated the output "good enough to send with light edits" on roughly four in five samples in an internal review (a small, single-team rating, not a benchmark). The model was not the problem.

The problem was that the agent was reading from systems that had been quietly decaying for years, and it was operating inside a permissions architecture that had never been designed for machine actors.

The Data Layer Was the Real Blocker

Dana's team ran the inbound triage agent against a backfill of 90 days of historical leads. In the demo environment, it performed beautifully. In production, it started confidently routing leads to account owners who had left the company eight months earlier.

The CRM had never been cleaned. Ownership records were stale, territory assignments hadn't been updated after a mid-year reorg, and 14% of active accounts had no assigned owner at all. The agent wasn't inventing owners — it was faithfully reading a system of record that had been lying to humans for years, and humans had learned to work around it.

The distinction matters. The failures Dana's team traced were grounding and data-integrity failures, not model-quality failures — but they're adjacent, and the line is thin: when retrieval returns stale, partial, or empty results, a capable model will often fill the gap with a confident-sounding guess. That's a hallucination, and it's triggered by bad data, not bad weights. Treating "the model is fine" as a reason to skip data work is how you get both problems at once.

"The agent didn't create the data debt," Dana said. "It just made it visible and expensive all at once. Reps had been mentally correcting for bad data for so long they'd stopped noticing it."

The team spent three weeks on a data remediation sprint that had been on the roadmap since 2023. That sprint should have happened before the rollout, not during it. (See: how to audit your CRM data before an AI agent deployment.)

Permissions Broke Before Prompts Did

Week one, the SSO integration mapped roles incorrectly. Sales development reps could see enterprise account records they had no business seeing. This was an identity and authorization failure — the role-mapping model between the identity provider and the agent's tool layer was wrong.

A week later, after a rushed fix, the opposite failure: agents silently returned empty results on restricted accounts, and reps got blank outputs with no error message. This one is a different bug entirely — a retrieval-level access-control failure. The agent's document and record retrieval wasn't enforcing row-level ACLs correctly, and when access was denied it returned "nothing found" instead of "access denied." To a rep, those two states are indistinguishable, and the second one teaches them the tool is unreliable.

The fix required treating permissions as agent infrastructure, not SSO plumbing: record-level access control enforced at retrieval time, and explicit "no-result" signaling so that silence is never mistaken for "nothing to report." Most agent stacks don't ship this by default.

Both failures eroded trust fast. The first created a compliance scare. The second created a quieter, more damaging problem — reps stopped believing the agent's outputs were complete.

Dana's framing is worth internalizing: "Permissions are the part of agent infrastructure that nobody puts in the demo. But in an enterprise, your agent is only as useful as the access-control model underneath it. If that's wrong, everything downstream is wrong, and it fails in ways that look like model failures but aren't."

"We spent six weeks debugging what we thought were prompt problems. Every single one traced back to permissions or data. Not one was actually a model quality issue." — Dana R., operations lead

For a deeper look at the infrastructure layer most teams skip, see our guide to agent permissions and identity architecture for enterprise AI.

Change Management Was an Engineering Problem

This is the thesis Dana came back to repeatedly, and it's the most transferable lesson from the rollout.

Her team had treated change management as a communications problem — a launch email, a training deck, a Slack channel, a weekly office-hours call. What they actually had was an adoption engineering problem: reps didn't abandon the agent because they didn't understand it. They abandoned it because it wasn't wired into the moments where they actually did work.

The sixty daily users were the ones who had built their own habits around it — a rep who checked triage output first thing in the morning, a rep who ran follow-up drafting before every call. Everyone else had no trigger, no prompt, no place in their day where the agent showed up unbidden and useful. The tool was available; it was not embedded.

The rebuild changed three things:

It moved the agent into the existing workflow instead of beside it. Triage output landed where reps already looked for new leads, not in a separate dashboard they had to remember to open.
It made the first interaction succeed. New users were routed to a single, high-confidence task — drafting a follow-up from a transcript they'd just recorded — rather than a menu of capabilities. First-session success rate became a tracked metric.
It gave reps a way to report bad output in one click, which doubled as the team's production eval signal. Every "this was wrong" was logged, triaged, and fed back into the golden set.

By the end of month five, weekly active usage had climbed from roughly 40% of eligible seats to the mid-60s — short of the original 70% target, but climbing, and concentrated in the use cases where the data and permissions work had landed. Dana's read: the target was achievable, but the original timeline assumed adoption was a communications event rather than a series of engineering fixes to the workflow itself.

What a Second Attempt Actually Looked Like

If Dana were starting over, the sequence would invert. Not model selection first, then integration, then change management — but data and permissions first, then a narrow, embedded use case, then expansion.

The concrete playbook she'd hand to another ops lead:

Audit the system of record before you touch the agent. Ownership completeness, territory freshness, and stale-record rates are the leading indicators of whether your agent will embarrass you in week one.
Model access control at the record level, and make denial loud. SSO role mapping is necessary and insufficient. Test the "restricted account" path explicitly, and require the agent to distinguish "no result" from "no access."
Build the eval set before launch, and keep it live. A golden set of labeled historical cases is your only defense against mistaking data failures for model failures — and your only way to prove the model is fine when everything else isn't.
Embed one use case where the work already happens. Adoption follows the workflow, not the training deck. Pick the task with the shortest path from output to action.
Instrument first-session success and one-click feedback. These are your production eval and your adoption leading indicator in the same signal.

The model was never the hard part. The hard part was everything the model inherited.

Dana R. is an operations lead at a 900-person B2B software company. Company and identifying details have been withheld at her request. Metrics are self-reported and reflect a single rollout.