Salesforce's CPO of Agentforce says 90 percent of agent work happens after go-live. Across more than 20,000 deployments. The Agent Build Lifecycle is architected for the half most teams never budget for.
John Kucera, Salesforce's CPO of Agentforce, gave an interview recently that deserves more attention than it has been getting. The numbers behind it are the reason. Salesforce has more than 20,000 enterprise customers running Agentforce in production. Its own support agent alone has handled more than three million conversations. That is a larger production sample than almost anyone else can claim, and the lesson that fell out of it is blunt.
The effort curve inverts. In traditional software, roughly 90% of the work happens before launch. You gather requirements, design the architecture, build, and test. After go-live you are mostly in maintenance. With agents, the ratio flips.
Kucera said it plainly. “In the typical software world, 90% of the work is getting to go live. Whereas in the typical AI agent, 90% of the work is after you go live to manage and improve the agent.”
This is the thing the Agent Build Lifecycle was built around. Salesforce just validated it at a scale no one else has reached. Here is what the 90% actually contains.
What did Salesforce learn from 20,000 agent deployments?
The effort curve inverts at go-live.
Modern tooling lets you build a working agent in an afternoon. The demo handles the typical questions well. Leadership sees it and greenlights production. The problem is that typical questions are a minority of what real users ask. The majority is edge cases, ambiguous phrasing, and cross-domain questions. That is where the agent earns or loses trust, and none of it shows up in the demo.
The failure pattern is teams following the traditional software playbook. They assume the hard work is done once the agent is live. It is not. That is when it starts.
The teams that succeed treat launch as the starting line. They get the pre-launch foundations right so they can iterate fast, and they budget the majority of their effort for the period after go-live.
Watch for a demo that cleared the typical questions getting mistaken for a finished agent.
Why do most enterprise agents fail after the demo?
A non-deterministic system needs a deterministic system underneath it.
LLMs are probabilistic. They predict the next best response rather than executing fixed logic. The same question can produce different steps each time. That is what makes them powerful for reasoning and natural language, and it is also what makes them a liability in high-stakes workflows where the answer has to be the same every time.
Salesforce's resolution is to run both. Deterministic workflows set the guardrails. Probabilistic AI adds adaptability and contextual reasoning on top. The production realities of 20,000 deployments pushed them to ship Agent Script, a TypeScript framework for deterministic control flow, and Hybrid Reasoning, so predictable steps run as code and only the genuinely ambiguous parts go through the model.
That split is the eval framework and the governance gate in different words. The agent reasons. The gate decides whether the output is allowed to ship. If you can't trace it, you can't trust it, and an agent you can't trust does not get to run unsupervised.
Watch for a workflow you could draw as a flowchart running through the reasoning loop instead of through code.
What has to be true before you ship?
Small scope. One KPI. Guardrails on both sides of the model.
Kucera's pre-launch advice was three moves. Start small, because agent capabilities are still moving fast and a complex multi-step build today may need rebuilding in six months. A focused use case gives you real production learnings without overcommitting to today's limitations.
Tie the agent to a KPI. Salesforce measures its support agent on containment rate, the percentage of cases fully resolved without human follow-up, and tracks work with Agentic Work Units, a standard count of meaningful tasks the agent actually completed. Without a measurable goal there is no way to tell a working agent from a drifting one.
Put the trust layer in place from the start. Input guardrails protect data on the way into the model with secure retrieval, zero data retention, and a trusted hosting boundary. Output guardrails check the response on the way out with tool validation, grounding checks, and content filtering.
This is the workflow audit and the architecture decision, done before a line of agent code. Scope and a number first.
Watch for an agent already in production with no metric that tells you whether it is working.
What does the post-launch feedback loop actually catch?
Four failure types. Four different fixes.
With agents, the failure modes are fuzzier than pass-or-fail tests. Salesforce sorts post-launch issues into four buckets, each with its own fix. Tone and brand drift gets fixed in the system prompt. Logic errors get fixed in tool configuration, or by moving the flow into deterministic code when the same error keeps recurring. Data quality issues get routed back to the data owner, because the source was wrong and the agent only repeated it. Their support agent grounds on 135,000 help articles, and the team regularly finds outdated ones behind a flagged answer. Coverage gaps get a scope expansion or a clean escalation to a human, and the gap gets logged so coverage growth is tracked.
The part that matters most is the speed of the loop. Across Salesforce's customer base, the speed of this feedback loop was the gate to scaling. Teams that could triage and fix fast earned the confidence to expand. Teams with slow loops stayed stuck in pilot.
This is the operating playbook. Cost telemetry and eval pass rates are the instruments that tell you which bucket a failure lands in and how fast you closed it.
Watch for a feedback loop slow enough to keep the fleet parked in pilot.
Which anti-patterns degrade agents at scale?
Three mistakes Salesforce saw repeat across 20,000 deployments.
The first is over-reliance on LLM reasoning where code is better. When a customer asks where their order is, the correct sequence of API calls is deterministic. Look up the order, get its status, get the shipment. Routing that through the reasoning loop adds round trips, latency, and a chance of error on every hop. If you can write the logic as a flowchart, it should be code.
The second is prompting harder instead of encoding policies. Teams catch a wrong behavior and respond with a stronger instruction, then bold text, then ALL CAPS and exclamation points. Models do not respond to emphasis the way humans do. A financial services firm that does not operate in Hawaii should not hope the model infers that from a prompt. The rule belongs in code. If the state is Hawaii, return this response, with no model judgment in the path.
The third is poor context engineering. One e-commerce get_orders call returned roughly 100K tokens by default. Trimmed to about 2K by returning only the fields the agent needs, order ID, status, delivery date, tracking number, the agent got faster and more accurate at the same time. More context buried the answer. Less context surfaced it.
For Magnetiz these are not post-launch cleanups. They are build principles that belong in the architecture decision, before the eval framework ever runs.
Watch for a strongly worded prompt standing in for a policy that should be a conditional in code.
What does building for the 90 percent look like in practice?
The lifecycle does not end at build.
The Agent Build Lifecycle runs seven phases. Workflow audit, architecture decision, build, eval framework, cost telemetry, governance gate, operating playbook. Build is one phase. The four phases that follow it are the 90% Salesforce measured.
The eval framework gates the output before it ships. Cost telemetry bounds the spend so an agent cannot quietly run past its budget. The governance gate sizes oversight to the trust boundary, tiered per autonomy level as covered in the last edition. The operating playbook runs the feedback loop that Salesforce found was the real gate to scaling.
The fleet that survives contact with real users is the one architected for the work that begins at launch.
Watch for a methodology that treats the build as the finish line.
The half of the lifecycle that decides the outcome
Salesforce just validated, at a scale of more than 20,000 deployments, the premise the Agent Build Lifecycle is built around. The build ships the agent. The eval framework, the cost telemetry, the governance gate, and the operating playbook decide whether it survives.
The teams that budget for the 90% run a fleet. The teams that stop at the demo run a pilot that never graduates. The work was never getting to go-live. The work was everything after.
FAQ
What did Salesforce learn from 20,000 Agentforce deployments?
In a 2026 interview, John Kucera, Salesforce's CPO of Agentforce, said the effort curve inverts with AI agents. In traditional software roughly 90% of the work happens before launch and the rest is maintenance. With agents about 90% of the work happens after go-live, managing and improving the agent against real-world questions. Salesforce draws this from more than 20,000 enterprise deployments, including its own support agent that has handled more than three million conversations.
Why do enterprise AI agents fail after launch?
They fail because teams apply the traditional software playbook and assume the hard work ends at go-live. A demo handles the typical questions, but real users bring edge cases, ambiguous phrasing, and cross-domain questions that the demo never surfaced. Because LLMs are probabilistic, the same question can produce different steps, so high-stakes workflows need deterministic systems underneath to stay consistent. Teams that skip the post-launch feedback loop never close that gap.
What AI agent anti-patterns did Salesforce identify?
Three. Over-reliance on LLM reasoning where deterministic code is better, such as routing a fixed sequence of API calls through the reasoning loop. Prompting harder instead of encoding policies, where teams add emphasis and capitalization rather than encoding a business rule as a conditional. Poor context engineering, where unfiltered API responses flood the context window and bury the answer, hurting both speed and accuracy.
What is an Agentic Work Unit?
An Agentic Work Unit, or AWU, is a discrete unit of meaningful work completed by an agent. Salesforce introduced it as a standard way to measure actual task completion, counting how many user intents an agent fully resolved rather than how many interactions it had. It complements outcome KPIs like containment rate with a more granular view of agent productivity.
Why should AI agents use deterministic code instead of LLM reasoning?
Because predictable logic runs more reliably and faster as code than as a prompt. A deterministic sequence routed through the reasoning loop adds round trips, latency, and a chance of error at each step. Business rules encoded as conditionals execute the same way every time, while the model is reserved for the parts that genuinely need flexibility, such as interpreting an ambiguous request or generating natural language. Salesforce built Agent Script, a TypeScript framework, to define deterministic control flow alongside LLM-powered decisions.
What is the Agent Build Lifecycle?
The Agent Build Lifecycle is the Magnetiz methodology for building and operating production AI agents across seven phases. Workflow audit, architecture decision, build, eval framework, cost telemetry, governance gate, and operating playbook. Build is one phase. The eval framework, cost telemetry, governance gate, and operating playbook cover the post-launch work that Salesforce found accounts for roughly 90% of the effort, which is why the lifecycle is architected to run well past go-live rather than ending at the build.