Scope and plan your first agent: Build Agentforce AI Agent Part 3

This is the forth blog in the series “Design Your First Salesforce AI Agent with Agentforce : From Sales Persona to Automation“.

Scope Your First Agent

💡Why This Matters
A tightly scoped MVP lets you prove value fast, build internal momentum, and create something reps will actually use. This step turns your roadmap into real execution — starting small, but with purpose.

🔑 What You’ll Learn
How to select the 2–4 use cases best suited for your first agent build
What criteria to use to balance value, effort, and cohesion
How to define clear outputs, systems, and triggers for each use case
How to scope an MVP that’s testable, measurable, and adoption-ready

With a phased roadmap in place, the next step is to define the scope of your initial AI agent. The goal here is focus: choose a small set of high-value, low-effort use cases that can be implemented quickly and deliver measurable results.

This step connects long-term planning to near-term execution. You’re distilling the broader roadmap into a focused MVP build — one that’s practical, testable, and outcome-driven.

The strongest candidates for your first build are use cases that:

• Map to a frequent, well-understood rep workflow
• Fit within existing systems and data models
• Require minimal configuration or process change
• Can demonstrate clear impact within a few weeks

🔍 Selection Criteria

When selecting use cases for the first build, keep the following in mind. This connects back to the mapping exercise we completed earlier.

• Business Value – Does this improve speed, accuracy, or follow-through in a core workflow?
• Effort to Deliver – Can it be built with existing data, automation patterns, and integrations?
• Workflow Cohesion – Do the selected use cases support a unified end-to-end flow (e.g. meeting → follow-up → update)?
• User Experience – Is it intuitive, easy to adopt, and helpful from day one?

🧩 Output of This Step

By the end of this step, you should have:

• 2–4 use cases scoped for MVP delivery
• Defined triggers, systems required, and expected outputs for each
• Clear internal alignment on success metrics (e.g., time saved, data accuracy, rep follow-through)

This forms the foundation of your first working agent.

✅ Strong Candidate Use Cases: Sales Persona

Here are high-value, low-effort jobs that make ideal starting points for your first agent, selected from the Friction × Impact exercise we completed earlier.

• Prepare for Customer Meetings
  Generate a meeting brief using CRM context, past notes, open tasks, and account history.
• Log Meeting Notes
  Use AI to summarize recordings or transcripts log notes and automatically create follow-up tasks.
• Draft and Send Follow-Ups
  Auto-generate personalized emails based on meeting content, open items, and Salesforce context.
• Create New Opportunities
  Suggest or auto-fill opportunity records during lead conversion to reduce manual entry and improve pipeline quality.
• Review and Update Opportunities
  Identify incomplete or outdated records and prompt reps to review or apply suggested updates.
• Monitor Deal Progression
  Surface stalled opportunities based on recent activity signals, helping reps refocus attention.
• Schedule Meetings
  Coordinate based on calendar availability and contact preferences, directly from Salesforce or email.

👉For the purpose of this blog, these are ideal use cases to highlight. They demonstrate how AI can solve real, everyday pain points — without complex setup — making them perfect for showcasing agent-based automation in action.

In Step 6, you’ll define the behaviors, triggers, and actions behind each of these use cases — and begin building your first agent using Agentforce.

Plan your first agent

💡Why This Matters
This is the moment where strategy becomes execution. Without a clear design, even the most promising AI agent can become brittle, inconsistent, or hard to maintain. Planning ensures that your agent behaves predictably, aligns with Salesforce data structures, and scales smoothly across users and use cases. It also minimizes rework — because a well-scoped, modular agent is easier to update as your business evolves.

🔑 What You’ll Learn In this section, you’ll learn how to:
Organize scoped use cases into clear, reusable agent topics
Define agent behaviors based on user intent
Map required Salesforce data objects and fields per topic
Set up guardrails, fallbacks, and context memory to handle real-world variation

