At VB Transform 2026, Intuit's VP of AI revealed something most enterprise AI teams would never admit publicly: they scrapped their production agent architecture not once, but twice — in a span of four months. And her take? She called it "the fast path."
That framing alone should stop every CTO and CFO mid-scroll. Because if one of the most sophisticated enterprise software companies in the world — with $18.8 billion in annual revenue, decades of fintech infrastructure, and a dedicated AI team — rebuilt their agent stack twice, you need to understand exactly why. The lessons aren't abstract. They are the difference between an AI investment that compounds and one that collapses under its own weight.
This is what Nhung Ho, Intuit's VP of AI, shared at VB Transform 2026. It is the most honest, data-grounded account of enterprise AI agent failure and recovery I've seen this year.
The First Architecture: Specialist Agents That Worked — Until They Didn't
Intuit started where most enterprises start: with specialist agents. Build a capable agent for tax questions. Build another for bookkeeping. Another for payroll. The logic is straightforward — specialized agents perform better on narrow tasks than generalist models trying to do everything.
And they were right. The specialist agents worked.
But then came a problem that had nothing to do with the agents themselves. Customers using Intuit's platform had to decide which agent to use for which task. That cognitive burden — essentially outsourcing the orchestration problem to the end user — was killing the experience.
The solution seemed obvious: add an orchestration layer. Build a central router that could take a customer's request and direct it to the right specialist automatically. The customer asks one question. The orchestrator decides who handles it. Clean, scalable, logical.
This orchestration layer held up for about three months. Ho described that timeline, with characteristic candor, as "roughly a year in compressed 2026 agent time." What she meant: the field is moving so fast that three months of stable production use qualifies as a meaningful track record.
Then the architecture broke.
The Failure Mode No One Talks About: Error Compounding
The way it broke matters more than the fact that it broke. This is where the lesson gets specific — and where most enterprise AI post-mortems stay vague.
The orchestrated system passed results between agents in natural language. Agent A completed its task and summarized the outcome in plain text. Agent B received that summary and used it as context for its own task. Agent C received Agent B's summary. And so on.
The problem: every handoff in natural language required the receiving agent to infer what the upstream agent had concluded and why. That inference is never perfect. And in a chain of ten agents, imperfect inferences compound.
"If you have 10 agents and they all are passing to each other, every time that pass happens, error compounds," Ho said at VB Transform.
This isn't a capacity problem or a model capability problem. It's a structural problem built into the architecture itself. A ten-agent chain does not fail occasionally — it degrades by design. The orchestration layer that was supposed to simplify the customer experience was systematically eroding the quality of the output.
That diagnosis, once confirmed, made the decision inevitable: they had to rebuild.
The 60-Day Rebuild: Skills and Tools Architecture
The second architecture replaced orchestration with a skills-and-tools model. Instead of passing results between agents in natural language, individual capabilities were broken into discrete, reusable skills and tools. The agent runtime could call these tools directly, with structured inputs and outputs — no natural language inference required between steps.
Think of it as the difference between a game of telephone and a shared database. The telephone version loses signal with every pass. The shared database version preserves fidelity regardless of how many components access it.
The full rebuild took 60 days. A first working version was running in under 20.
That timeline tells you something important about how teams should plan AI architecture investments. The first working version at 20 days represents the minimum viable architecture — enough to validate the approach and demonstrate correctness on real customer queries. The remaining 40 days was hardening, testing at scale, and transition.
For enterprise planning purposes: a major AI architecture rebuild, when scoped correctly and driven by a clear diagnosis, can be accomplished in under 90 days. That is not a reason to rush. It is a reason to invest in diagnosis before you design.
The Harder Problem: Getting Engineering Buy-In
Nhung Ho was clear that the architectural decision was not the hardest part of the rebuild. The harder problem was internal: convincing both leadership and the engineers who had built the original system that scrapping recent work was the right call.
This is an underappreciated dimension of enterprise AI investment. Technical debt in AI systems is not just code — it's human capital. Hundreds of engineers outside Ho's core team had built the specialist agents that were being retired. The ask was to dismantle their work and rebuild it as shared skills and tools. That is a significant organizational ask.
The pitch to leadership relied on evidence, not argument. Ho's team built a demonstration using real customer queries pulled from production data, then showed the new architecture outperforming the existing system on identical tasks. No theoretical claims. No benchmarks on synthetic data. Real customers, real problems, real comparative results.
"The best proof, at least my belief, is what are customers trying to do? And whatever system you build needs to address those problems," Ho said.
The pitch to engineering required a different approach. The motivating argument was scale. A standalone specialist agent solved one narrow problem for one category of customer. A shared skill or tool, built into the new architecture, could serve every customer across the entire product surface. The scope of impact multiplied by an order of magnitude.
That shift also changed what partner engineering teams were responsible for day-to-day. Their focus moved from building and maintaining agents to running evaluations — because evals became the only reliable way to measure whether the new architecture was actually working.
This is a management model worth noting: in a skills-and-tools architecture, eval ownership is the primary engineering accountability. Not shipping features. Not maintaining agents. Running continuous evaluations against real production queries.
What CFOs Need to Understand About AI Architecture Costs
The business case for rebuilding is harder to make than it looks, because the costs of not rebuilding are mostly invisible.
Consider what the orchestration failure was actually costing Intuit. Customer queries routed through a ten-agent chain were systematically producing degraded outputs. Some percentage of customers were getting wrong answers, incomplete guidance, or confusing results. That drives support volume, reduces product trust, and ultimately threatens renewal rates — especially for a product that handles people's finances and taxes.
None of those costs show up on the AI infrastructure line of a budget. They show up in customer satisfaction scores, support ticket volume, and churn. By the time the finance team can attribute them to the AI architecture, the architecture has already done significant damage.
The CFO-level framing for AI architecture rebuilds is straightforward: technical debt in AI systems has a direct path to revenue leakage. The question is not "can we afford to rebuild?" It is "how much is the current architecture costing us in lost customer trust, and how long are we willing to absorb that?"
For Intuit, the answer was about three months of orchestration stability before the compounding error problem became undeniable. That is a relatively fast failure — which is actually a good outcome. The teams that should worry are the ones whose orchestration failures are slow and diffuse, degrading output quality gradually in ways that never trigger a clear red line.
The Feedback Revolution: Why agentic AI Changes Everything
One of the most consequential side effects of Intuit's rebuild was what happened to their feedback loop.
In a traditional software product, explicit customer feedback is rare. Maybe 0.3% of customers leave a rating or a comment. The feedback is sparse, bimodal (loved it or hated it), and usually skews negative.
In a chat-based agentic system, every conversation is feedback. The customer describes their problem, the agent responds, and the customer's next message tells you exactly whether the agent got it right. That is not a 0.3% signal — it is approaching 100% signal density.
"Feedback in the past used to be very, very sparse, and it was also very bimodal," Ho said. "Either they loved it or they hated it, and usually it tends towards the negative."
With the new architecture, Intuit went from 0.3% explicit feedback to near-total feedback coverage across every customer interaction. The volume is so high that Ho said she has returned to writing code herself — specifically to build models that can analyze feedback at a scale no manual review process could handle.
The tone is also different. Customers tell the agent exactly where it failed. In plain language. Without diplomatic softening.
"They straight up tell you, 'You suck. I hate this. This is not right,'" Ho said. "But they're also willing to give the systems grace and correct it as well."
That combination — unfiltered criticism plus customer willingness to correct and continue — is an extraordinary feedback mechanism for any enterprise product. The teams that build processes to systematically harvest and act on this feedback will compound their model quality over time. The teams that treat it as noise will fall behind.
Human in the Loop: The Trust Architecture
The rebuild also enabled a capability that Intuit is now testing with approximately 1% of its customer base: the ability for a customer to pull a human expert into an agent conversation mid-stream.
The human — whether an Intuit bookkeeper, a product support specialist, or the customer's own accountant — joins with full context of everything the agent has already done. No re-explaining. No starting over. The conversation continues with the human added as a participant.
Ho drew a direct contrast with how most AI chat products handle this transition. A general-purpose assistant answering a tax question typically ends with "consult a professional." Intuit's architecture is built to connect the customer to that professional directly, inside the same conversation, without breaking the thread.
This is the trust architecture that enterprise AI products need to build for high-stakes domains — finance, legal, healthcare, compliance. Not "here is the AI's answer, please verify with a human." But "here is a conversation between you, the AI, and the human expert, with full shared context." That is a fundamentally different product experience.
Intuit backs this with explicit permissions: every action the agent takes on a customer's financial data requires explicit customer authorization. An audit log captures every agent action. Permissions can ease over time as the customer builds trust in the system. But the default is consent-first, audit-always.
The OpenAI Signal: "Useful Work Per Dollar"
This week, OpenAI also published a framework for enterprise AI investment management — timed, not coincidentally, as enterprises increasingly grapple with AI spend that is growing faster than demonstrable ROI.
The central concept: stop measuring AI investment by token price. Start measuring by useful work per dollar — tasks completed, time saved, decisions improved, workflows ready to scale.
The framework also introduces "cost per accepted outcome" as the right unit of analysis for specific workflows. In customer support, that might be a resolved case. In engineering, a tested code change that passes review. The point is to tie AI spend to business outcomes that the organization already knows how to value.
Intuit's rebuild is a perfect illustration of why this framing matters. The orchestration architecture was not failing on token price. It was failing on useful work per dollar — because compounding errors across agent chains were reducing the percentage of queries that resulted in a genuinely useful customer outcome.
The teams that measure AI success by API costs will miss this entirely. The teams that measure by outcome quality will catch it, and act.
What to Do Before You Scale
If your organization is building or scaling AI agent systems, the Intuit case offers a practical pre-flight checklist:
1. Validate your inter-agent handoff model before you scale. If agents are passing results in natural language, test a ten-hop chain and measure output quality degradation at each hop. If quality degrades, you have found your architectural limit before it finds you in production.
2. Define "useful work per dollar" for your highest-priority workflows. Not token cost. Not completion rate. Cost per outcome that your business already knows how to value.
3. Treat eval ownership as a first-class engineering accountability. In a skills-and-tools architecture, the teams maintaining individual capabilities need to own continuous evaluation against real production queries — not synthetic benchmarks.
4. Build your trust architecture before you build your capability architecture. Permissions, audit logs, human-in-the-loop escalation paths, and consent flows should be designed alongside agent capabilities, not retrofitted afterward.
5. Plan your feedback infrastructure. Agentic systems generate near-100% feedback signal. The organizations that build systematic processes to analyze and act on that signal will compound their model quality faster than organizations that don't.
6. Brief leadership and engineering separately. The Intuit case makes clear that evidence-based demos beat theoretical arguments for leadership buy-in. And scale of impact — not preservation of prior work — is what wins engineering support for architectural transitions.
The Bottom Line
Intuit rebuilt its AI agent architecture twice in four months. The first rebuild solved a customer experience problem. The second solved a structural error-compounding problem that the first rebuild inadvertently created.
The VP of AI who led both rebuilds called the combined process "the fast path." Not because it was easy. But because moving fast on the right diagnosis — rather than slow on the wrong architecture — is how enterprise AI investments produce durable returns.
The lesson for technical leaders: test your inter-agent handoffs before you scale them. The lesson for business leaders: budget for the rebuild. Not as a sign of failure, but as a sign that your teams are diagnosing honestly and moving decisively.
The enterprises that will lead in the agentic era are not the ones that get the architecture right on the first try. They are the ones that get the diagnosis right quickly — and act on it without waiting for the failure to become undeniable.
Intuit is showing what that looks like in practice.
Sources: VentureBeat, VB Transform 2026; OpenAI Blog, July 2026
