Your first agent earns its budget on business outcomes. So when you pitch it to your executive sponsors, keep the business case to one slide. Name the business objective, what the agent will do to reach it, and the metric you'll use to prove it worked. 

In the take-home tools below, our Build Your Business Case template gives you that slide, plus a worksheet for weighing potential savings against new costs.

Andrea Simon and Rushikesh Choudhury made that business case together at Workday . Andrea leads business systems analysis under customer support. Rushi leads engineering on the business technology side. Business and IT walked into the exec conversation together, aligned on the same target.

Workday's customer support team started with a modest target: 10% case deflection by the end of the year.

Workday sits on a deep body of support content. Customers were opening cases for questions the knowledge base could already answer. Each deflected case is analyst time freed up for the more strategic work.

Andrea said, "We sit on a wealth of knowledge within the support organization. We thought, 'how can we make sure that customers have the ability to self-serve?'"

Rushi carried the technical side of the business case. His team had already been through one round with a legacy AI platform, then an AppExchange product. Both got the team to a certain level. Neither scaled with the volume Workday was seeing. Agentforce entered the conversation because the team kept re-evaluating tools on the market.

"We constantly re-evaluated all the products available in the market. And that is when we thought Agentforce could be the right fit for our use cases," said Rushi. "That's where we did our pivot on the technology."

A common trap for builders at long-time Salesforce customers is a mindset carried in from past enterprise rollouts.

Andrea noted that for long-time Salesforce customers, prior investment in the platform can shape how quickly new out-of-the-box features get adopted.

When previous rollouts have been slow, it's easy to assume the next one will be too. That assumption can lead builders to pad timelines or lower the ambition of their pitch before testing what's possible with Agentforce.

Andrea and Rushi avoided that trap because Rushi built the first working prototype fast enough to reset her expectations. "We were incredibly impressed with how quickly Rushi and team were able to set it up," said Andrea. She recalled reacting, "Wow, look at the quality that we're seeing."

Once the SMEs got hands-on, the results were already exceeding what the team had been experiencing before. A working demo, in front of real SMEs, faster than the team had seen a prior rollout ship. That shifted what leadership was willing to sign off on.

Workday's initial target was 10%. The result came in at 21% by the end of Q1 . Conversations with leadership shifted from "can we hit this?" to "what's the next number?"

Builders might assume the business case is IT's deliverable. IT builds the agent, IT owns the ROI, business signs the check. Leadership needs both sides of the case. IT can prove the technology works. The business side has to come from the business owner: what changes for customers, revenue, or cost savings.

Andrea and Rushi wrote their case together in one working session. Andrea owned the outcome the business needed. Rushi owned what the platform could realistically deliver, and by when. The exec conversation had one voice because the two of them agreed on the number before they walked in.

The same pattern shows up outside Workday. Chris Emmett, Managing Solution Architect at Capgemini , anchors his client conversations on the same idea after nearly a decade in the Salesforce ecosystem. "You can't tackle Agentforce technology first, it doesn't work," said Chris. "You have to find a business problem."

On one Capgemini engagement, that discipline let Chris build an Agentforce solution that identified expiring sales opportunities and drafted the chase email in 30 seconds. That task normally took a human rep 30 minutes, a 98% reduction in time.

When the business and IT sides show up to leadership with the same outcome, a working demo, and the same next-quarter target, the exec conversation gets easier.

Bring these tips into your first exec conversation:

• Don't let past enterprise rollouts set expectations for this one. Bring the number and the working demo. The last rollout's scar tissue stays behind you.
• Experiment early. Build the working version before you build the deck, and know where the journey goes after it.
• Pick the enterprise-ready platform up front. Small tools stack up fast, and leadership is signing off on a platform, not just a pilot.
• Work together. If you're on the business side, walk it to IT before you walk it upstairs. If you're on the IT side, do the same.

Andrea and Rushi walked out of their exec meeting with a target and shared momentum. For most teams, the business case and the first use case take shape together, and each one sharpens the other. Chapter 2 goes deeper on picking a first use case narrow enough to ship in weeks.

Go to chapter 2

As the practitioners building and shipping agents inside their companies, Agentblazers start with one question: What should my first agent actually do?

First-time agent builders who answer it well pick a repetitive, high-volume task, prove value in weeks, and let the wins compound.

