How to Build an Agentforce Agent (And Why Most No-Code Builds Fail at Step 3)

Your Agentforce Demo Impressed the Board. Your Production Agent Just Told a Customer Their Order Was Cancelled. It Wasn't.

You watched the Salesforce Agentforce demo. You typed "Create an agent that reviews meetings and suggests talking points" into Agent Builder. The AI built topics, actions, and guardrails in minutes. No Apex. No prompt engineering.

The board loved it. The CDO approved the budget. The pilot began.

Three weeks later, your service agent told a customer their $50K enterprise contract was expired. It wasn't. It renewed last month. The agent pulled the wrong contact record—one of three duplicates in your CRM—and confidently synthesized a wrong answer.

This is not a bug. This is what happens when you skip the foundation.

At Implementology, we build Agentforce agents for mid-market B2B companies. In the last 12 months, we've rescued 9 stalled Agentforce pilots. The pattern is identical every time: the no-code build took 3 days. The data cleanup took 6 weeks. The deployment never happened.

This guide is the build manual we wish existed when we started. It covers the 8-step process, the three prerequisites everyone skips, the production deployment trap, and the exact decision framework for when to build in-house versus bring in a partner.

The No-Code Mirage (And the Foundation It Hides)

Agentforce Builder is genuinely no-code. You describe what you want. The Atlas reasoning engine generates topics, suggests actions, and writes instructions. A sales manager can build a lead-qualification agent in an afternoon.

But no-code does not mean no foundation. The builder doesn't create data. It consumes it. If your CRM has duplicate contacts, stale opportunities, and knowledge articles from 2022, your agent will serve wrong answers with complete confidence.

The Einstein Trust Layer masks PII and secures prompts. It does not fix dirty data. It makes dirty data sound authoritative.

You might think: "We'll clean the data after we prove the agent works."

Here's why that assumption creates the exact failure pattern we're discussing: An agent grounded in dirty data doesn't fail gracefully. It doesn't say "I'm not sure." It synthesizes partial records into coherent, wrong answers. By the time you discover the error, the customer has already escalated to a human—angrier, with screenshots.

No-code means the governance has to happen before you open Agent Builder. Not after. Not during. Before.

The 3 Prerequisites Nobody Checks

Before you create a single topic, confirm these three things. Skipping them is the #1 reason pilots become rescue engagements.

Prerequisite 1: Clean Data (Not "Good Enough" Data)

Agentforce reads from the same objects your reps use: Contact, Account, Opportunity, Case, Knowledge. If those objects have duplicates, null fields, or stale records, your agent inherits every problem.

The 5-minute data audit:

Check	How to Check	Pass Threshold
Duplicate contacts	Run duplicate rules in Setup	<5% duplicates
Null email/phone on contacts	Report: Contacts with blank email OR phone	<10% null
Stale opportunities	Report: Open opps with no activity >90 days	<15% stale
Orphan cases	Report: Cases with no contact link	<3% orphan
Knowledge article age	Report: Articles last modified >18 months ago	<20% old

Fail more than two checks? Stop. Clean first. Build second. We run Data Cloud readiness audits that surface exactly which records are poisoning your agent's grounding data.

Prerequisite 2: Data Cloud (The Hidden Gate)

Salesforce says Data Cloud is "recommended." For production, it's a prerequisite.

A basic Agentforce agent can run on core CRM data alone. But production use cases—identity resolution across CRM and ERP, unified customer profiles, behavioral grounding, calculated insights-require Data Cloud as the foundation. Without it, your agent answers from fragmented records. It recommends products to customers who already bought them. It escalates cases with half the context.

The rule: If your use case needs unified profiles or external data, Data Cloud is not optional. It is the foundation. We cover the Data Cloud → Agentforce connection in our implementation rescue guide.

Prerequisite 3: A Sandbox Deployment Pipeline

Building directly in production is reckless. Agentforce metadata-topics, actions, prompt templates, permission sets—must be version-controlled, tested, and deployed via Salesforce CLI.

If your team doesn't have a sandbox-to-production pipeline for metadata, you are not ready to build. You are ready to break things in front of customers.