Let’s break down the building blocks of Agentforce. Every agent is organized around topics, which represent the jobs to be done. Each topic has a name and description that help the reasoning engine classify the user’s intent. Once a topic is selected, the agent follows the instructions defined for that topic in natural language. Finally, each topic is powered by a set of actions that the agent can execute, such as looking up an order, summarizing an account, or searching the web.

Since we’ve identified the use cases for your first agent, it’s time to move from ideas to execution. But before we start building, we need to design the foundation. Planning ensures your agent behaves predictably, works within Salesforce’s structure, and scales with minimal rework.

1. Classify Use Cases into Topics
   Group related workflows into logical topics like Meeting Preparation, Post-Meeting Follow-Up, and Pipeline Management.
   
2. For Each Topic:

• Map user intents to specific behaviors
  (e.g., “Prep me for Omega” → PrepareMeeting → fetch & summarize Event + Account + Opp → fallback if no match)
• Define the data needed across Salesforce objects and fields
  (e.g., Event, Account, Opportunity, ActivityHistory)
• Set guardrails and fallback logic
  (e.g., “I couldn’t find a meeting with Omega — would you like to see all upcoming meetings?”)
• Identify any context memory needed for continuity
  (e.g., reuse the last Event referenced when the user says “send me the notes”)

🔹 Classify Use Cases into Topics

💡Why This Matters
Topics are the building blocks of your agent’s reasoning. A clear topic structure makes it easier for the agent to interpret user intent, route requests accurately, and respond with consistent behavior. Without well-defined topics, the agent becomes harder to maintain and more prone to misfires.

🔑 What You’ll Learn
How to group related use cases into coherent topics
Why topic distinctiveness is key for LLM-driven accuracy
How to avoid overlap and ensure intent-to-topic mapping is clear
Examples of strong topic design based on real sales workflows

First start by clustering your use cases into coherent topics. A topic represents a logical unit of sales work — grouped by timing (before/after meeting), purpose (prep vs. follow-up), and data context.

Careful Topic Definition Is Critical to a Successful Agent Design

When building an agent, clearly defining each topic is one of the most important steps. Topics should be mutually distinct and purpose-specific — not overlapping in scope or intent. Why? Because large language models (LLMs) rely on semantic cues to determine which topic or action to activate based on the user’s utterance.

If topics are too similar or ambiguous, the LLM may misclassify the user’s request, triggering the wrong behavior or returning an irrelevant response. This leads to user confusion and undermines trust in the agent.

To avoid this:

• Define each topic around a unique job-to-be-done, not just a similar workflow step.
• Ensure that intent phrasing and examples clearly align to one topic only.
• Avoid creating multiple topics that respond to similar keywords unless they produce fundamentally different outputs.

Think of topics as entry points into focused capabilities — the clearer and more differentiated they are, the more accurate and reliable your agent will be.

👉 Within the product we have a topic overlap alert which will alert you as you are building. For more information about topics refer to https://help.salesforce.com/s/articleView?id=ai.copilot_topics.htm&type=5

🧱 Topics definition

For the use cases we selected for the first agent, lets scope the topics:

1. Meeting Preparation

Use Case:

• Prepare for upcoming customer meetings

Why it’s a topic:

It happens before a scheduled meeting and relies on Event, Account, and Opportunity data to deliver a contextual brief.

2. Post-Meeting Follow-Up

Use Cases:

• Summarize meetings
• Log notes
• Create follow-up tasks
• Draft/send emails

Why it’s a topic:

These happen after a meeting and share a common input (meeting context) and output (follow-ups, communication, task creation).

3. Pipeline & CRM Record Management

Use Cases:

• Review/update Opportunities
• Create new Opportunities
• Look up real-time CRM data during meetings

Why it’s a topic:

These are always-on sales ops tasks, tied to core objects like Opportunity and Account. Grouping them avoids duplication and enables reusability.

🔹 Define Agent Responses, Data, Guardrails, and Context Memory

💡Why This Matters
This step is the foundation of your entire agent. It defines how the agent interprets user input, chooses the right behavior, retrieves the right data, and maintains context across interactions. If this structure isn’t clear, your agent will behave inconsistently, struggle with ambiguous requests, or return incomplete responses. A well-defined logic model ensures your agent can reason accurately, handle edge cases, and scale to new use cases without rework.