Corporate travel platform Engine shipped the first version of Eva in 12 days. Eva is a customer-facing cancellations agent built on Agentforce . Sarah's team picked the highest-volume task in Eva's queue: Cancellations were the most frequent request their reps handled, and that volume made the impact easy to measure. Within one quarter, CSAT hit 94%, Engine's highest on record at the time.

"Your use case does not have to be fancy. It does not have to be big and shiny. It just needs to provide value. Start small and dive in with both feet — really identify a use case that is repetitive or manual for your human agents."

— Sarah Morton, Senior Salesforce Administrator, Engine

Engine's first version of Eva behaved more like a chatbot than an agent. The team launched with 35 topics (now called subagents), hoping to cover every possible question. The result was latency, misrouting, and wrong answers when Eva guessed at which subagent applied. The fix was scope. The team condensed 35 subagents down to eight and let Eva do those eight things well. Accuracy improved immediately. Fewer subagents, stronger outcomes.

Big-bang launches make memorable demos. Teams stall when they try to launch too many use cases at once. Start small, wire the first agent to real data, prove the value, then let ambition compound. 

Need help picking your first use case? In the take-home tools below, our Plan Your Use Case template walks your team from a brainstorm to a ranked shortlist, with a round of Bad Use Case Bingo to catch common traps before you build.

• Look at your own day-to-day work first. A task you and your team wish was easier is often a good use case.
• Start where the work is already repetitive. That's where value compounds fastest.
• Fewer subagents mean less risk of misrouting. Narrow the scope, then narrow it again.
• Design for reuse from day one. The architectural pattern you build for your first agent will carry forward to the next.

With your first use case picked and your first agent shipping, the next question is context. Chapter 3 shows how Agentblazers keep agents accurate in production by picking the data their first use case needs, choosing where the agent reads it from, and setting guardrails around it.

Go to chapter 3

AI agent builds stall waiting for perfect data. Many teams spend quarters cleaning field values, mapping fields, and mapping some more, and yet never ship. There's a faster path. The builders in this chapter didn't wait for perfect data. They picked the data their first Agentforce use case actually needed, built guardrails around it, and shipped from there.

Two questions decide the scope:

1. What decision does the agent need to make?
2. What data does that decision depend on?

Any other data can wait. What can't wait is scoping the fields, records, and access rules the agent will read from day one. Scope tightly enough that you'll spot a wrong answer fast and trust a right one on sight.

Dr. Romi Chopra is a leader at MIMIT Health , a Chicago-based medical group. His team scoped Agentforce to a specific set of patient data — the fields the agent needed to greet, verify, and route callers, and nothing more. Guardrails went in place around that data. The agent ran reliably from there. MIMIT saw a 459% ROI within three months, cut patient onboarding to under 10 minutes, and posted 30% gains in both CSAT and productivity.

CC Chiderski is Director of AI at CLD Partners, and coaches teams to treat governance the way pilots treat a preflight check. Her From Hype to Habit framework makes governance the launchpad. Before an agent goes live, a cross-functional team defines the guardrails and data-access policies that give it the right context to work within. She said the first move is to "create an AI governance team made up of stakeholders from Salesforce, IT, legal, security, operations, sales, and delivery." Data model, permissions, and audit trail get built for that scope first, and scope stays deliberately narrow, because a well-bounded agent with the right context is more reliable than a do-it-all agent without that context.

"Always avoid 'do everything' agents," CC said. "Narrow scope leads to higher reliability."

Pulling together a team like the one CC describes? In the take-home tools below, our Center of Excellence template helps you map who has a seat at the table and who makes which call, from production sign-off to rollback.

A common mistake is pointing an agent at everything and hoping accuracy follows. The more data an agent can reach, the more room it has to pull the wrong fact into a customer conversation, and in a clinical setting a wrong fact is not a small thing.

Dr. Chopra's team took the opposite approach. They scoped the agent to the specific patient data it needed to greet, verify, and route callers, then built guardrails around that scope so the agent could only read from the objects they had defined. That constraint is what makes the agent trustworthy. "It won't hallucinate because it can only look in the Salesforce objects that we've created," said Dr. Chopra.

Limiting what the agent can read does as much for accuracy as choosing what it reads. Scope the data to the decision, and the agent has far less room to get it wrong.