The 8-Step Build (What Actually Happens in Agent Builder)

Step 1: Define One Use Case in One Sentence

Not three use cases. Not "AI everywhere." One.

"This agent qualifies inbound leads by scoring industry, company size, and last activity."

If you can't define it in one sentence, you're not ready to build. An agent that does everything does nothing well.

Step 2: Create the Agent

Setup → Agents → New Agent.

Pick a template. Salesforce ships pre-built templates: Service Agent, Sales Development Rep, Campaign Agent, Guided Shopping. Start with a template. Don't build from scratch unless you have a specific reason.

Name the agent. Link it to a dedicated Agent User—not your admin user. This separation matters for audit trails and permission scoping.

Step 3: Define Topics (Now Called Subagents)

As of April 2026, Salesforce renamed "Topics" to "Subagents." Same functionality. You may see both terms in documentation.

A topic is an intent category. It tells the Atlas engine: when a user asks about X, route to this set of actions.

Each topic needs:

• Classification description: The routing logic. Write this like you're explaining to a colleague when they should handle this request.

• Scope: What the topic covers—and explicitly what it does not.

• Instructions: How the agent behaves. Tone, what to check first, escalation rules.

  
  

The most common mistake: Vague classification descriptions. Write "Handles inbound leads from the website contact form, scores them based on industry and company size, and books a meeting if score is above 70"—not "Handles customer questions." The Atlas engine routes conversations based on these descriptions. Vague descriptions create vague routing.

Step 4: Add Actions

Actions are the tools your agent uses. Four types exist:

Action Type	When to Use	No-Code?
Standard Actions	Query records, summarize, send email	Yes
Flow Actions	Declarative automation via Flow Builder	Yes
Prompt Template Actions	LLM-powered text generation	Yes
Apex Actions	Complex logic, external API callouts	No

Rule: Check standard actions first. Build Flow actions only if standard actions can't handle it. Reserve Apex for complex logic that Flow can't express.

For Flow actions, build the Flow first in Flow Builder, then register it in Setup → Agent Actions. Tick "Show in Conversation" on at least one output—this surfaces results to the user and keeps them in the agent's memory for follow-up turns.

Step 5: Write Instructions (The Quality Determinant)

Instructions are not prompts. They are behavioral guardrails written in natural language.

Good instruction: "Before suggesting a product, check the customer's purchase history in the last 12 months. If they already own the product, recommend complementary accessories instead. Never recommend a product the customer already owns."

Bad instruction: "Be helpful and recommend products."

The difference is deterministic behavior. Good instructions produce consistent, testable outcomes. Bad instructions produce inconsistent, unpredictable answers.

Agent Builder now supports Agent Script—a language that combines natural language with programmatic expressions. You can add conditional steps, loops, and variable comparisons without writing Apex.

Step 6: Set Guardrails

Guardrails are your safety net. At minimum:

• Off-topic refusals: What the agent explicitly will not do.

• Escalation threshold: When the agent hands off to a human. We typically set this at 70% confidence.

• Data access limits: Which objects and fields the agent can read versus modify.

Step 7: Test Five Scenarios (Not One)

Use the Conversation Preview panel. Test these five scenarios before calling testing complete:

1. Happy path: User asks exactly what the agent was built for.

2. Edge case: User asks a related but unplanned question.

3. Off-topic: User asks something completely unrelated.

4. Ambiguous: User's intent could map to two different topics.

5. Adversarial: User tries to get the agent to reveal data or perform unauthorized actions.

If the agent fails any of these, refine the topic classification or add a conditional filter. Do not deploy until all five pass.

Step 8: Deploy to Production (The Step That Kills Most Pilots)

This is where no-code tutorials end. In reality, deployment is where the work starts.

Production deployment checklist:

1. Package metadata via Salesforce CLI. Retrieve topics, actions, Apex, Flows, prompt templates, and permission sets from sandbox.

2. Verify target org licenses. Confirm Einstein, Agentforce, and Data 360 are enabled in production.

3. Create the Agent User in production. Don't reuse the sandbox user.

4. Deploy metadata via CLI. Include all dependencies.

5. Activate flows. Ensure all deployed Flows are active at the correct version.

