Powering the Future: Building Your GenAI Infrastructure Stack

Merrin Kurian's thesis is that the hard part of putting AI agents into production is not the agent code. It is everything around the agent code: evaluation, observability, guardrails, prompt lifecycle, model hosting, and the organisational agreements that stop thousands of engineers from solving the same problem, in her words, "in 100 different ways". Her talk is a report from inside Intuit's two-and-a-half-year build of GenOS, short for Generative AI Operating System, the internal platform that she says "helps scale and accelerate all these AI-powered experiences across our products". By her reported numbers, 1,300 of Intuit's 8,000 developers build on it.

Kurian is a Distinguished Engineer at Intuit leading AI Foundation capabilities across classic ML, generative AI, and agentic experiences; she previously led platform engineering for QuickBooks. She gave this 50-minute, 39-second talk at QCon San Francisco; InfoQ published the recording on May 19, 2026.

These notes report what Kurian presented. Where I add background an intermediate engineer needs but the talk did not state, the paragraph says so explicitly. Intuit is a large, heavily regulated financial-services company with a dedicated central platform organisation, so several of these decisions are correct because of that context rather than universally correct — the notes flag those cases.

What You Will Learn

• The practical difference between a workflow and an agent, and the specific signal that tells you which one your problem needs.
• Why LLM-based applications break the testing assumptions that make traditional applications tractable, and what replaces them.
• The catalogue of multi-agent failure modes Kurian says every agent builder must now plan for, and why final-output testing cannot detect most of them.
• How trajectory evaluation and LLM-as-a-judge work, plus the ground-truth problem that limits both.
• What sits inside a mature internal GenAI platform: prompt registry, tool registry, agent registry, RAG pipeline, guardrails, and end-to-end tracing.
• Why Intuit replaced millions of per-customer personalised models with a handful of fine-tuned LLMs, and what that bought them.
• The "fixed, flexible, free" governance model for platform technology choices, and the centralisation trade-offs it manages.
• Four investments — tool-ready APIs, data metadata, multimodal UX, and latency-tolerant infrastructure — that pay off even if you ship no agents this year.

The Business Context, and Why the Numbers Matter

Kurian opens with scale figures, and they are worth keeping in mind because they explain why Intuit's answers are as heavyweight as they are. Intuit serves roughly 100 million consumer, small-business, and mid-market customers. Its ML platform generates 60 billion machine learning predictions per day. It holds around 625,000 attributes per small business and close to 70,000 attributes per consumer that it has permission to use for personalisation. On the business side, the platform processes close to $2 trillion of invoices, pays 18 million US workers through payroll, and handles about $100 billion of tax refunds.

The agent programme sits under a company bet Intuit calls done-for-you experiences. Kurian's reported outcomes: 80% repeat engagement across the QuickBooks family of AI agents; an accounting agent saving customers 12 hours per month; tax products saving 1.7 million hours of data entry per year; a payments agent getting invoices paid five days faster on average; and self-help answering 110 million questions per year, which she describes as an order of magnitude above previous years. These are company-reported product metrics, not independently audited results — but they establish that these agents are in front of real customers at volume.

Two agents illustrate what "done-for-you" means concretely. The payments agent scans the email thread between a business and its customer, understands the conversation, reads the attachments, and drafts an invoice; the business owner only reviews and sends. The finance agent compares your data against industry peers — in her demo, a retail business asks about its net profit margin, and the agent reports that margins are low and attributes it to material and labour costs. In her narration the diligent business owner has "found some supplier list" and asks the agent, given that list, what to do next; the agent recommends specific suppliers to cut material cost, reasoning over supplier pricing and the factors it identified as squeezing the margin. Kurian is explicit that Intuit's design position is that AI must be augmented with human intelligence: a human expert is always available to consult.

Workflow or Agent? The Decision Before the Architecture

Kurian credits Anthropic for these definitions and recommends their material as a starting point.

A workflow is a predefined set of code paths — a fixed sequence of steps executed in a known order. Its value is predictability for complex tasks and consistency for well-defined ones. An agent is where decisions are made by the model rather than by you: it operates on the context it has at that moment and the tools at its disposal, and it decides what to do. Its value is flexibility when you do not have a predefined set of steps, and — importantly — when you do not even know how many steps there will be.