You don't need perfect data everywhere. You need the right data, scoped to your use case. Cleaning up data across an entire company may be a near-impossible task, and waiting on it will keep you from starting.

• Pick the pathway before you pick the fields. Map where your agent's data lives. If the data sits in CRM fields, start there. Reach for MCP or web search when the data doesn't exist in CRM.
• Scope the fields to the first decision, not the whole system. Once the pathway is set, pick the fields your agent needs to make its first decision well. Add data only after the agent earns trust.
• Treat governance as launch prep. Permissions, audit logs, and rollback paths clear the way to launch. Set them for the scoped data first.
• Track wrong answers, not just right ones. A tight feedback loop on failures is how you know when to expand the agent's data scope. Agentforce Studio surfaces those signals as your agent moves toward enterprise scale.

Once the context is in place, it's time to build. Chapter 4 picks up with architecture patterns builders use to keep agents accurate as they scale, from subagents to tools to the connections between them.

Go to chapter 4

Building your first agent is one thing. Building the fifth, sixth, or seventh, where edge cases pile up and reliability has to hold across conversations, is another. Most agent builders eventually ask, How do I make this agent reliable enough to ship?

The builders who answer that question well are purposeful in designing their architecture. Deterministic logic goes where the agent has to behave the same way every time. Prompt instructions handle the rest.

Two builders tell that story from opposite sides of the Agentforce platform. One teaches it publicly to thousands of admins and architects. One shipped it in production and moved the numbers.

The moment your agent has to hold up under real traffic, prompt-only architecture stops paying off. Long prompt instructions feel like they should catch every edge case. In practice, they compound. The model has more to interpret, more to weigh, more to guess wrong about. Reliability drops.

The fix is architectural. It goes deeper than the prompt. Move the parts of the agent that must follow rules into Agent Script 's deterministic logic. Keep prompt instructions for the moments where the agent's judgment is needed.

Sally ElGhoul has spent 16 years on the Salesforce platform and now teaches other builders how to work with it through Code with Sally and her YouTube channel with Agentforce-specific tutorials in English and Arabic. She is a Salesforce Lead Developer and Architect, a Salesforce MVP, Golden Hoodie recipient, and one of the most active teachers on Agent Script in the community.

Sally sees many newer builders working with Agent Script recipes — reusable code patterns Salesforce publishes for common agent behaviors. There’s also a learning-oriented recipes repo for builders getting started. The recipes are helpful starting points, especially if you take the time to learn the vocabulary and syntax.

Among the builders who start with recipes, Sally notices a pattern.

"What I hear all the time from new builders is, 'I followed the sample recipe exactly, but my agent is still misbehaving in ways I can't explain.' And when I dig into their build, the pattern I see is that they've copied a recipe before really sitting with Agent Script as a language. What I always tell people is, before you build anything, spend a couple of hours with the syntax fundamentals. Get familiar with indentation, case sensitivity, the difference between logic and prompt instructions. I know it sounds a little boring, but it's worth your time. Once you have the mental model, the recipes become starting points you can shape to your own use case."

— Sally ElGhoul, Salesforce Lead Developer & Architect, Code with Sally

Datasite runs its Agentforce program with one builder. Grant Roberson is the sole Agentforce administrator behind the company's Escalation Agent and Knowledge Answers Agent, both live in production and resolving customer conversations at scale.

The first version of the Escalation Agent lived entirely in prompt instructions. As Grant added edge cases, he stacked more instruction paragraphs to catch them. Reliability dropped in testing. Around one in three conversations couldn't produce a clean answer.

Grant rebuilt both agents on Agent Script. The architecture shifted from probabilistic prompt-coaxing to a hybrid model. He used prompt instructions for the conversational moments, and he used Script for deterministic logic and flow control. Case deflection climbed 17 points to a steady 82%. In a manual audit of roughly 400 conversations, only 2 failed to provide a clean answer. That's a ~0.5% failure rate, down from about 33%. The agent's CSAT now matches the live support team's CSAT at 4.8 out of 5.

"I used to have paragraphs of repetitive instructions everywhere to try and force behavior. With Agent Script, it's easy to remove that noise and replace it with conditional logic that lets you trust your agents to do exactly as you want them to."

— Grant Roberson, Sr. Salesforce Administrator, Datasite

"Use Script for guarantees. Use prompts for judgment."

— Sally ElGhoul

