Intuit overhauls AI agents to fix compounding errors with new architecture
At VB Transform 2026, Intuit VP of AI Nhung Ho described a compounding-error problem that pushed Intuit to rebuild its agent architecture twice in about four months: agents passing results to each other in natural language, with each handoff losing context the next agent needed to act on. "If you have 10 agents and they all are passing to each other, every time that pass happens, error compounds," she said.
The first architecture was a fleet of specialist agents. Customers could solve any one problem well, but they still had to pick which agent to use, which became its own complaint. The replacement was a central orchestration layer that routed tasks internally so customers did not have to choose. That layer ran for about three months before its structural flaw surfaced. Ho put the elapsed time at roughly a year in agent-development time in 2026.
The compounding problem is not specific to Intuit. In any chain where downstream agents must infer how upstream agents reached a conclusion, the inference cost grows with hop count and the conversion fidelity of each hop is multiplicative rather than additive. Intuit's diagnosis points to a broader design constraint in multi-agent systems: natural-language handoffs degrade predictably, while structured handoffs require schemas the systems may not share. The architectural move Intuit made, from orchestration to skills and tools, addresses the compounding problem at the cost of giving up whatever routing flexibility the orchestrator enabled. That tradeoff is not benchmarked in the source. Ho framed the rewrite as structural, not as a performance comparison.
The full second rebuild took 60 days, with a first working version in under 20. Ho said the harder problem was internal, convincing leadership and the engineers who had built the original agents that scrapping recent work was the right call. The leadership pitch relied on a demo built from real customer queries, shown outperforming the existing system on the same tasks. The engineering pitch leaned on scale: a specialist agent solved one narrow problem, while a shared skill embedded in the new architecture could serve every customer who touched that part of the product.
The shift also rerouted what partner teams owned day to day. Building agents gave way to running evaluations, since evals became the only way Ho's team could measure whether the new architecture actually worked. That is a real change in operating model. It moves accountability from shipping features to proving they hold up under measurement, and it implies that any team whose work could previously be signed off by shipping is now accountable to a continuous evaluation surface. The source does not characterize the headcount impact; it describes the change in role, not in team size.
The most visible customer-facing result of the rebuild is a human-handoff feature currently live to about 1% of Intuit's customer base, with broader rollout described as imminent. A customer can pull a human, an Intuit support person, the customer's own accountant, or one of Intuit's bookkeepers, into the live agent conversation, with the human joining carrying the full context of what the agent has already done. Ho drew an explicit contrast with generic assistants that end a tax answer with a disclaimer to consult a professional; Intuit's framing is that the system connects the customer to that professional directly, inside the same conversation. The architecture underlying this requires a permissions model built for financial data, where every agent action on customer financial information requires explicit permission, with an audit log of each action that can be reversed if needed. Ho said the requirement can relax as customers build trust in the system, though the source does not specify what conditions would trigger that relaxation.
The feedback loop is the second non-obvious shift. Ho said feedback in earlier product surfaces was sparse and bimodal, with explicit feedback coming from roughly 0.3% of customers. In an agentic chat, every conversation is feedback, and the rate of customers implicitly telling the system where it failed moved close to 100%. The tone is harsh and direct: customers write "you suck" when the system is wrong, and they correct it when it is partially right. Ho has returned to writing code herself to build models that analyze that feedback volume systematically, looking for failure patterns at a scale no manual review could keep up with.
That mechanism also enables the feedback loop Ho described. Failures become measurable in real time, and addressing them shifts onto a cadence governed by eval results rather than release cycles. Whether that holds at Intuit's actual customer volume, and whether the 60-day rebuild itself can repeat routinely rather than as a one-time response, is the question the source does not test.