That last clause is the sharpest decision criterion in the talk. If you can enumerate the steps, you want a workflow. If the step count is a function of the input, you want an agent. Kurian adds an empirical observation from Intuit: agents work best with unstructured data — text, documents, images, audio, speech — which is exactly the data that resists the fixed schema a workflow needs.

The trade-off is cost and latency. Getting accurate agent behaviour often means asking the model to consider multiple options, or to think harder and longer. All of that consumes more tokens, costs more money, and adds latency. Kurian's framing: if you want a snappy response and you want the agent to reason, that is the trade-off you have to make. There is no configuration that gives you both.

She also uses Google's four-component decomposition of an agent, which is a useful mental checklist when you are reviewing someone's agent design:

Two Generations of Agents, and What Actually Changed

Intuit's first-generation agents were what Kurian calls conversational assistants: chat interfaces that answered questions and fetched data. The current generation takes actions on the customer's behalf. The interesting part of the talk is her account of why the second generation became feasible, because it doubles as a map of what capabilities to depend on today.

When Intuit started in 2023, the constraints were brutal. There was a GPU shortage and LLM capacity was rationed. The model context window was at most 4,000 tokens, which meant retrieval-augmented generation was not an optimisation but the only way to get any domain knowledge into the model at all. Intuit built its own framework for multi-turn chat with a centralised planner and subagents that could ask follow-up questions, plus the memory orchestration, continuous troubleshooting, and evaluation machinery around it. Kurian's summary is that the vision was bold and the technology landscape was not there.

Supplementary context, not from the talk: RAG means embedding your documents into a vector index, retrieving the chunks most similar to the user's query, and pasting only those chunks into the prompt. With a 4,000-token budget shared between instructions, retrieved context, conversation history, and the answer, almost every architectural decision becomes a fight for space — which is why Kurian's team ended up building so much custom orchestration.

Five things changed, and each one deleted code:

• Function calling. Once models could call functions natively, they could do query decomposition and planning directly. Kurian says teams have repeatedly told her that a lot of code can now be deleted because these functions folded into the LLM APIs themselves — you can split an incoming request across subagents without building the splitter yourself.
• Structured output. Guaranteed-shape responses are what make it possible to chain multiple LLM actions together reliably, because step n+1 can parse the output of step n.
• Multimodality. Reasoning extended from text to images, documents, audio, and video.
• Model families instead of one model. Kurian describes the resulting pattern directly: a superior reasoning model for planning, a workhorse model for tool selection, and a lightweight, fast, cheap model for natural-language tasks such as summarisation. Matching model tier to task is now a first-order cost and latency lever.
• Frameworks and protocols matured. She notes, with some disbelief, that they once ran LangChain "version 0030-something" — an early 0.0.x release — in production: "I had never seen something put in production with a version number 0.0.something, but that's all we had." Today's frameworks span fully declarative to full control over graph execution, and they solve state management, checkpointing, and multi-agent coordination out of the box. Agent communication protocols are converging on at least rough consensus for agent-to-tool and agent-to-agent interaction — problems Intuit previously had to solve by getting everyone in the company into a room to define internal standards for every interaction.

Her conclusion for anyone starting now: you will not have to struggle as much as they did.

The Standards Strategy

Intuit's stated policy is to adopt standards as they mature, on the explicit assumption that they will not solve every problem themselves and stick with their own answer forever. The first standard they adopted was the OpenAI chat completion API, chosen because every agent framework supported it — by making their internal APIs compatible with it, every framework immediately became available to Intuit's agent developers without further integration work. Reaching that point took two years and three versions of their API.

The generalisable insight is that picking a widely supported interface as your internal contract converts an integration problem into a compatibility problem. Kurian's aside is candid: sometimes if you wait six months, things sort themselves out and you do not have to try so hard. Until standards settle, they keep shipping deliberately experimental solutions so the organisation keeps learning.

Why LLM Applications Break Your Testing Assumptions

Kurian draws a sharp contrast between traditional and LLM-based applications, and this section is the conceptual hinge of the talk.

Her line about traditional applications is worth keeping: compared to a simple LLM-based application, race conditions "feel like a cakewalk."

