{"id":93032,"date":"2026-04-14T09:00:00","date_gmt":"2026-04-14T16:00:00","guid":{"rendered":"https:\/\/www.salesforce.com\/?p=93032"},"modified":"2026-04-14T09:25:14","modified_gmt":"2026-04-14T16:25:14","slug":"applied-ai-building-agents-playbook","status":"publish","type":"post","link":"https:\/\/www.salesforce.com\/news\/stories\/applied-ai-building-agents-playbook\/","title":{"rendered":"Applied AI: Why Building AI Agents Requires a New Playbook"},"content":{"rendered":"\n

Table of Contents<\/strong><\/p>\n\n\n\n

    \n
  1. Introduction: The End of \u2018Build Once, Ship, Move On\u2019<\/a><\/li>\n\n\n\n
  2. First Principles: Why Agents Aren\u2019t Software<\/a><\/li>\n\n\n\n
  3. The ADLC Framework: Phases of the Agent Lifecycle\u00a0<\/a><\/li>\n\n\n\n
  4. Defining Critical Jobs to Be Done<\/a><\/li>\n\n\n\n
  5. Managing Synthetic Reasoning: Drift, Calibration, and the Human in the Loop\u00a0<\/a><\/li>\n\n\n\n
  6. Conclusion: The Crossover Point<\/a><\/li>\n<\/ol>\n\n\n\n
    \n\n\n\n

    1. Introduction: The End of \u2018Build Once, Ship, Move On\u2019 <\/strong><\/h2>\n\n\n\n

    For decades, the Software Development Lifecycle (SDLC) has been the bedrock of the technology industry. Its logic is elegant and straightforward: Define requirements, write code, test it, ship it, maintain it. If the code says 2 + 2 = 5, you have a bug \u2014 a logic error with a deterministic fix. You patch it, you push a new version, and the world moves on. Modern software engineering is built on one core assumption: predictability. <\/p>\n\n\n\n

    That assumption is now breaking. <\/p>\n\n\n\n

    As enterprises race to deploy autonomous AI agents<\/a> that don\u2019t just execute instructions but reason, adapt, and make decisions, they\u2019re discovering an uncomfortable truth: Agents aren\u2019t traditional software. They\u2019re probabilistic, not deterministic. They don\u2019t \u201crun\u201d; they \u201cbehave.\u201d And the degree to which they behave well isn\u2019t a fixed property you can test once and trust forever. <\/p>\n\n\n\n

    The instinct in our industry is to treat agent development the way we have always treated software development: Write the prompt, connect the APIs, run a test suite, deploy, and move on. This results in agents that work brilliantly in staging and erratically in production, agents that degrade over time even when no one touches them, agents that pass every test case and still fail the customer. <\/p>\n\n\n\n

    The gap between how we build traditional software and how agents actually work is where most enterprise AI<\/a> deployments break down. No amount of prompt engineering will close it. What is needed is a fundamentally different lifecycle designed from first principles for the realities of probabilistic AI. <\/strong><\/p>\n\n\n\n

    At Salesforce, we have spent the past two years building and deploying autonomous agents at enterprise scale across thousands of use cases, serving tens of thousands of employees and millions of end customers. In the early days, we saw the same friction points many enterprises face today. We had disparate approaches across the organization, a lingering bias toward “build once and ship,” and ad hoc AI governance. This fragmentation led to inconsistent results and inaccurate guidance for our teams.<\/p>\n\n\n\n

    Through that work, we have developed the Agent Development Lifecycle, or ADLC. <\/p>\n\n\n\n

    ADLC is a closed-loop learning system of testing, monitoring, calibration, and refinement that is designed to manage the inherent drift of an evolving AI ecosystem. Where SDLC ends at the release, ADLC recognizes that deployment is merely day one and delivers a model centered on continuous improvement post-launch, rigorous AI governance, and teams comprising agentic technologists who support technical build and behavioral coaching.<\/p>\n\n\n\n

    This paper introduces the ADLC framework, explains the first principles behind it, details its six core phases, and describes the new jobs to be done and organizational capabilities enterprises must develop to succeed in the agentic era. <\/p>\n\n\n\n

    2. First Principles: Why Agents Aren\u2019t Software<\/strong><\/h2>\n\n\n\n

    To understand ADLC, we need to move past the hype and look at the functional reality of building and managing probabilistic systems.<\/p>\n\n\n\n

    The Taxonomy of Agent Work <\/strong><\/h6>\n\n\n\n

    The first mistake most organizations make is treating every agent task the same way. In practice, when we decompose a job into its elemental tasks, those tasks fall into three distinct categories, each of which demands a different tooling approach. <\/p>\n\n\n\n

    The first category is deterministic code<\/strong>. These are tasks that require 100% accuracy and zero creativity: updating a CRM field, generating an invoice, changing a lead status. They belong in traditional code (Apex triggers, flows, APIs), not in a language model. <\/p>\n\n\n\n

    The second category is retrieval<\/strong>. These tasks require specific, factual context: \u201cWhat are our Q3 pricing tiers?\u201d or \u201cWhat is this customer\u2019s contract renewal date?\u201d The agent needs to be grounded in a trusted data source (like Salesforce Data 360<\/a>) to ensure it\u2019s not hallucinating.<\/p>\n\n\n\n

    The third category is the reasoning engine<\/strong>: the large language model (LLM) itself. These are the tasks that require genuine judgment: \u201cBased on this prospect\u2019s LinkedIn activity and recent support tickets, what is their most likely pain point?\u201d This is where the LLM<\/a> earns its keep.<\/p>\n\n\n\n

    Distinguishing between these three categories is the most important design decision in ADLC. If a task can be accomplished with a regular expression or an if-then statement, keep it out of the LLM. Save the reasoning tokens for where the ambiguity actually lives. <\/p>\n\n\n\n

    Job Decomposition, Then Job Automation<\/strong> <\/h6>\n\n\n\n

    The second mistake is attempting to automate an entire role, for example, \u201cAutomate Sales\u201d or \u201cAutomate Support.\u201d Automation isn\u2019t the wrong goal, but it\u2019s the wrong starting point. Before you can automate anything, you must decompose the role: break it into its elemental tasks and determine which specific tasks an agent can own, which require human judgment, and which should remain in deterministic code.<\/p>\n\n\n\n

    When we built our Engagement Agent \u2014 the same one that now generates over $120 million in annualized pipeline<\/a> \u2014 we didn\u2019t try to \u201cautomate Sales.\u201d Instead, we looked for the high-volume, high-impact tasks where extra capacity would provide outsized gains for our sales development representatives (SDRs). Engagement Agent has succeeded not by trying to be an SDR but by doing specific SDR tasks exceptionally well. <\/p>\n\n\n\n

    Don\u2019t Throw the Kitchen Sink at Your Agent <\/strong><\/h6>\n\n\n\n

    This leads to the third first principle: Resist the urge to build a \u201cgeneral agent.\u201d The biggest mistake we see operators make is trying to build a single agent that can do everything \u2014 handle research, draft communications, verify facts, update records, and make recommendations all in one system. These monolithic agents become bloated, expensive, and prone to \u201clogic collisions\u201d where the instructions for one capability interfere with the performance of another. <\/p>\n\n\n\n

    ADLC instead advocates for a targeted agent architecture. Each agent should have a defined, coherent scope of work with clear purpose and boundaries. Build one agent for account research. One for customer outreach. One for seller coaching. Each does one thing exceptionally well, and each can be calibrated, monitored, and improved independently. Critically, these targeted agents must pass a quality check to earn their \u201cticket to ride\u201d before being orchestrated into enterprisewide systems. ADLC is a gated process, and only high-quality agents get through. <\/p>\n\n\n\n

    Within each targeted agent, the work is further decomposed into subagents that handle specific tasks in the agent\u2019s broader scope. Consider our Engagement Agent, whose job is engaging a customer after a lead is submitted by email. The macro goal is to get that customer ready to book a meeting with a seller. But that scope breaks down into discrete subtasks: One subagent drafts the initial email. Another checks the message strength before it goes out. Another handles the follow-up sequence. Each subagent has its own skill and context and can be independently refined. The result is that, as any one component improves, the overall agent improves. And when a subagent gets overloaded, you can split it apart and create a new one \u2014 giving agents clear purpose and boundaries at every level.<\/p>\n\n\n\n

    How these targeted agents then work together is a question of orchestration, and it\u2019s the ultimate destination of ADLC. <\/p>\n\n\n\n