6. Assign permission sets. Add deployed permission sets to the Agent User.

7. Configure channels. If using Embedded Service or Messaging, publish the deployment.

8. Validate end-to-end. Run the same five test scenarios from Step 7 in production.

If this checklist feels like more than your team wants to handle internally, our Agentforce Quickstart Package includes sandbox-to-production deployment, permission set auditing, and 30-day post-launch monitoring.

The "Works in Sandbox" Trap

You've tested. You've deployed. You activate the agent. And in production, it gives completely different answers.

Three reasons why:

1. Production data is dirtier than sandbox. Sandbox is often a partial copy with clean sample data. Production has 12 years of duplicates, merged accounts, and orphan contacts.

2. Permission sets are broader in production. In sandbox, you tested with admin permissions. In production, the Agent User has field-level security restrictions you forgot to replicate.

3. Channels behave differently. Testing in the Agent Builder preview panel is not the same as testing in Embedded Chat on your public website. Channel context changes routing behavior.

The fix: Soft launch. Deploy to one channel, one user segment, one geography. Monitor for 48 hours. Fix what breaks. Then scale.

The Stakeholder Translation

For Your CDO	For Your Salesforce Admin	For Your AI Architect
Focus on the 3 prerequisites and the production deployment checklist.	Focus on Step 3 (topic classification) and Step 4 (action types).	Focus on Step 5 (instructions/Agent Script) and Step 8 (CLI deployment).
The board wants to know: "Is our data clean enough for AI?"	The admin needs to know: "Which template do I pick, and how do I route intents?"	The architect needs to know: "When do we hit Apex, and how do we version-control metadata?"

When to Build vs. When to Call a Partner

Factor	Build In-House	Call a Partner
Use case complexity	Single topic, standard actions only	Multi-topic, custom Apex, external APIs
Data quality	Passed all 5 audit checks	Failed 2+ checks, duplicates >10%
Data Cloud readiness	Already deployed and stable	Not deployed, or match rate <40%
Deployment pipeline	Sandbox → CI/CD → Production	No CLI experience, no version control
Timeline	Flexible (8+ weeks)	Fixed deadline (Dreamforce, board mandate)
Agentforce experience	Built 2+ agents previously	First agent, no Einstein experience

If you're building in-house, start with the prerequisites checklist. Fail any check? Address it before opening Agent Builder. If your Data Cloud match rate is below 40%, or you have no sandbox deployment pipeline, bring in a partner for at least the architecture phase.

FAQ

Q1: Does Agentforce require coding?

A: No for basic agents. Agent Builder is no-code for standard actions, Flows, and prompt templates. Complex logic requiring external API callouts or custom scoring needs Apex.

Q2: Do I need Data Cloud for Agentforce?

A: You can start with core CRM data. For production deployments requiring unified profiles, external data grounding, or calculated insights, Data Cloud is a prerequisite.

Q3: How much does Agentforce cost?

A: Salesforce Foundations offers a free entry point for Enterprise Edition with 1,000 conversations and 250K Data Cloud credits. Production pricing uses Flex Credits, with Agentforce Service Agent starting at approximately $2 per conversation.

Q4: How long does it take to build an Agentforce agent?

A: A focused pilot with one use case can go live in 2–3 weeks if data is clean and prerequisites are met. Most stalled pilots we see took 8+ weeks because teams skipped prerequisites and had to rebuild topics after discovering data quality issues.

Q5: What is Agent Script?

A: Agent Script is the language for building agents in Agent Builder. It combines natural language with programmatic expressions—conditions, loops, variable comparisons, so you can enforce deterministic behavior without writing Apex.

Q6: Can I deploy directly from Agent Builder to production?

A: No. Production deployment requires Salesforce CLI to package and deploy metadata, verify licenses, create Agent Users, and activate flows. Building directly in production is not recommended.

AGENTFORCE PILOT STALLING AT DEPLOYMENT?

We build production-ready Agentforce agents in 3–4 weeks, from use-case definition through sandbox testing to production deployment. Includes Data Cloud readiness audit, topic architecture, and 30-day post-launch monitoring.

→ Talk to Our Agentforce Team