The consequence that matters operationally is the last row. You cannot set a breakpoint inside a model's reasoning, and because the model is general purpose, you genuinely do not know in advance what it will do. That is why the rest of the talk is largely about evaluation and observability rather than about code.

The Multi-Agent Failure Modes

Kurian presents a catalogue of multi-agent failure modes, noting that this is now well-researched and documented, and that although you would not normally do formal failure mode analysis for a small application, agent systems have forced exactly that. The modes she lists:

• Obeying or disobeying the task specification.
• Forgetting their role in the system.
• Repeating steps even after the task has been processed.
• Forgetting what happened previously in the interaction.
• Failing to terminate — continuing a conversation that should have ended.
• Failing to ask clarifying questions when the request is ambiguous.
• Drifting from the original objective.
• Withholding information from a subagent.
• Ignoring input from a supervisor agent.
• Stopping early, before the task is complete.
• Verifying incorrectly — running a validation step that passes when it should not.

Her point is that none of these are exotic. They are the normal operating behaviour of composed model-driven systems, and it is now the engineer's job to know them and design against them.

Why Final-Output Testing Is Not Enough

Kurian's worked example is the clearest thing in the talk. She wanted to book a trip to San Francisco; the agent booked a trip to San Diego. If your only test asserts on the final output, all you learn is it failed. You have no idea what to do next.

Decomposed, the run has at least five independent failure points:

1. Tool selection — it had to determine which tool to call, and it called the wrong one.
2. Tool arguments — it had to call a search API, and it passed the wrong arguments or wrong values.
3. Retrieval — it had to use RAG, and either used it incorrectly or supplied the wrong context.
4. Response quality — the tone of the reply may have been inappropriate.
5. Overall correctness — the trip is booked to the wrong city.

The cost of the failure is not just a wrong booking: it is an unhappy customer, a large number of tokens spent, and wasted resources. Kurian's framing is that this is what an agent looks like when you do not know what you are doing.

Trajectory Evaluation and LLM-as-a-Judge

The answer, she says, is what AI science teams have always done: systematic, structured evaluations. Software engineers moving into AI development are learning a practice that already exists.

The mechanism is trajectory evaluation. Instead of scoring only the final response, you capture the full trace of decisions the LLM made, then evaluate each decision point against the right ground truth. Applied to the San Diego example, that means separately scoring "did it pick the right tool", "were the arguments right", "was the retrieved context right", and "was the tone right" — each of which is individually actionable in a way that "the booking was wrong" is not.

To scale beyond human review, the technique is LLM-as-a-judge: use a model to score each decision point. Kurian's caveat is immediate and important — it all depends on the judge's quality. Does the judge know, as a human would, how to make the right judgement? And the objectivity of the ground truth itself is a huge challenge if you are not the domain expert. An LLM judge does not remove the need for domain expertise; it amortises it.

Her final point on evaluation is the one most teams get wrong: evaluations are not fixed in time. Behaviour you never observed in your first runs will appear in production as an emergent behaviour, or customer needs will change and shift what "correct" means. Eval datasets must be continuously updated, and the regression suite along with them. This is the biggest challenge of working with LLMs, in her words: unlike a unit test, passing once does not mean passing forever.

GenOS: The Platform

GenOS is Intuit's answer to all of the above. Its top-level components are the AI Workbench (the development environment), GenRuntime (the runtime), GenUX (the user-experience layer), the hosted large language models, and a responsibility and governance process wrapping the whole thing — Kurian is explicit that whatever they could not solve with technology, they augmented with process.

The stated motivations are worth separating, because they are different arguments:

• Velocity through abstraction. Teams should not be bogged down by compliance, data handling, and security. Push those into the platform.
• Avoiding divergence. They did not want a hundred different solutions to the same problem across the company.
• Nothing off the shelf fits. Both in 2023 and today, Kurian says there is no enterprise-grade end-to-end AI platform that solves for the kind of businesses Intuit is in. She states the decision rule plainly in her conclusion: they build what is not available off the shelf because they have to meet the regulatory standards, they look outside to see whether external options meet those same standards, and it is "always a constant evaluation of what meets our bar". The regulatory bar, not cost or convenience, is the build-versus-buy criterion.
• Unify rather than restart. They did not build from scratch. Intuit had invested in data and AI platforms for a long time; the goal was to unify what already worked and enhance it — her example is authorisation, where the existing identity system was extended to work for agents rather than replaced.
• Centralised keeping-up. A central team tracks the rapidly evolving landscape so that 8,000 engineers do not each have to.

