Salesforce Agentforce
Turn customer context into a next step.
ColdAI implements Salesforce Agentforce one workflow at a time. Each agent is grounded in the customer record and approved knowledge, limited to the actions your process allows, and finishes by writing a clear outcome back to the case or opportunity so service and sales teams can see what happened. Program-wide standards and budgets belong to our Agentforce Center of Excellence work.
The opportunity
Start with a decision
worth improving.
A service request needs account context, an eligibility check and a proposed resolution. The agent should progress the case while preserving the rules that govern customer changes.
From possibility to a working system
Follow the flow.
Three connected decisions. One considered architecture.
Conceptual flow, not a live system or measured result.
Ground the conversation
Identify the relevant customer records, knowledge and access rules. Define which information is trustworthy and which questions require clarification before the agent can continue.
Choose a bounded action
Map the permitted actions to the business process. Validate required fields and escalation conditions, especially when a response changes a customer record or commercial commitment.
Return a useful outcome
Write the agreed outcome back into the workflow and preserve its context for the team. Evaluate resolution quality, handoffs and repeated failure patterns with real task examples.
The work, made concrete
What we can build
with your team.
We agree scope, dependencies and acceptance criteria before delivery. Your project can start with an assessment, a pilot or an integration into an existing system.
CRM agent use-case design
Clarify the system boundary, the responsible owners and the decisions the architecture needs to support.
Action and knowledge integration
Turn the agreed design into reviewable work, evaluated against representative inputs and explicit success criteria.
Service-team evaluation and handover
Make the next step operable: document responsibilities, known limitations and the path from pilot to ongoing use.
In depth
Go deeper into building one Agentforce agent
Detailed pages on the two stages that most often decide whether a first agent reaches customers: its design and its pre-launch testing.
- 01GuideDesigning Agentforce subagents, instructions and actionsHow to design Agentforce subagents (formerly topics), instructions and actions: scoping, where rules belong, Flow or Apex actions, filters and a worked example.
- 02ChecklistTesting an Agentforce agent before go-liveA pre-launch Agentforce testing checklist: utterance sets, subagent and action assertions, agent-user permission tests, handoff checks and early monitoring.
One Agentforce workflow from request to recorded outcome
Every agent worth launching follows this spine. Channels, extra subagents and checks are added around it, not instead of it.
- Customer or employee asks
A message arrives through messaging, the web, Slack or an internal app, carrying whatever context the session already holds.
- Agent Router
Classifies the request into a subagent using each subagent's name and description1.
- Grounding
Reads the relevant case, account or opportunity and retrieves approved knowledge, within the agent user's access.
- Bounded action
A Flow or Apex action checks eligibility or prepares a change, with required fields validated in code rather than in the prompt.
- Confirm or escalate
The customer confirms, a rep approves, or the conversation moves to a human queue with its context.
- Outcome written back
The case or opportunity records what was decided, by whom and why, so reports reflect the agent's work.
Three shapes of first Agentforce workflow and how they differ
Most first agents take one of these shapes. The shape decides what the agent reads, what it may change and how you will know it works.
| Criterion | Service case resolution | Opportunity next step | Employee self-service |
|---|---|---|---|
| Grounded in | Case, account, entitlement and knowledge articles | Opportunity, contacts, activity history and pricing rules | Internal knowledge and the employee's own records |
| Typical bounded action | Check eligibility, propose a resolution, update the case status | Draft a follow-up, log a task, propose a stage change for the rep to approve | Create a request record or update a personal detail |
| Outcome written back to | Resolution fields and a summary comment on the case | The opportunity's next step and activity timeline | The request record and its owning queue |
| Main risk | Promising something the policy does not allow | Changing forecast data without the rep's judgment | Exposing records beyond the employee's own |
| Signal that it works | Cases resolved or correctly escalated with complete fields | Logged next steps that reps keep rather than overwrite | Requests completed without a follow-up ticket |
Lead qualification and support triage are written up separately as the AI lead qualification and AI customer support triage use cases.
Agent, Flow or person: the right tool for each step
- If
The steps are fixed, the inputs are structured and nobody needs to interpret language.
ThenBuild or keep a Flow, with no agent involved.
Deterministic automation is cheaper to run and far easier to test than a reasoning step.
- If
Requests arrive as free text but map to a small set of permitted outcomes.
ThenUse an Agentforce agent with one or two subagents whose actions enforce the rules.
The agent handles interpretation while the actions keep decisions consistent.
- If
The outcome commits money, changes a contract or alters forecast figures.
ThenLet the agent prepare the change and route it to a named person for approval.
Accountability for commercial commitments should stay with an employee.
- If
The records or knowledge articles the agent would read are incomplete or contradictory.
ThenFix the data before building the agent.
An agent repeats whatever the record says, faster and to more people.
- If
Several business units want agents at the same time.
ThenAgree shared standards first through an Agentforce Center of Excellence.
Reusable actions, evaluation sets and budgets are easier to set before agents multiply than after.
Implementation sequence for a single Agentforce agent
Each stage ends in something a process owner can review. Design and testing have their own detailed pages.
Choose the workflow and record its baseline
Pick one process with an owner, describe how it is handled today and note how outcomes are measured now, so the agent is compared with something real.
Confirm records and knowledge
Check that the fields the agent will read are populated and trusted, and that knowledge articles are current and owned.
Design subagents, instructions and actions
Scope what the agent handles and decide which rules live in Agent Script or actions rather than instructions; see designing subagents and actions.
Set the agent user's access
Give the agent user only the objects, fields and records the workflow needs, and note every Flow that runs in system context.
Test before customers see it
Run batch, permission and handoff tests in a sandbox; see the Agentforce pre-launch testing checklist.
Pilot, then hand over
Release to a limited audience or channel, review failed conversations with the service team, and hand runbooks and test suites to the people who will own the agent.
What the Salesforce org needs before agent work starts
None of these need to be perfect. Each one that is missing becomes the first task of the project instead of a surprise in the pilot.
Why first Agentforce agents stall
Too many subagents too soon
Early signalSimilar requests land in different subagents from one test run to the next.
MitigationStart with one or two subagents with clearly distinct descriptions, and add more only when tests show the router keeps them apart.
Business rules written as instructions
Early signalThe agent usually applies a refund limit, but now and then it does not.
MitigationMove rules that must always hold into Flow, Apex or Agent Script, which Salesforce positions as the place for control rather than behavior1.
An over-permissioned agent user
Early signalThe agent can read records no rep in that queue could open.
MitigationGive the agent user a narrow permission set and test data access as that user before launch.
No write-back, so no visible value
Early signalConversations happen, but case fields and reports look unchanged.
MitigationDefine the fields the agent must update and report on them from the start of the pilot.
Usage that nobody forecast
Early signalConsumption grows faster than conversations because actions loop or retry.
MitigationTrack actions per conversation during the pilot; program-level budgeting sits with the Center of Excellence work.
Frequently asked questions
How is an Agentforce agent different from an Einstein bot?
Einstein bots follow dialogs that an administrator designs step by step. Agentforce agents use a reasoning engine that classifies each request into a subagent and chooses actions, which copes better with open-ended language but needs more testing. Many service teams keep deterministic dialogs or Flows for fixed processes and use an agent only where interpreting free text adds value.
Do we need Data Cloud before starting with Agentforce?
Salesforce's current guide describes Data 360, the product formerly called Data Cloud, as provisioned by default for Data Library automation, which indexes and chunks knowledge for retrieval actions such as answering questions with knowledge1. Further Data 360 features, such as external data sources and real-time data graphs, are optional and depend on what the agent must read1.
Can an Agentforce agent act in systems outside Salesforce?
Yes, through actions. Salesforce lists MuleSoft API and External Service actions for calling external systems and REST APIs described with OpenAPI, and notes that both need additional licenses2. Flow and Apex actions can also call other systems. Whatever the route, the external call should validate its inputs and return a result the agent can explain to the customer.
Is one agent enough, or do we need a Center of Excellence?
Start with one well-scoped agent when one team owns the process and the data. A Center of Excellence becomes worthwhile when several teams want agents and would otherwise build duplicate actions, separate testing habits and budgets nobody has forecast. Our Center of Excellence page covers that program-level work, from portfolio choice to shared standards.
What do we receive at the end of an Agentforce implementation?
The use-case design for the CRM workflow, the integrated actions and knowledge, and a service-team evaluation and handover, which are the deliverables listed for this work4. In practice that includes the agent design document, the test suites and the runbooks your administrators need to keep changing the agent safely after the pilot.
Sources
- The Agentforce Guide to Context Engineering — Salesforce
- Legacy Guide: Agentforce Reasoning, Subagents, Instructions, and Actions — Salesforce
- Explore agent testing tools and considerations — Salesforce Trailhead
- Salesforce Agentforce: CRM agent use-case design, action and knowledge integration, evaluation and handover — ColdAI
Connect the architecture
The next connection.
Explore the complementary capabilities that can turn an individual technology into a complete workflow.
Your next move
Bring us the
real problem.
A workflow that takes too long. A system that cannot connect. An idea that needs a technical path. Start there, and we can define what to investigate, build and measure.
- An identified CRM workflow
- Reliable records and knowledge
- Salesforce administrators and process owners