Get in Touch

Category: Agentforce

  • Grounding Agentforce responses: retrieval patterns that stop an agent making things up

    Agentforce will answer a question whether it knows the answer or not. That’s the part teams miss when they go from a demo to production. In the demo, someone asks a question the agent happens to be grounded for, gets a clean answer, and everyone nods. In production, a customer asks something slightly off to the side of what the knowledge base covers, and the agent fills the gap with something plausible-sounding and wrong. Nobody flagged it because the answer read fine.

    Grounding is the fix, and it’s not one setting. It’s a set of retrieval patterns you have to choose deliberately, test against real questions, and keep auditing after go-live. Get it wrong and you’ve built a confident liar with a Salesforce logo on it.

    What grounding actually does

    An Agentforce topic doesn’t reason from nothing. Before the model generates a response, Salesforce retrieves content it thinks is relevant (Knowledge articles, Data Cloud records, data from a prompt template) and stuffs it into the context the model sees. The model’s job then becomes summarising and rephrasing that retrieved content, not inventing facts. Strip the retrieval step out, or retrieve the wrong thing, and the model falls back on its training data and whatever pattern-matching gets it to a fluent-sounding answer.

    That’s the whole mechanism. Retrieval-augmented generation isn’t exotic. It’s giving the model the right paragraph at the right moment so it has something true to paraphrase instead of something to guess.

    The retrieval patterns worth knowing

    Knowledge grounding

    The simplest pattern: point a topic at a Knowledge action, let Salesforce’s built-in relevance search pull matching articles, and let the model summarise them. This works well when your Knowledge base is actually current and well-tagged. It falls apart fast when articles are stale, contradictory, or written for internal agents rather than customers. I’ve seen a contact-centre team ship this straight from a Knowledge base that hadn’t had a content audit in two years. The bot was technically grounded. It was grounded in wrong information, confidently delivered.

    Before you turn this on, run a content audit. Not a vibe check, an actual pass through the top fifty articles your topic will retrieve from, checked against what’s actually true today.

    Data Cloud vector search

    For anything beyond FAQ-style content, you’re grounding against a vector database built from Data Cloud: unstructured documents chunked and embedded, searched by semantic similarity at query time. This is where most of the real engineering work lives. Chunk size matters more than people expect. Chunk too large and you retrieve a paragraph with the right answer buried in three unrelated ones, diluting the signal. Chunk too small and you lose the surrounding context that made the answer correct in the first place. There’s no universal number here. I’d start around 300 to 500 tokens per chunk with meaningful overlap, then tune against your own eval set rather than trusting a default.

    Metadata filtering is the other lever that gets ignored. If your vector index spans multiple products, regions, or policy versions, retrieval without a metadata filter will happily pull a correct-sounding answer from the wrong product line. Tag chunks at ingestion time and filter at query time. It’s unglamorous and it’s the difference between a grounded agent and one that’s grounded in the wrong document.

    Prompt template grounding

    The pattern that gets underused: grounding directly off record data through a prompt template, rather than off a document corpus at all. If the customer is asking “what’s my order status”, you don’t need semantic search over a knowledge article. You need the actual Order record merged into the prompt. This is deterministic, cheap, and nearly impossible to hallucinate against, because the field value either exists or it doesn’t. Reach for this first whenever the ground truth is a structured record rather than prose. Save vector search for the cases where the answer genuinely lives in unstructured text.

    Where teams get burned

    The most common failure isn’t a bad retrieval pattern. It’s confusing retrieval with validation. Grounding reduces the chance the model invents something, but it doesn’t guarantee the model only says what was retrieved. A model can still misread a retrieved chunk, blend two retrieved passages into a claim neither one makes, or answer a question the retrieved content doesn’t actually cover while sounding like it does. I’ve watched a demo agent cite a real, correctly retrieved article and still get the eligibility criteria backwards, because the article covered two scenarios and the model merged them.

    That’s why grounding and testing aren’t separable phases. You need an eval set: real questions, with the correct answer written down by a human who knows the domain, run against the agent regularly, not just before launch. Score for factual accuracy against the retrieved source, not just “did it answer in a reasonable tone.” A response can be fluent, on-brand, and wrong.

    A practical build order

    When I’m setting this up for a topic, the sequence is roughly: identify whether the ground truth is a record (use a prompt template, skip vector search entirely), a policy or process document (use Knowledge grounding, after a content audit), or genuinely unstructured and large (use Data Cloud vector search, with deliberate chunk size and metadata filters). Then write twenty to thirty real questions covering the edge cases your support team actually fields, not the easy ones. Run them before launch and after every content change, because grounding isn’t something you configure once. The source content keeps changing, and the retrieval behaviour needs to keep up with it.

    None of this requires exotic tooling. It requires treating “what does the agent actually know, and where did it come from” as a question you answer on purpose, every time, rather than something you assume because the demo went well.

  • Agentforce in a contact centre: where it helps the agent, and where it should stay out of the way

    A support agent picks up a call about a failed order. Before they’ve said a word, the case history, the customer’s last three interactions and a draft summary of the account are already sitting on screen. That’s Agentforce doing its job well: invisible, fast, and out of the customer’s way. Ten minutes later the same customer is angry about a refund policy exception, and the agent needs to read the room, bend a rule slightly, and say something that sounds human. That’s a different job entirely, and it’s not one Agentforce should be doing.

    I’ve spent years inside contact-centre Service Cloud orgs, and the pattern with Agentforce is becoming clear fast: the technology is genuinely good at a specific band of work, and genuinely bad at the work either side of that band. Knowing where that line sits matters more than any feature list Salesforce ships this year.

    Where Agentforce earns its place

    The strongest use cases I’ve seen all share one trait: they’re information-retrieval and drafting problems, not judgment problems.

    Summarising before the agent needs to ask

    Case summarisation is the easiest win in the whole platform. An agent opening a case with eleven prior interactions, three transfers and a product return doesn’t need to read all of that. They need the three facts that matter right now. Agentforce reading case history and surfacing a two-line summary saves real seconds on every single call, and seconds compound across thousands of calls a week.

    First-draft replies on routine requests

    Password resets, order status, standard policy questions: these have one correct answer and no emotional complexity. Letting Agentforce draft the reply and having the agent review and send it is faster than typing from scratch, and it’s lower risk than it sounds, because the agent is still the one hitting send.

    Routing and triage

    Classifying an inbound case by intent, urgency and the right queue is exactly the kind of pattern-matching large language models are built for. I’ve watched Omni-Channel routing improve meaningfully once case classification stopped depending on a customer picking the right dropdown option on a web form.

    Where it should stay out of the way

    The failure cases I’ve seen cluster around three things: emotional nuance, irreversible actions, and genuine edge cases the model has never seen framed quite that way.

    Anything with an angry or vulnerable customer

    An agent can hear tone shift in someone’s voice and adjust. A model reading transcript text is working from a much thinner signal. Handing de-escalation, retention conversations, or anything touching a customer in genuine distress to an autonomous agent is a bad trade even when the model gets the facts right, because the facts were never the hard part.

    Actions that can’t be undone

    Refunds above a threshold, account closures, data deletion requests: give Agentforce a narrow, well-tested action for these and it’ll happily execute it exactly as scoped. The risk isn’t the model being wrong occasionally. It’s that “occasionally” compounds fast when the action is irreversible and the volume is high. I treat any Apex action tied to money or data loss as something a human approves, full stop, no matter how good the surrounding prompt is.

    The exception that breaks the pattern

    Every contact centre has cases that don’t fit the normal shape: the customer who’s a VIP but isn’t flagged as one, the policy exception that was agreed on a call six months ago and never got written down, the integration that silently failed last Tuesday and left three systems disagreeing about the truth. Agentforce has no way to know what it doesn’t know. A human agent, at minimum, knows when something feels off.

    A rough framework for the line

    When I’m scoping where Agentforce should sit in a Service Cloud build, I ask three questions about the task:

    • Is there a single correct answer, or does the right answer depend on reading a person?
    • Can the action be reversed cheaply if the model gets it wrong?
    • Has this exact shape of request happened often enough that the model has real pattern density to draw on?

    Three yeses, and Agentforce can probably run with real autonomy. Two yeses, give it a supporting role with a human in the loop. One or zero, keep it out of the workflow entirely and spend the budget somewhere else.

    What this means for the build

    Practically, this changes how I scope Agentforce actions. I design the narrowest possible action for each task rather than one broad “handle the case” agent. A tight action that looks up order status is easy to test, easy to monitor, and easy to trust. A broad action that can also issue refunds, update addresses and escalate cases is none of those things, even if it demos beautifully.

    It also changes where I put the guardrails. Input validation on every Apex action an agent can call isn’t optional, because the agent will eventually call it with something you didn’t anticipate. And every action above a certain blast radius gets a human approval step before anything executes, not because I distrust the model specifically, but because that’s the same discipline I’d apply to any automation touching customer money or customer trust.

    None of this is an argument against Agentforce in a contact centre. It’s an argument for being precise about which parts of the job it’s actually solving. The agents who do this well in six months won’t be the ones who gave Agentforce the most access. They’ll be the ones who worked out, task by task, exactly where the model was reliable and designed everything else around a human doing what humans are still better at.

  • Flow orchestration for agents: handing a multi-step process to Agentforce safely

    An agent that calls one Apex action is easy to reason about. Give it a clear input, get a clear output, done. The trouble starts when you hand Agentforce something with five steps, two approval gates, and three ways it can fail halfway through. That’s not an action anymore. That’s a process, and Flow is where most Salesforce teams are reaching to let an agent run one safely.

    I’ve seen this go wrong two ways before it goes right. Either the Flow gets built the way it always has, screen-free but assuming a predictable caller, and the agent trips over edge cases nobody designed for. Or the Flow gets treated like a black box: wire it to an action, hope the agent passes sane inputs, and find out in production what “sane” actually meant.

    Why this isn’t just another autolaunched Flow

    A Flow built for a scheduled job or a button click has one caller, and that caller is predictable. A human clicking a button has already read the screen. A batch job runs against records that already passed a filter. Agentforce doesn’t give you either guarantee. It decides to invoke the Flow based on a conversation, so the inputs it hands over are only as good as the prompt, the topic instructions, and whatever grounding data it pulled that turn.

    That changes what the Flow needs to do before it does anything else: trust nothing coming in. Validate every input the way you’d validate a public API, not the way you’d validate a field that’s already constrained by a page layout and a validation rule.

    Three things to design before the happy path

    An input contract the agent can’t violate by accident

    Define exactly what the agent is allowed to pass, with types, required fields, and value ranges, as part of the action’s input parameters, not buried in Flow logic three screens deep. If a field should only ever be one of four picklist values, constrain it at the action level. An agent that free-types “urgent” into a priority field expecting “High” will do that eventually. Catch it at the boundary, not in a decision element nobody will debug at 9pm.

    A way to stop partway through without leaving a mess

    Multi-step Flows fail in the middle. A record updates, a callout times out, the fourth element in the chain throws. In a human-triggered Flow, a failure usually means the person tries again or logs a ticket. An agent-triggered Flow needs the same recovery path, except nobody’s watching it happen in real time. Build in checkpoints: a status field on the driving record that tracks which step last completed successfully, so a retry, whether triggered by the agent, a scheduled cleanup job, or a human reviewing a log, can pick up from where it actually broke instead of re-running steps that already succeeded.

    Idempotency, because the agent will call it twice

    Conversational agents retry. A timeout, a dropped connection, a user who asks the same thing two different ways in one session, and your Flow gets invoked again with the same or similar inputs. If step two creates a case and step four sends an email, a second run shouldn’t create a second case and send a second email. Check for an existing record before creating one. This is ordinary integration hygiene, and it matters more here than it did when the only caller was a trusted internal system.

    Where approval steps actually belong

    If the process needs a human sign-off before something happens, a refund over a threshold, a case escalation on a VIP account, anything touching financial data, don’t let the agent decide whether to pause for approval. Build the approval gate into the Flow itself, triggered by the data, not by the agent’s judgment about when something feels risky. The agent should know it can submit a request. It shouldn’t be the thing deciding whether that request needs a second pair of eyes. That decision belongs in business logic you control, versioned and testable, not in a prompt that someone can reword next week without telling you.

    Logging that helps you debug an agent, not just a Flow

    Standard Flow error emails and debug logs were built for admins debugging admin-triggered automation. When Agentforce is the caller, you need to know what the agent was asked, what it decided to pass in, and what the Flow did with it, all three, in one place you can actually query. I log the action name, the full input payload, the Flow interview GUID, and the final status to a custom object rather than relying on native fault emails. When something breaks three days later and the only report you get is “the agent said it couldn’t finish,” that log is the difference between a five-minute fix and a long afternoon reconstructing a conversation from debug logs that have already rolled off.

    Test it like an API, not like a form

    The usual Flow testing habit is to run it against a few representative records and eyeball the result. That’s not enough once an agent is the caller. Test it the way you’d test an integration endpoint: valid inputs, missing optional fields, wrong data types, boundary values, and the same call fired twice in a row. Where you can, write test invocations of the action itself, not just the Flow, that simulate what Agentforce would send on a bad day. A bad day is exactly when this will matter.

    The real shift

    None of this is new Flow capability. It’s the same orchestration tool doing what it always did, built with a different caller in mind. The teams getting this right aren’t running the fanciest Flow. They’re the ones who stopped assuming the caller is trustworthy by default and designed the contract first. Once that contract holds, handing a multi-step process to an agent stops being a risk you’re managing and starts being just another integration you’ve already solved before.

  • Zero Copy and Data Cloud: when you actually need it, and when a sync job still wins

    Every Data Cloud conversation I’ve had in the last year eventually turns to Zero Copy. Someone read a blog post, saw a demo, and now wants to know why the team is still running nightly batch jobs to move data into Salesforce when Salesforce says you don’t have to copy anything at all. It’s a fair question. The answer is less exciting than the marketing: Zero Copy is the right tool for a narrow set of problems, and a genuinely bad fit for most of the integration work a typical org still needs.

    I’ll say the quiet part up front. Zero Copy doesn’t mean “no copying happens anywhere.” It means Data Cloud can query data sitting in an external system, typically a data warehouse like Snowflake, Databricks, Redshift or BigQuery, without physically ingesting it into Data Cloud’s own storage first. Federated access, not teleportation. The data still lives where it lived. Salesforce reaches out and reads it on demand, or through a virtualised connection, instead of pulling a copy in and storing it locally.

    What Zero Copy is actually solving

    Three real problems, and they’re the ones worth checking your org against before you touch a connector.

    Storage and duplication cost

    Every record you ingest into Data Cloud takes up space and needs to be kept in sync. If your warehouse already holds ten years of transaction history and you only need the last 90 days visible inside a Salesforce flow, ingesting the full history is wasteful twice over: you’re paying for storage you don’t need, and you’re building a pipeline to keep a copy fresh that nobody asked for.

    Freshness

    Batch sync jobs run on a schedule. Hourly, nightly, whatever the pipeline was built for. If a contact-centre agent needs to see a customer’s current loyalty tier and that tier updates in near real time in the warehouse, a four-hour-old copy in Data Cloud is wrong exactly when it matters. Zero Copy queries the source directly, so the answer reflects what the warehouse has right now, not what it had at the last sync.

    Governance and single source of truth

    Some organisations have a hard rule, often from a previous audit finding, that customer financial or health data cannot be duplicated outside its system of record. Compliance teams like fewer copies, not more. Zero Copy lets Salesforce reference that data for a specific use case without creating another place it has to be secured, retained and eventually deleted.

    Where a sync job still wins

    This is the part that gets skipped in the demos. A traditional ingestion or sync pattern beats Zero Copy in a lot of ordinary situations, and pretending otherwise causes real problems six months later.

    Query volume and latency

    Federated queries go over the network to the source system, every time. If you’re building something that needs to evaluate thousands of records per second, inside a real-time decisioning flow or an Agentforce topic that fires on every page load, round-tripping to an external warehouse for each lookup adds latency you can’t always absorb. Ingested data sitting in Data Cloud’s own storage is fast because it’s local. That’s not a small detail. I’ve seen a well-intentioned Zero Copy design get quietly reverted after performance testing showed response times that were fine in a demo with ten records and unacceptable with ten thousand.

    Transformation needs

    If the data needs real shaping before it’s useful, identity resolution, calculated fields, harmonisation across multiple source systems, a batch pipeline that transforms on the way in is usually simpler to build, test and debug than trying to push that logic into a live federated query. Zero Copy is a read path. It’s not where you want to be doing heavy lifting.

    Source system availability

    A sync job decouples Salesforce from the warehouse’s uptime. If the warehouse has maintenance windows, rate limits, or occasional outages, a Zero Copy dependency means your Salesforce experience goes down with it. A local copy keeps functioning even when the source is briefly unreachable. For anything customer-facing, that resilience is worth more than the storage you save.

    Cost at scale, the other direction

    Zero Copy isn’t free. Federated queries against a warehouse usually cost compute on the warehouse side, and that cost scales with how often Salesforce asks. A high-frequency use case can end up more expensive querying live than it would have been ingesting a well-scoped subset once a day. Nobody puts that in the slide deck.

    A decision framework that actually holds up

    Before picking a pattern, I ask four questions, roughly in this order.

    • How often does this data actually change, and does the use case genuinely need to see it the moment it changes, or is “accurate as of last night” good enough?
    • What’s the query pattern: occasional lookups during a case or interaction, or high-frequency reads across a large population?
    • Does the data need transformation, joining or harmonisation before it’s usable, or is it already clean and query-ready at the source?
    • Is there a governance constraint that actively prohibits a second copy, versus a preference for “less duplication is nicer”?

    If the honest answers are: rarely changes, low query volume, minimal transformation, and no hard governance block, Zero Copy might genuinely save you a pipeline. If any one of those tips the other way, especially the query volume question, a conventional sync is probably the safer build, and it’s the one your team already knows how to monitor and fix at 2am when something breaks.

    What I tell clients

    Zero Copy earns a place in an architecture when it removes a specific, named pain: a duplication rule from compliance, a freshness gap that’s actually been reported as a problem, or a dataset so large that ingesting it was never going to be practical. It’s not a default. I’ve started treating it the way I treat any other integration pattern choice: pick it because the requirements point there, not because it’s the pattern with the most momentum in the ecosystem this quarter. A sync job that’s boring, well-tested and runs every night without surprises is still, for most orgs, the right answer most of the time.

  • Agentforce and PII: what a Salesforce technical lead needs to get right before go-live

    Most PII conversations on a Salesforce project happen before anyone builds anything: field-level security, sharing rules, maybe a Data Mask run before a sandbox refresh. Agentforce breaks that habit. An agent doesn’t just display a field on a page layout where a profile either sees it or doesn’t. It reads fields into a prompt, reasons over them, and sometimes writes them straight into a conversation transcript that sits in your org indefinitely. The access model you already trust stops being the whole story.

    I’ve seen teams get genuinely stuck here, not because the Salesforce security model is unfamiliar, but because it answers a different question than the one Agentforce is asking.

    The access model you have isn’t the access model the agent uses

    Field-level security and permission sets govern what a user can see through the UI and through standard API access. Agentforce actions and topics run under whatever permission the agent’s running user holds, which is often broader than any single human agent needs, because it has to cover every scenario the topic might encounter. A case summarisation action that needs the case description field will usually also have query access to everything else on that object, including fields nobody scoped it to touch.

    That’s the first gap: scope creep in the permission set backing the agent, not a flaw in Agentforce itself.

    Retrieval pulls in more than the page layout ever showed

    Grounding makes this worse in a specific way. When an agent retrieves records to answer a question, it’s not rendering a page layout with field-level security quietly hiding what a profile shouldn’t see. A SOQL query inside an action or a retriever against Data Cloud returns whatever fields the query asks for, and it’s easy to write that query broadly “just in case” during development and never trim it back. I’ve reviewed actions that pulled ten fields off a Contact record to answer a question that needed three. Two of the surplus seven were PII with no business reason to be in that prompt at all.

    Where PII actually leaks once an agent is live

    Three places, in practice.

    Conversation transcripts. Agentforce logs what it reasoned over and what it said, and that log persists. If a customer’s date of birth or a national ID number passed through an action during the conversation, it’s sitting in the transcript object now, subject to whatever retention and access rules you set for that object, which on a lot of orgs is “whatever the default was.”

    Cross-object grounding. An agent answering a billing question might ground against Data Cloud profiles that unify data from several sources. Identity resolution can quietly merge a field that was masked on one system of record with an unmasked copy that arrived through a different ingestion path. Nobody intended that, and nobody will notice until someone asks why a customer’s unmasked phone number showed up in a response from an org where phone numbers are supposed to be protected.

    Third-party model calls. If any part of the topic routes through an external LLM provider rather than staying inside Salesforce’s Trust Layer boundary, you need to know exactly what left the org and under what data processing terms. Most Agentforce deployments stay inside the boundary. Confirm it rather than assume it, especially if a custom action calls out to another service.

    What to actually check before go-live

    This isn’t a theoretical list. It’s what I walk through on a release:

    • Pull the permission set or permission set group backing the agent’s running user and diff it against the fields each topic’s actions genuinely need. Strip the rest.
    • Read every SOQL query inside every action. If it selects more fields than the prompt or the response uses, narrow it.
    • Check the retention policy on conversation transcript objects and who has read access to them. Treat that list the same way you’d treat access to a case history with sensitive notes, because functionally it is one.
    • Test with masked data in a full sandbox refresh before go-live, not a partial copy. An agent behaves differently against realistic volume and realistic messy data than against twelve clean test records.
    • Confirm which calls, if any, leave the Trust Layer boundary, and get that in writing from whoever owns the integration, not just a verbal “yeah it’s fine.”
    • Walk through what happens when the agent gets something wrong with a real customer’s sensitive data mid-conversation. Is there a human escalation path that doesn’t require someone to dig through a transcript to understand what happened?

    Code review needs a new question

    When I review an Agentforce action or a custom Apex class behind one, I’ve added a question I didn’t used to ask: what does this expose that a human doing the same task manually wouldn’t have pulled up? A service rep looking at a case pulls up the case. They don’t typically also load the customer’s full contact record, their order history, and three related cases just to answer one question, because there’s a cost to clicking through all that. An agent pays no such cost. It’ll query everything it’s allowed to query if the action lets it, and that difference in behaviour is exactly where PII exposure creeps in without anyone deciding it should.

    Governance for this doesn’t need to be heavy. It needs an owner. Someone signs off on what each agent action is allowed to touch, and that sign-off gets revisited when the topic changes, not just at initial build. On most projects I’ve worked, that owner is the technical lead, because nobody else is reading both the permission model and the prompt logic closely enough to catch where they disagree.

    None of this is an argument against building with Agentforce. It’s an argument for treating the data model review as part of the build, the same way you’d treat a security review before any other release, rather than something you circle back to once an agent is already answering real customers.

  • Long-running agents: what changes when Agentforce pursues a goal over days, not one request

    Every Agentforce conversation I’ve seen so far, in demos and in real builds, ends in minutes. A customer asks something, the agent reasons over a topic and some actions, and it answers. Long-running agents break that assumption. The goal isn’t answered in one turn. It might take three days, span a dozen system checks, and need to pick back up after a human went to lunch, a batch job finished overnight, or an approval sat in someone’s queue until Thursday.

    That’s a different engineering problem, not just a longer conversation. And it changes what a Salesforce technical lead actually has to design for.

    What “long-running” actually means here

    A short-running agent interaction has a request, some reasoning, maybe a tool call or two, and a response. State lives in the session and dies with it. A long-running agent holds a goal across multiple sessions, multiple triggers, and gaps of real time where nothing is happening at all. Think: “resolve this customer’s billing dispute,” not “answer this customer’s question about their bill.”

    Resolving the dispute might mean raising a case, waiting for a credit approval that takes two business days, checking back when the approval lands, applying the credit, and then confirming with the customer a week later that it’s done. No human is sitting there watching the whole thing. The agent has to know where it left off every time it wakes up.

    The state problem nobody puts in the demo

    Most Agentforce demos show a topic, a few actions, a clean answer. What they don’t show is what happens to the agent’s understanding of the goal between step two and step seven, three days apart. You need a durable record of: what was the original goal, what’s been tried, what’s pending, what’s the next trigger that should wake this thing up. That’s a data model problem, not a prompt engineering one, and it belongs on your org’s objects, not buried in a context window that resets.

    I’d model it as a first-class record, something like an Agent Task or Agent Goal object, with a status picklist, a reference to the triggering case or opportunity, and a related list of the steps the agent has taken so far. Give it the same rigor you’d give a case lifecycle. Because that’s effectively what it is.

    Where the real risk sits

    Short-running agents fail loudly and immediately. You see the wrong answer in the chat window and you fix it. Long-running agents can fail quietly for days before anyone notices, because nobody’s watching a conversation that isn’t happening in real time.

    The failure modes I’d actually worry about:

    • An agent that’s waiting on an external event (an approval, a callout response, a batch completion) and never gets woken up because the trigger that should resume it didn’t fire.
    • An agent that retries a step it already completed, because its record of “what’s been done” drifted from what actually happened in the org.
    • An agent that’s technically still “in progress” according to its own status field, three weeks after the customer gave up and called support directly.
    • Two separate long-running processes both acting on the same case because neither checked whether the other had already claimed it.

    None of these show up in a quick test. They show up in production, slowly, and they’re the kind of thing a support team discovers when a customer calls in furious about something Salesforce thought it had already handled.

    Timeouts and dead-letter handling, not optional

    Every long-running goal needs an expiry. If an agent is waiting on an approval that was supposed to take two days and it’s been nine, that’s not a quiet background process anymore, that’s an escalation. Build the “this has gone stale” check as deliberately as you’d build the happy path. A contact-centre team I worked with learned this the hard way with a long-running case escalation flow, not an agent, but the same principle: anything that waits across sessions needs a heartbeat and a timeout, or it becomes invisible debt that resurfaces as an angry phone call.

    What this changes about how you build the action layer

    Short-running agent actions can assume a clean, present-tense context: here’s the customer, here’s the case, go. Actions built for long-running goals need to assume the opposite. They need to be safe to call more than once (idempotent), they need to record enough of what they did that a resumed agent can tell “already done” from “not yet attempted,” and they need a way to signal “I’m waiting on something external” rather than just returning and losing the thread.

    That pushes real design work back onto your Apex actions and Flow orchestrations. If you’re exposing an action to an agent that might call it, wait days, then call a follow-up action, you can’t design it the way you’d design a single-request integration. You need a correlation ID that survives the gap, and you need the receiving system (yours or a third party’s) to be able to answer “what’s the status of the thing you asked me to do” rather than just “here’s what happened when you asked.”

    Observability has to span the whole goal, not one session

    Debugging a short-running agent means reading one transcript. Debugging a long-running one means reconstructing a timeline: what was the goal on day one, what changed on day two, why did it sit idle for 36 hours, what finally triggered the resumption. If your logging only captures individual agent sessions, you’ve got gaps in the story exactly where the interesting failures live. Build the audit trail at the goal level, update it at every state transition, and make it queryable by the goal record, not just by transcript ID.

    Practical starting point

    If you’re building toward this rather than already in it, start smaller than “fully autonomous multi-day agent.” Pick one process in a typical enterprise org that already has a natural multi-step, multi-day shape, something like a credit approval or an onboarding checklist, and model the state explicitly before you hand any of it to an agent. Get the status object, the timeout logic, and the resumption trigger working as a deterministic Flow first. Once that skeleton is solid, the agent is just a smarter decision-maker sitting on top of state you already trust. Build the agent before the state model is solid, and you’ll spend your first few months firefighting things that were never really about the AI at all.

  • Job-ready agents like Casey and Hunter: evaluating a prebuilt agent against a custom build

    Salesforce ships Casey and Hunter as finished employees, not building blocks. Casey handles service conversations, Hunter chases sales leads, and the demo makes both look ready to drop straight into a contact centre or a pipeline review. The pitch is simple: skip the months of topic design and action wiring, hire the agent, point it at your data, done. For a lot of orgs that pitch is close enough to true. For plenty of others it isn’t, and the gap between those two groups is where I spend most of my Agentforce conversations lately.

    What “job-ready” actually means

    Job-ready doesn’t mean zero configuration. It means Salesforce has already made the decisions you’d otherwise spend weeks making yourself: which topics exist, what instructions sit under each one, which standard actions get called, and roughly what tone the responses take. You’re still connecting data, setting guardrails, and testing against your own cases. What you’re not doing is designing the agent’s reasoning structure from a blank canvas.

    That’s a real head start. I’ve sat through enough early Agentforce builds to know that topic design is where teams lose the most time, not model tuning, not UI work. Getting the boundaries between topics right, so the agent doesn’t try to handle a billing dispute through the shipping-status topic, takes iteration most teams underestimate. Casey and Hunter arrive with that iteration already done, for the scenarios Salesforce built them around.

    Where the prebuilt path earns its keep

    If your service org runs reasonably standard Case and Knowledge processes, Casey will get you to a usable pilot faster than a custom build, often by weeks. Same goes for Hunter against a fairly standard Lead and Opportunity motion. Three situations where I’d lean toward the prebuilt option without much hesitation:

    • You need a working agent in front of stakeholders inside a sprint or two, and the use case is close to the standard pattern.
    • Your data model hasn’t drifted far from Salesforce’s defaults, so the standard actions actually find what they’re looking for.
    • You want a reference implementation to learn against before committing to a bigger custom investment.

    That third one matters more than people give it credit for. Standing up Casey against a sandbox, even one you know you’ll outgrow, teaches your team how topics, instructions and actions actually behave together. It’s cheaper training than a six-week discovery workshop.

    Where it hits a wall

    The wall shows up fast once your process deviates from what the agent assumes. A contact-centre team I worked with routes cases through four separate queues based on entitlement tier, language, and a product-specific escalation flag that lives on a custom object. Casey’s standard case-handling topic has no concept of that flag. You can extend it, Salesforce does let you add custom topics and actions alongside the prebuilt ones, but at that point you’re doing custom build work anyway, just inside someone else’s scaffolding.

    The same thing happens with Hunter wherever territory rules, custom scoring, or a non-standard opportunity stage model sit between a lead and a qualified deal. The agent isn’t wrong. It’s just reasoning against a model of your sales process that your actual sales process doesn’t match.

    The real evaluation question

    Most teams frame this as prebuilt versus custom, as if it’s a single irreversible choice made in a steering committee meeting. It isn’t. The honest question is narrower: how much of this specific use case matches the standard pattern Salesforce designed for, and how much is the customisation that made your org worth customising in the first place?

    I run four questions before recommending either direction, and I’d encourage any technical lead to do the same rather than taking the vendor comparison at face value.

    Four questions worth asking before you commit

    • Does the core object model match? If cases, leads, and the fields that drive routing are close to standard, the prebuilt agent’s assumptions hold. If you’ve heavily customised the objects those topics depend on, you’re fighting the agent’s model of reality from day one.
    • Who owns the topic boundaries long term? Prebuilt topics are maintained by Salesforce, which means they change on Salesforce’s schedule, not yours. A custom build is entirely yours to extend, which costs more upfront and less in year two if your process keeps moving.
    • What’s the actual cost of a wrong answer here? A billing agent that mishandles a refund calculation needs tighter guardrails than one recommending a knowledge article. Prebuilt agents come with sensible defaults, not your specific risk tolerance.
    • How much of the value is in the exception handling? If 80% of your volume is the standard case and 20% is the reason you built a bespoke process, ask whether that 20% is actually the part worth automating. Sometimes it’s the part that should stay with a human.

    A framework I actually use

    In practice I treat Casey and Hunter as a starting position, not a final answer. Stand up the prebuilt agent against a slice of real traffic, maybe 10-15% of inbound service cases or a single sales segment, and measure where it succeeds unassisted versus where it hands off or gets the answer wrong. That gives you an actual number instead of a guess: if the standard topics resolve 70% of volume cleanly, custom work only needs to cover the remaining 30%, which is a much smaller and more honest scope than “replace the whole process.”

    If that number comes back low, under 40% say, that’s useful information too. It tells you your process is customised enough that a ground-up build, with topics designed around your actual case types rather than Salesforce’s assumed ones, will pay for itself faster than extending something that was never shaped for your data in the first place.

    Either way, don’t skip the measurement step and jump straight to a build decision based on how the demo looked. Demos are built on clean data and the exact scenario the agent was designed to handle. Your production queue is neither.

    What this means for the technical lead in the room

    The job here isn’t picking a side in the prebuilt-versus-custom debate before it starts. It’s running a short, honest test against real cases, reading the result without bias toward whichever option looked more impressive in a vendor session, and scoping the custom work to the gap that’s actually there. Most orgs end up somewhere in between: a prebuilt agent carrying the standard flow, with a handful of custom topics bolted on for the handling that made their process worth building in the first place. That’s not a compromise. For most Salesforce orgs with any operating history, it’s the correct answer.

  • AgentExchange and the rise of prebuilt agents: build, buy, or customise?

    Salesforce launched AgentExchange as the marketplace for Agentforce: prebuilt agents, actions and templates you can install instead of building from scratch. The pitch is familiar if you’ve been around Salesforce long enough. AppExchange did the same thing for apps fifteen years ago. Install instead of build, and get to value faster.

    The question that actually matters isn’t “should I use AgentExchange.” It’s which decision applies to the thing in front of you: build it yourself, buy something off the shelf, or buy something and then rework it until it fits. Most teams default to one answer regardless of the situation. That’s the mistake.

    What’s actually on AgentExchange

    Listings fall into a few buckets. Fully packaged agents aimed at a specific job, like a service agent or a sales research agent. Agent actions, smaller building blocks you drop into your own agent. And templates: a starting structure for topics, instructions and guardrails that you still have to configure for your org.

    The marketing treats all three the same way. They’re not the same decision at all. A packaged agent is closer to installing an app. An action is closer to installing a library. A template is closer to downloading someone else’s starting notes.

    Build, buy, or customise

    Three honest options, and most orgs land in the third one more often than they expect.

    Buy wins when the job is generic

    If the task doesn’t touch anything specific to how your org runs, a prebuilt agent is usually the right call. Lead qualification against standard fields. Case summarisation. FAQ-style support questions where the knowledge base is already clean. These are commodity problems. Paying to solve them yourself is paying to reinvent something a vendor has already tested against thousands of orgs.

    The failure mode here is skipping evaluation because the install was easy. An easy install doesn’t mean the agent’s reasoning matches your process.

    Build wins when the logic is the differentiator

    If the value sits in how your org actually makes a decision, not whether a decision gets made, build it. A contact-centre team I worked with had a triage process that weighted case severity, customer tier and SLA exposure in a specific order, tuned over years. No off-the-shelf agent was going to replicate that without being rebuilt into something custom anyway. At that point, you’re not saving effort by starting from a template. You’re adding a translation step.

    Build also wins when the data behind the agent is genuinely unusual. If your object model, your Apex business logic or your approval chains don’t look like anyone else’s, a generic agent will either ignore that complexity or get it wrong.

    Customise is where most of this actually lands

    In practice, a lot of AgentExchange installs end up as a customise decision whether or not anyone planned it that way. You install a packaged agent, discover it’s 70% right for your process, and then start rewriting instructions, swapping actions and adding guardrails until it matches. That’s fine. It’s often faster than building from nothing. But budget for it as a build, not an install. Teams that treat a prebuilt agent as finished the moment it’s installed end up shipping something that technically works and practically annoys every user who touches it.

    What to check before you trust a prebuilt agent

    A few things matter more than the demo:

    • Where does it get grounded? If it’s pulling from Data Cloud, your data quality becomes its accuracy ceiling, no matter how good the agent’s reasoning is.
    • What actions can it actually take? A read-only agent and a write-access agent are different risk profiles. Know which one you’re installing before you see what it does in production.
    • Can you see its reasoning? If the vendor can’t show you why it made a call, you can’t debug it when it makes a wrong one, and it will eventually make a wrong one.
    • Who maintains the underlying logic? A vendor update to a packaged agent can change its behaviour without you touching anything. That’s a different maintenance burden than code you own.

    None of this is unique to AgentExchange. It’s the same diligence you’d apply to any third-party integration. The difference is that an agent making a wrong call is harder to spot than an integration throwing an error. A failed callout shows up in the logs. An agent that quietly routes a case to the wrong queue, or summarises a complaint in a way that drops the part that mattered, just looks like a slightly bad outcome. Nobody gets paged for that.

    The actual decision framework

    Before installing anything, answer three questions. Is the underlying process generic across orgs, or specific to how we run things? Does getting it wrong cost us a bad customer interaction, or something worse, like a compliance or financial problem? And are we prepared to own the maintenance of whatever we install, the same way we’d own a build?

    If the process is generic and the stakes are low, buy and move on. If either answer tips the other way, plan for build or customise from the start rather than discovering it three months in, once the packaged agent can’t be stretched any further.

    AgentExchange is going to keep growing. The marketplace model works, and Salesforce has every incentive to make it the default path into Agentforce. That’s a reasonable thing for a platform to want. It’s not a reason to skip the evaluation most teams would already run on any other third-party tool going into a production process.

  • Giving an agent permission to act: designing the guardrails before Agentforce gets write access

    Every Agentforce rollout starts the same way: read access first, a few topics, a demo that goes well. Then someone asks the obvious next question. Can it actually update the case? Can it process the refund, not just look it up? That’s the moment the project gets real, and it’s also the moment most teams realise they don’t have an answer ready.

    I’ve sat in that meeting more than once. The agent works fine in read-only mode because read-only mode forgives almost everything. A bad query returns the wrong record and someone notices on screen. Write access doesn’t forgive. A bad write closes the wrong case, double-refunds a customer, or fires an email to the wrong contact, and by the time anyone notices, it’s already happened.

    Why write access changes the risk profile

    A human agent who makes a mistake usually makes one mistake. They’re slow, they second-guess themselves, and they ask a supervisor when something feels off. An AI agent with write access and a bug in its reasoning can make the same mistake a hundred times in the time it takes you to notice the first one. That’s the actual argument for guardrails: not that the agent is untrustworthy in some abstract sense, but that its error mode is different in kind from a human’s. Scale is the risk, not intent.

    This is why “it worked in the demo” tells you almost nothing about whether it’s safe to give an agent write access. The demo ran one happy path, once, with someone watching. Production runs every path, continuously, with nobody watching the individual transaction.

    The guardrails that actually matter

    Scope the permission set to the job, not the object

    The standard Salesforce instinct is to grant edit access on a case or an account and call it done. Don’t. Build a permission set that matches exactly what the agent’s topic is meant to do: update status on a specific case type, not edit any field on any case. If the agent’s job is to update delivery status on an order, it has no business editing the billing address on that same record, even though both fields sit on the same object. Narrow the permission set until the agent literally cannot do the thing you didn’t intend it to do, rather than trusting it won’t try.

    Put validation in the data layer, not the prompt

    A system prompt that says “don’t process refunds over $500” is an instruction, not a control. Agents misread instructions, and a cleverly worded customer message can talk an agent out of a soft rule faster than you’d expect. The actual limit belongs in a validation rule, a flow, or an Apex trigger on the object itself, somewhere the agent can’t negotiate with it. Let the agent attempt the action. Let the platform reject it if it breaks the rule. The agent should never be the only thing standing between a customer and a bad outcome.

    Build an approval step for anything you can’t undo

    Some actions are cheap to reverse: updating a case description, adding a note, re-routing a routine enquiry. Others aren’t: a refund, a contract change, anything that sends an external communication. For the second category, the agent should request the action and a human should approve it before it fires, at least until you’ve got enough production history to trust the pattern. This slows the agent down on the actions that matter and leaves it fast on the ones that don’t, which is the right trade.

    Log what it did and why, not just that it did something

    Standard field history tells you a value changed. It doesn’t tell you which topic triggered the change, what the customer said that led to it, or what the agent’s reasoning was at the point of action. Without that, every incident review turns into guesswork. Set up logging that captures the triggering input, the action taken, and a short reasoning trace, and keep it somewhere a support team can query quickly. The first time an agent does something wrong in production, you’ll want this a lot faster than you’ll want to build it.

    Testing before the switch flips

    Testing an agent with write access isn’t the same exercise as testing a flow. A flow does the same thing every time you give it the same input. An agent can take a slightly different path through the same conversation twice, so a single pass of test cases won’t tell you what you need to know. Run the same scenario multiple times with small variations in phrasing and check that the outcome stays within bounds, not that it’s identical. Then run the scenarios you hope never happen: an angry customer trying to talk the agent into an exception, a request that sits right on the edge of what the permission set allows, a malformed input that a human would recognise as odd. If the agent’s write access only gets tested on clean, polite inputs, you’ve tested the demo, not the job.

    What skipping this actually costs

    I’ve seen teams treat guardrails as the thing you add once the agent is working, not before. That ordering is backwards, and it’s backwards because of how these failures surface. A flow with a bug usually fails loudly and immediately. An agent with a subtly wrong permission set or a missing validation rule can run correctly for weeks and then fail on exactly the input nobody tested for, at a point where it’s already touched hundreds of real records. Retrofitting guardrails after that happens means an incident review, a rollback, and a much harder conversation with whoever owns the business outcome than the one you’d have had by building the guardrails first.

    None of this is an argument against giving Agentforce write access. It’s an argument for treating write access as a separate decision from read access, with its own permission design, its own validation layer, its own approval points, and its own test plan. Get that sequencing right and the agent earns broader access on a track record you can actually point to. Skip it, and you’re trusting a demo to predict production, which it never does.

  • Agent Script and the Agentforce Vibes IDE: what changes for Salesforce developers

    Every Agentforce build I’ve looked at eventually hits the same wall: the logic that decides what an agent does lives in three or four different places at once. A topic here, an instruction there, an Apex action buried in a class nobody on the business side will ever read. Agent Script is Salesforce’s attempt to collapse that into something a human can actually look at and reason about. The Vibes IDE is the authoring layer sitting on top of it. Together they change less about what an agent can do and more about who gets to build it and how fast.

    What Agent Script actually is

    Strip away the branding and Agent Script is a structured, readable way to describe agent behaviour: what the agent is responsible for, what it should ask before acting, which actions it’s allowed to call, and under what conditions it hands off to a human. It compiles down to the same topics, instructions and actions Agentforce has always run on. The difference is that it’s written and reviewed as text, not assembled by clicking through five different setup screens and hoping the configuration matches the mental model in your head.

    That matters more than it sounds like it should. Right now, auditing an Agentforce agent means opening the Topics list, then the Actions list, then whatever Flow or Apex sits behind each action, then trying to hold all of it in working memory at once. A text-based definition means you can diff it, version it, and review it the way you’d review a pull request. For a technical lead, that’s the real unlock: code review stops being a special case you do for Apex and starts applying to agent behaviour too.

    Where this bites in practice

    I’ve seen plenty of orgs where the person who built the original agent configuration has moved teams, and nobody left can explain why a particular topic routes the way it does. Click-based configuration doesn’t leave a trail. A script does. Even a mediocre commit history beats no history at all.

    Where Vibes IDE fits

    Vibes IDE is the authoring experience: describe what you want the agent to do in plain language, get a working scaffold back, then drop into the underlying Agent Script to tighten it up. It’s the same pattern that’s shown up across developer tooling generally over the past couple of years: natural language gets you eighty percent of the way, and a competent engineer closes the gap on the remaining twenty. The interesting part isn’t the generation step. It’s that the output is inspectable and editable rather than a black box you either accept or throw away.

    For admins and junior developers, this lowers the floor for getting something working. For a technical lead, it changes what review looks like. You’re no longer just checking whether an agent answers correctly in a demo. You’re reading generated script the same way you’d read a junior developer’s first pass at a trigger: is the scope right, does it fail safely, does it ask for confirmation before anything irreversible.

    What doesn’t change

    None of this touches the actual hard problems. An agent built from a beautifully clean script still fails if the underlying data model is messy, if field-level security is inconsistent across the objects it touches, or if nobody’s defined what “done” means for the task it’s handling. A contact-centre agent that’s supposed to look up order status is still at the mercy of whatever gap exists between the Order object and the Case object in your org. Agent Script makes the agent’s logic legible. It does nothing for the data the agent is reasoning over.

    Testing doesn’t get easier either, just more structured. You still need the same discipline you’d apply to any automation: a set of representative inputs, a way to assert on outcomes, and a regression suite that runs before every change ships. The format changed. The job didn’t.

    There’s a governance question hiding in here too. A script that’s easy to generate is also easy to regenerate, and it’s tempting to let an agent’s permissions grow every time someone asks Vibes IDE for “one more capability.” I’d treat any change that expands what an agent can write to, not just what it can read, as a release event, not a prompt. That’s a small discipline to add, and it’s the difference between an agent that’s genuinely useful and one that’s quietly been granted more reach than anyone signed off on.

    What a technical lead should actually do with this

    Three things, in order of how quickly they pay off.

    • Treat Agent Script output the way you’d treat any generated code: review it before it ships, don’t just trust the demo. The gap between “answers the happy path” and “handles the edge cases a real customer will hit” is where most agent failures live.
    • Put agent definitions under the same version control and release process as everything else. If Agent Script gives you text, there’s no excuse for configuration drift between sandbox and production anymore.
    • Use Vibes IDE for the first draft, not the final build. It’s genuinely useful for getting unstuck on structure. It’s not a substitute for understanding what the agent is allowed to do and why.

    None of this is a reason to slow down adoption. A contact-centre team I worked with spent most of an early Agentforce build arguing about Topic boundaries in a spreadsheet, because nobody could see the whole picture at once. Something that turns that argument into a reviewable document is worth having, even before it generates a single line of anything. The value isn’t that the agent gets smarter. It’s that the people building it finally have something solid to point at when they disagree.