Grant's first build treated the model like a rule engine. Each new edge case meant another paragraph of prompt instructions, hoping the model would read them, weigh them, and apply them in the right order. The prompt got longer, and reliability got worse.

To fix this structural issue, Grant moved the parts of the agent that had to behave the same way into Agent Script's deterministic logic. He kept prompt instructions for the truly conversational moments, the places where the model's judgment is most useful. The prompt stopped growing, and the agent got predictable.

Sally sees the same failure mode from the other side of the platform. When architects show her an agent that works in testing and drifts in production, the pattern is almost always the same: Use prompt-style instructions in places where the agent needed deterministic logic. Prompts are probabilistic. They get you there most of the time but might fail you the times that matter most.

"Architects sometimes tell me my agent works great in testing, but in production it's just kind of unpredictable. And what I see when I look at their build is that they've written prompt-style instructions in places where they really needed deterministic logic. That's the disconnect. Agent Script is a real programming language. It has structure, it has syntax, it behaves the same way every single time you run it, and that predictability is the key to trusting your agent."

— Sally ElGhoul, Salesforce Lead Developer & Architect, Code with Sally

Each additional paragraph of instructions gives the model more text to interpret, more clauses to weigh, and more reasons to guess wrong. Grant's rebuild started at roughly a 33% failure rate on a prompt-only agent. It ended at 2 failures in about 400 conversations after he moved the deterministic logic to Agent Script. When you find yourself stacking instructions to force behavior, that's your signal to move the logic out of the prompt and into Script. 

Mapping out your own build? In the take-home tools below, our Choose Your Pilot Path template lays out four build options, from a quick prototype to a larger pilot with full governance.

• Invest an hour studying the syntax before you lean on AI to write it for you. Once you know indentation, case sensitivity, and the difference between logic and prompt instructions, recipes become starting points you can shape. Before that, they are a source of errors you cannot trace. 
• Test with realistic utterances, various languages, and across permission sets. Agents work in preview and break in production for reasons that don’t show up in a two-test QA pass. Test the same request phrased several different ways. Test with a service user, not just an admin. Check the parent user's permission sets before you deploy. 
• When you’re stacking instruction paragraphs to force behavior, move the logic into Script. Deterministic requirements like validation, required fields, and calling a specific action a specific way belong in code. Save the prompt for judgment. 
• When your prompt grows a paragraph of "if X, then Y" rules, move that logic into Script. Conditional code gives the reasoning engine one less thing to guess about, and lets you trust your agents to do exactly what you want. 
• Use AI as your ideation and planning partner. Brainstorm, plan your agent logic, and expedite your learning with our Help agent or other AI tools. It’s an effective way to refine your requirements before writing your first line of Agent Script.
  • Some tools we recommend: Coworker , Slackbot , Claude Tag , AI + Salesforce's MCP Server , and Ask Agentforce via the pop-up on any page of help.salesforce.com and developer.salesforce.com .

With one agent running well, the question becomes how to scale the practice. Chapter 5 opens inside Southwest Airlines®, where Ishrat Bhatti authored the Salesforce Center of Excellence's framework for Agentforce adoption. It's a reusable operating model for how Agentforce use cases get scoped and governed, with clear expectations for ownership and monitoring after launch. The chapter picks up with that pattern. You'll see the front door Agentforce use cases pass through before they're built.

Go to chapter 5

Once the first agent is working, builders start asking, “What does the second agent look like, and the tenth?”

The teams that scale well answer that question with a pattern, not another agent. They decide once how agents get scoped, governed, and monitored, and every new use case follows the same path. Teams weigh themselves down when they clone the first agent for every new use case; every copy adds another set of configurations, endpoints, and monitoring to maintain.

“One of the biggest lessons for us has been knowing when to slow down and build a reusable pattern, even when copying what worked the first time feels faster,” said Ishrat Bhatti.

Ishrat is a Lead Technology Analyst within the Salesforce Center of Excellence (CoE) at Southwest Airlines® , where she focuses on enterprise Agentforce adoption, governance, and enablement. She is the author of the CoE's Agentforce Adoption Framework, developed in alignment with Southwest's enterprise architecture standards. She also wrote the generative AI use case intake and governance process that feeds it, shaped with Southwest's architecture and AI governance teams, the reference teams work from when they bring an agent forward.