What GenOS solves for: responsible AI development, secure private access to LLMs, out-of-the-box guardrails for security, safety, privacy and compliance, and rapid experimentation at scale through correct data handling plus end-to-end observability and analytics via instrumentation. Critically, it is extensible: product teams plug their domain capabilities and knowledge systems into GenRuntime, and guardrails and evaluation metrics can be extended by use-case teams, so the platform gets richer as more teams onboard.

Architecture and Data Flow

The GenOS architecture diagram uses a colour convention worth stating because it encodes the build strategy: green is what the platform team built, sitting on top of grey pre-existing Intuit infrastructure, while blue is what product teams build — their own agents and the domain capabilities they contribute back.

flowchart TD
  subgraph DEV["AI Workbench (development)"]
    W1["Prompt management,
evaluation, optimization"]
    W2["RAG pipeline:
chunk, embed, index"]
    W3["Labeling, eval frameworks,
tracing, guardrail testing"]
    W4["Agent Starter Kit
CI/CD, starter code, patterns"]
  end
  subgraph REG["Registries"]
    R1["Prompt registry"]
    R2["Agent registry"]
    R3["Tool registry"]
    R4["Use case registry"]
  end
  subgraph RT["GenRuntime"]
    A1["Single-agent and
multi-agent systems
A2A, hedged by Kurian"]
    A2["Tools activated via MCP"]
    A3["LLM service:
guardrails and controls inline"]
    A4["Datastores and
RAG knowledge systems"]
  end
  UX["GenUX: widgets +
interaction management"]
  PROD["Product experience
(QuickBooks, tax, ...)"]
  OBS["Evaluation, monitoring,
tracing, logging"]
  DEV -->|"artifacts persisted"| REG
  REG -->|"activated at runtime"| RT
  A1 --> A2
  A2 --> A4
  A1 --> A3
  RT --> UX
  UX --> PROD
  PROD -->|"interaction data"| OBS
  RT -->|"traces"| OBS
  OBS -->|"eval datasets, regressions"| DEV

Read as a cycle: engineers do prompt, RAG, and evaluation work in the AI Workbench; every artefact is persisted into a registry; the registries are what the runtime activates when a request arrives; the runtime drives GenUX components embedded in the product; interaction data and runtime traces flow into the observability and evaluation layer; and that data feeds back into the Workbench as updated eval datasets. The loop closing back to development is the part that makes continuous evaluation possible rather than aspirational.

Inside the Layers

AI Workbench provides prompt management, evaluation and optimisation as self-serve pipelines; a RAG pipeline; data labelling; eval frameworks and eval tracking; end-to-end tracing; and guardrail testing. The RAG offering is deliberately turnkey: you bring your content, choose from the platform's chunking strategies and embedding models, and the pipeline indexes into the shared vector store; at retrieval time the embedding models select the right chunks and you supply your own custom prompt for the generation step. Kurian's reason for calling this out is that they do not expect every team to hand-build a RAG pipeline. The evaluation pipelines follow the same shape — define metrics, collect data, compute metrics, generate a report — and she stresses that the report is deliberately rendered in a developer-friendly and leader-friendly way rather than an AI-science-friendly way, because it is the artefact a team uses to decide when it is a good time to launch. The same pipelines then run continuously in production to monitor the application's performance after launch. The Workbench UI itself puts the tooling in one place with guided steps in the middle and metadata alongside, and Kurian makes a direct causal claim about that packaging: putting the end-to-end developer tooling in one place with self-serve onboarding and guided workflows is what accelerated the experimentation at scale.

GenUX supplies the front-end widgets that AI agents need inside product surfaces, plus interaction management that captures interaction data. That data is what later powers performance evaluation, analytics, and KPI management — the UX layer is an instrumentation layer as much as a component library.

GenRuntime hosts single-agent and multi-agent systems. On the multi-agent communication protocol Kurian hedges rather than claims: multi-agent systems, "for relative purposes, can say that they are working with A2A" — which is worth reading as directional alignment rather than a confirmed production protocol commitment. Agents are sourced from the agent registry. Tools come from the tool registry and are activated through MCP. The use case registry provides end-to-end instrumentation and automation, which is how the platform delivers observability and analytics without each team wiring it up. Domain capability teams register their APIs as tools, their data sources into the platform datastores, and their knowledge systems into the RAG system; the platform also does some context engineering on their behalf. The LLM service supports multiple modalities and interaction patterns, and — the key design decision — controls and guardrails are baked inline with the LLM APIs so they cannot be bypassed.

Supplementary context, not from the talk: MCP (Model Context Protocol) is an open protocol for exposing tools — and other context — to models through a standard interface, and A2A (agent-to-agent) is an open protocol for agents delegating to other agents. Adopting them is an instance of Kurian's "adopt standards as they mature" policy applied at the runtime layer.

The Agent Starter Kit is their most recent addition and the clearest lesson in developer experience. Intuit had all the individual capabilities, but Kurian says people found it hard to make sense of the building blocks while also reading the internet about competing agent frameworks and assembling it themselves. The Starter Kit packages everything with default configuration already pointing at the existing platform capabilities, plus starter code, multiple patterns, reference implementations, and built-in debugging, tracing, offline evaluation, registration, and integrations. The reported result: in a one-week company hackathon, 900+ downloads and 100+ demos. Nobody had to read documentation or find the right person to ask.

Prompts as First-Class Entities

Intuit treats prompts as first-class entities with their own lifecycle, and the justification is organisational rather than technical. A prompt frequently passes through a cross-functional chain: a marketing person — a non-technical author — writes the first version, a scientist optimises it, and an engineer integrates it into the application. Some of those people do not work in Git. That forces you to externalise prompts from the codebase so they can be collaborated on, governed, versioned, templated, and observed.

Kurian is honest about the limit: prompt portability is still a challenge. Moving from one LLM to another means rewriting your prompts and redoing all your previous optimisation work. That is a real switching cost to price into any multi-model or model-migration plan.

Model Hosting and the Fine-Tuning Case Study

GenOS hosts 15+ models across 70+ versions, and also does fine-tuning for task-specific use cases. Kurian is precise about why they fine-tune: to help manage accuracy, cost, and latency.

The example is QuickBooks transaction categorisation. Categorising a bank transaction into an accounting category is highly variable: a landscaping business is not categorised the same way as a real-estate business, and two accountants in the same industry may do it differently. Intuit's previous approach was to take each business's historical transactions and train a personalised model per small business. With LLMs, they could instead fine-tune on the specific context, because the base model already knows accounting, business types, and industries.

The payoff is operational, and it is the kind of result worth generalising:

The general principle: when a pretrained model already contains the domain knowledge, fine-tuning shifts you from learning the domain to learning the variation, which collapses both the data requirement and the number of artefacts you have to operate. Note this is a categorisation task with abundant labelled history — the result should not be assumed to transfer to domains the base model has not seen.

Fixed, Flexible, Free: Governing Technology Choice

Intuit applies a three-tier framework to any technology choice, and it is the most portable idea in the talk for anyone running an internal platform:

• Fixed — concerns that are standardised for every Intuit engineer. These are platform concerns nobody should have to re-solve per agent: compliance, data handling, security, identity. The platform team has an opinion and a working solution.
• Flexible — a curated set of options. Kurian stresses that flexible is "not unlimited": the platform has an opinion about which options exist, and every option is guaranteed compatible with the fixed layer.
• Free — space for experimentation outside what the platform offers. Part of what the free tier buys is an open-source posture: Kurian's stated aim is to help their community "try everything open source as much as possible", rather than confining engineers to the platform's curated selections.

The free tier exists because of a failure they had to correct. Intuit started with very stringent rules and an air-gapped experimentation environment, and it did not work — people wanted the latest and greatest, and the platform could not invest in every possible direction. Being an internal platform, they got instant feedback. They evolved to defining guardrails and enabling rapid experimentation within parameters. The upside they did not anticipate: early adopters explore something fascinating, then bring the learning back, letting the platform team make an informed decision about where to invest next.

People and Process

Asked repeatedly how many people GenOS took, Kurian's answer is "hundreds", and she is clear that the technology was the smaller half.

Leadership. The CTO decided there would be one GenOS for all of Intuit, which she describes as a novelty — normally each business unit builds its own platform capabilities. That commitment is what made the scale achievable. Leadership also established explicit decision-making and escalation processes and forums for review, which is what let them move fast in a fast-moving landscape. Multiple vice-president organisations came together under a unified mission.

Team shape. There is a persistent core team, with other teams joining the mission, delivering their piece, and leaving. The core team's job is to stay nimble and pivot quickly as technology and customer needs change.

Partnership. Processes are aligned to the capabilities so they work in unison, across legal, security, privacy, compliance, and engineering. Contributions come back the other way too — teams have contributed client libraries in programming languages the platform did not support.

Building in public, internally. This is Kurian's strongest process claim. Leadership sponsorship did not mean the team could disappear for a quarter and return with a design. Every week they presented their designs and decisions for the whole company to review. Her description is "it's like exposing yourself" — but it was necessary, because it was the only way to take feedback and adapt at the speed the landscape demanded. Her calibration on that speed is worth recording: she has been at Intuit for 17 years and saw nothing like this in her first 15, and having led transformations to AWS, public cloud, and event-driven microservices, none of them arrived as fast or as intensely as this one. She is also careful not to claim the platform team drove it alone: "it's not just our transformation. It's because Intuit as a company decided to transform that we were able to pull this off." The transformation she describes is company-wide — software engineers becoming AI engineers — and the platform's role was to lower the barrier to entry for that shift, not to cause it.

Adoption mechanics. A company-wide hackathon runs every six months, and the platform team targets releases at it, runs workshops in the week before, and shares sample apps, reference implementations, and best practices. They also bring in external industry leaders and vendor partners for tech talks and workshops, and try to influence vendor roadmaps toward what Intuit needs. For communication they have tried podcasts and short, TikTok-style videos.

What Did Not Work

Kurian lists the failures directly, which is the most useful part for anyone copying this:

• Inflexible APIs at the start. People wanted to explore the latest and greatest; rigid APIs blocked them. Fixed by adopting standards as they emerged.
• The air-gapped experimentation environment. Too restrictive; replaced with guardrailed rapid experimentation.
• A comprehensive, rigid review process. Teams spent multiple weeks in review, only to discover the customer did not like the idea and pull back. The fix was to match review depth to lifecycle stage: an early experiment needs no heavy review; something scaling out gets all of them.
• Skepticism about centralisation. The common assumption was that a central platform slows everyone down. They earned credibility over time by delivering and by offering the flexibility people asked for, converting highly opinionated customers into ones who now seek the platform team's guidance.

The reported end state: 8,000 developers at Intuit, 1,300 building on the platform, 3,500 experiments launched in production, 450,000 requests per day, and over 4 trillion tokens consumed in August alone. My reading, not Kurian's wording: "experiments in production" is not the same as shipped features — it is a measure of experimentation throughput, which is the metric she argues elsewhere in the talk that you should be maximising.

Preparing for a Future Where Agents Are Mainstream

Kurian's closing section is aimed at teams that are not building agents yet, and it is the most broadly applicable material in the talk.

Experimentation velocity is the real metric. She asked someone what the hallmark of a true AI company is, expecting an answer about model complexity or transformers. The answer was: how fast you can experiment, and how many experiments you are running in production at any time. Enabling that depends on data pipelines — well connected, continuously moving data from the product to evaluation, to offline analysis, to retraining and monitoring. Her observation is that people who have worked in AI take this for granted, while software engineers new to the field do not appreciate it, and that is where they get stuck. She ties the platform investment straight back to this: the more instrumentation you have on your agents and on their interactions with customers, and the more evaluations you have, the easier it is to iterate. Instrumentation is not reporting overhead; it is what sets your iteration speed.

"It works on my machine" has become "it works for my questions." Experiments launch, a customer asks a differently-shaped question, and the whole thing falls apart. Her prescription is to partner closely with product managers and ask them to step up: do not just write a PRD — define the evaluation metric, state what you actually care about, and supply the data to evaluate against. The engineer often cannot imagine the full scenario space; the domain expert or PM proxy provides the coverage engineering misses. Intuit backs this with training, tutorials, and repeated workshop sessions so the message sticks, and escalates to leadership when teams are not doing enough evaluation.

Then the four foundations, which she frames as things that will not change even as the technology does:

1. Tool-ready APIs. Enterprise REST and GraphQL APIs return complex JSON with multiple levels of nesting, because they were built for humans to integrate by hand. Kurian's assessment is that in their current state, LLMs are not really good at processing that. APIs need rethinking so they are tool-ready for agents to operate on, not for humans to integrate against.

2. Metadata for your data. Organisations have data lakehouses full of data, but how much metadata describes it? Without metadata, neither you nor an agent can make sense of it, and you cannot inject the right context for the agent to operate autonomously.

3. Multimodal-native user experience. Kurian's own reframing is instructive: she used to think Intuit was a financial-services company whose data is all numbers, so what use are language models? Then she realised how much of the product is asking people to fill in forms — and a form is just a mechanism for collecting information. What if the customer could instead just talk, or upload, or take a screenshot?

4. Infrastructure that tolerates a wide latency spectrum. If you are not a social media company, you may only have simple request-response APIs that all complete in around 200 milliseconds. LLMs break that assumption: small models are reasonably fast, reasoning models may take minutes, and there is everything in between. Her questions are the ones to take back to your own team — how does your infrastructure handle that? What is a "failed customer interaction" in that world? How do you define an incident? And if you now want voice everywhere, what do bidirectional WebSockets do to your architecture?

Trade-offs and Limitations

The talk's caveats fall into two groups. The limits of the approach itself are covered where each technique is introduced above: reasoning quality trades against cost and latency, LLM-as-a-judge is only as good as the judge and the ground truth, eval datasets decay and must be maintained, and prompt portability imposes a real switching cost on model migration. The remaining limitations came out under questioning, and they are the ones that most sharply calibrate what "agents in production" actually means at Intuit today.

From the Q&A

Nothing at Intuit is fully autonomous. Asked directly about the proportion of truly agentic flows versus workflows — the questioner used self-driving cars as the analogy — Kurian declined to claim autonomy. Intuit serves the whole spectrum from pure workflows with LLMs injected, to somewhat agentic. Her words: "I don't want us to say we have true agent experiences with no human intervention. We are not there yet." There is always a human-in-the-loop step today. Agents can take many actions after a human approves the proposed next steps, and the human can always cancel. This is the single most important calibration in the talk: this is what production agents look like at a company operating at Intuit's scale and regulatory exposure.

Latency-based SLOs do not transfer, and semantic caching arrived early. Asked about impedance mismatch between traditional APIs and chattier agent traffic, Kurian said one of their first lessons was that there is no point defining SLOs based on simple request-response latency, because vendors change things constantly and what is slow today may be fast later. Teams came to her asking how to define a "failed customer interaction" for an LLM and her honest answer was that she did not know. Integrating this into existing monitoring and observability systems was a challenge requiring partnership with those teams — and sometimes, she notes, your dashboard is simply always red because you take longer than everything else. In the same answer she offered a platform-building caution: they built semantic caching assuming everyone would need it, but caching only pays off at scale and it took a long time for use cases to get there.

Scaling was planned, but had blind spots. Pressed on whether agents suddenly multiply request volume on downstream APIs, Kurian pushed back on the premise: these are planned rollouts starting at small percentages, with known dependencies and coordinated scale-up with owning teams — "it's not like all of a sudden the agent is going out of hand." Their actual blind spot was different and worth noting: the guardrail monitors themselves depend on ML models, and those had to be scaled up too. Agents are deployed on Intuit's existing service runtime, so all existing guardrails and protections apply.

AI governance is a partnership that needs balancing. On governance, Kurian reported that Intuit's teams actively participate in standards bodies such as NIST, both drawing requirements from them and contributing back. Her most transferable observation is cultural: their security researchers build the guardrails rather than blocking the work — they are not saying "no, don't do this," they are building the protections. She adds the honest caveat that sometimes the security and governance side goes "way eager" and the team has to address the business need, so it is a balance to be figured out rather than a solved process.

Context Dependence

Intuit is a regulated financial-services company with a dedicated central platform organisation, CTO-level mandate for a single platform, and 8,000 engineers. The build-it-yourself conclusion follows from Kurian's stated criterion — the regulatory bar — rather than from platform economics in general, so a smaller or less regulated organisation should re-run that build-versus-buy analysis rather than inherit the answer.

Practical Takeaways

• Decide workflow versus agent by asking whether you know the number of steps. Known sequence, known count, structured input — build a workflow. Unknown step count, unstructured input, open-ended goal — build an agent.
• Evaluate the trajectory, not just the final answer, and design against the known failure modes. Capture traces of every decision the model made and score tool selection, arguments, retrieved context, and tone separately, then keep those eval datasets alive as emergent production behaviours appear. Use Kurian's failure-mode list — role amnesia, step repetition, non-termination, objective drift, information withholding between agents, premature stopping, incorrect verification — as the design-review checklist.
• Get product managers to ship evaluation criteria with the PRD. Ask for the metric, the acceptance criteria, and the evaluation data. Domain experts cover scenarios engineers cannot imagine.
• Bake guardrails inline with your LLM API so they cannot be bypassed — and remember to scale the ML models behind those guardrails alongside agent traffic. Compliance you can route around is compliance you do not have.
• Externalise prompts from the codebase with versioning and governance. The people writing and optimising prompts are frequently not the people using Git.
• Ship a starter kit, not just capabilities. Default configuration wired to your platform, starter code, reference implementations, self-serve onboarding, and built-in tracing and evaluation is what converts an available platform into an adopted one — and scale review rigour to lifecycle stage so early experiments do not pay the cost of a full scaling review.
• Adopt a widely supported API standard as your internal contract. Intuit's OpenAI chat-completion compatibility made every third-party agent framework usable without bespoke integration.
• Classify every platform technology choice as fixed, flexible, or free, and feed what free-tier experimenters learn back into the roadmap.
• Start on the four foundations now, agents or not: make APIs tool-ready rather than deeply nested and human-oriented, invest in metadata over your data lake, design multimodal input paths that replace form filling, and prepare infrastructure for responses that take minutes rather than milliseconds.

Key Terms

• Workflow — A predefined sequence of code paths executed in a known order, chosen for predictability and consistency.
• Agent — Software in which the model makes the decisions, using the context it has at the moment and the tools available, chosen when the steps or step count are not known in advance.
• Done-for-you experience — Intuit's term for the current generation of agents that take actions on a customer's behalf, as opposed to first-generation conversational assistants that only answered questions.
• RAG (retrieval-augmented generation) — Retrieving relevant content from an index and inserting it into the prompt so the model can reason over data it was not trained on.
• Trajectory — The full recorded sequence of decisions and tool calls an agent made during a run, as opposed to only its final response.
• LLM-as-a-judge — Using a language model to score another model's outputs or decisions, so evaluation can scale beyond human review. Only as good as the judge and the ground truth it scores against, which requires domain expertise to establish objectively.
• Guardrails — Inline controls enforcing security, safety, privacy, and compliance constraints, placed in the LLM API path at Intuit so they cannot be bypassed.
• Fixed, flexible, free — Intuit's framework for technology choice: fixed platform concerns everyone shares, a curated compatible set of flexible options, and guardrailed space for free experimentation.
• GenOS / GenRuntime / GenUX / AI Workbench — Intuit's generative AI platform, its runtime, its user-experience layer, and its development environment; the Agent Starter Kit packages a CI/CD process, default configuration, starter code, and reference implementations on top of them.
• Tool registry / agent registry / prompt registry / use case registry — GenOS's catalogues of registered tools, agents, prompts, and use cases; work done in development is persisted here and activated at runtime.
• MCP (Model Context Protocol) — An open protocol for exposing tools, and other context, to models through a standard interface; GenOS uses it to activate registered tools at runtime.
• A2A (agent-to-agent) — An open protocol for agents communicating with and delegating to other agents in a multi-agent system.
• Tool-ready API — An API designed for an LLM to call, rather than a deeply nested human-oriented REST or GraphQL interface that models struggle to process.

Reference: Merrin Kurian, Powering the Future: Building Your GenAI Infrastructure Stack, QCon San Francisco, published by InfoQ on May 19, 2026.