🔑 What You’ll Learn
How to map user intents to specific agent behaviors
What Salesforce data is needed to support each behavior
How to design fallback logic and safety checks
How to use context memory to support multi-turn interactions within a topic

Once you’ve defined your core topics, it’s time to build out how the agent actually thinks and behaves within each one. This is where abstract ideas turn into usable AI logic — every topic becomes its own micro-brain with precise behavior, inputs, and safety checks.

Use the following structure for each topic:

• 🧠 Map user intents to specific agent responses
• 📊 Define the data needed across Salesforce objects and fields
• 🛡️ Set guardrails and fallback logic to keep responses safe and reliable
• 🪢 Identify any context memory needed for continuity

🗓️ Topic 1: Meeting Preparation

🧠 Intent-to-Behavior Mapping

📊 Data Needed

To generate a contextual meeting brief, the agent must retrieve data across several standard Salesforce objects:

• Event
  • Subject, StartDateTime, EndDateTime, WhatId (Account), WhoId (Contact), Description
• Account
  • Name, Industry
• Opportunity
  • Stage, Close Date, Amount, AccountId

🛡️ Guardrails and Fallback Logic

• Restrict visibility to Events owned by the user
• Only surface Events from the next 7 days
• Handle missing Account gracefully (skip Opps)
• Never auto-send meeting summaries — always confirm destination
• If vague references like “second meeting” or “Omega” can’t be matched, ask the user to clarify

🪢 Context Memory Required

• Cache the ordered Event list for follow-ups like “second meeting”
• Store the generated meeting brief to support sending or editing
• Carry forward the Account context (e.g., Acme) for subsequent meeting prep

🗓️ Topic 2: Post-Meeting Follow-Up

🧠 Intent-to-Behavior Mapping

📊 Data Needed

To log notes, update/create events, generate tasks, and draft emails, the agent must access:

• Event
  • Subject, StartDateTime, EndDateTime, WhatId, WhoId, Description
• Task
  • Subject, DueDate, Description, WhatId, OwnerId
• Account / Opportunity
  • Name, Primary Contact, Id
• Contact
  • Name, Email, Related Account

🛡️ Guardrails and Fallback Logic

• Restrict access to user-owned Events
• Only search past Events from the last 30 days
• If WhatId is missing, prompt the user to supply the Account manually
• Never auto-send emails — show the draft and ask to confirm
• Fallback defaults:
  • No due date? → assume tomorrow
  • No duration? → assume 30 minutes

🪢 Context Memory Required

• Store meeting notes in memory while user edits or confirms
• Cache recent Events for index selection like “use the 3rd one”
• Remember the created Event or Task for downstream flows
• Keep the approved notes for generating emails

🗓️ Topic 3: CRM Record Management & Pipeline Support

🧠 Intent-to-Behavior Mapping

📊 Data Needed

To view, update, or create opportunities and retrieve CRM data:

• Opportunity
  • Name, Stage, Amount, Type, Close Date, OwnerId, AccountId
• Account
  • Name, Id, Industry, Region, Type, OwnerId, Billing Address
• Contact
  • Name, Email, Title, Role, AccountId

🛡️ Guardrails and Fallback Logic

• Validate that the field exists before updating any record
• Always require explicit user confirmation for updates or creation
• Enforce constraints:
  • Stage must be Discovery or Qualification
  • Type must be New Business, Add-On, or Services
  • Only create Pipeline opportunities
• Prompt if:
  • Reference is vague (“the first one”)
  • Required field (e.g. Close Date) is missing
• Never assume:
  • Clarify field names if ambiguous
  • Ask for account if opportunity match fails

🪢 Context Memory Required

• Cache list of recent Opportunities for index-based actions
• Store Account/Opportunity context for follow-up queries like “show me more”
• Cache Contact list when showing multiple results for disambiguation
• Save last Opportunity or Account for similarity comparisons or activity checks

Checkout the next blog in the series here.

Written by