At Southwest, Agentforce was approved as an enterprise platform, but that approval doesn't mean every idea automatically becomes an agent. Every Agentforce use case enters through the CoE, regardless of which business, product, or architecture team proposes or delivers it. 

Teams bring their ideas, and the CoE helps shape them into well-scoped use cases, guides them through a structured intake process, and sets expectations for ownership and monitoring once they're live. Lessons captured along the way help the next build start smarter.

Platform approval enables Agentforce at the enterprise level, but it doesn’t replace use case-level governance: Every use case still goes through governance intake and review, and each one is evaluated on its own risk, data usage, and customer impact. The CoE applies governance and oversight before the build begins, while the responsible delivery team owns implementation, so the first decision is often whether something should be an agent at all.

That path is documented end to end: the CoE takes in and shapes the use case, AI governance assesses risk and determines the level of review required, and architecture governance reviews the design before build begins.

The model is also explicit about who decides what: The CoE advises, the business owns the use case, and architecture owns the design decision.

That front door does more than filter. Each use case that comes through it adds to what the next team starts with: the questions worth asking at intake, the standards proved out in practice, and the monitoring that surfaced problems early. Enablement is part of the same loop, because the standards only scale if the teams building agents know how to apply them.

What the CoE offers each team is a reusable operating model rather than a technical platform. The framework covers:

• The adoption lifecycle
• Governance and AI controls
• A decision framework for judging whether an agent is the right solution at all
• A library of implementation patterns
• Environment and sandbox strategy
• Monitoring and observability standards

A team bringing forward its first agent starts from that, instead of from a blank page. Once an agent is live, it’s operated like a product, with clear owners, monitoring, and continuous improvement after go-live.

One of the most consequential moves the CoE made was a change in where governance sits. Instead of each team defining its own review, standards, and monitoring for its own agent, those decisions are made once for the airline and applied to the agents that follow. That single change is what turns “build another agent” into “scope it, govern it, and hold it to the same standards.”

The pattern is already in practice. Agentforce Service is Southwest’s first enterprise AI customer support capability, live today, bringing key systems, data, and workflows together for the teams who serve travelers. A growing pipeline of new use cases is following the same path.

Southwest’s customer-facing product and architecture teams are expanding that footprint through the SuperAgent initiative, which brings the airline’s FAQ Agent and its newer Back Office Agent under one program. It’s a clear example of the pattern in action: Rather than delivering individual AI capabilities one at a time, each new capability moves through the same intake, governance, and observability standards the CoE stewards across the airline.

What makes it a proof point is the path it took: the same intake, the same governance review, and the same observability expectations that applied to the first agent. The framework carries a router and subagent orchestration pattern for exactly this shape of problem, and SuperAgent is one team’s application of it.

The build itself is owned and delivered by those product and architecture teams. Although those teams own delivery, each capability remains subject to the enterprise intake, governance, and observability requirements. 

The CoE's contribution is the operating model underneath it — the way each use case is scoped, reviewed, and monitored. That established process is what lets the next capability start ahead, instead of from scratch.

Once a first agent is working, the fast path is to clone it for every new use case. Each new build carries its own configuration, its own monitoring, and its own governance review. Each clone compounds the operational burden.

The more durable path is to define the pattern once. Ishrat wrote the framework first, so intake, governance, environment strategy, and observability standards are settled for the airline up front. Later builds start from them instead of negotiating each one again.

Scaling well means defining the pattern once. Intake, governance, observability, and architectural standards become a single operating model the next use case can build on. That operating model is what makes the third and fourth use cases easier to take on than the first.

• Design the second agent as a pattern. The scoping, governance, and audit trail you define now become the starting point for the builds that come after.
• Use agent data to identify follow-on use cases. Analyze the topics and queries flowing through your first agent; distinct concentrations of subject matter often reveal the prime candidates for your next specialized sub-agent.
• Bring governance earlier in the lifecycle. When governance is defined once and applied platform-wide, it becomes the mechanism that carries every build after the first.
• Monitor token efficiency. Understanding token usage helps you scale operationally and gives you a clearer view of the timeframes and budget for the net-new agents you want to explore.
• Treat the admin role as strategic. The work shifts from writing rules for one agent to shaping the pattern behind all of them.

Enjoyed learning from the Agentblazers in this guide? Plug into the Agentblazer Community to trade ideas, ask questions, and see how other builders are scaling.