Get in Touch

Category: Salesforce AI

  • 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.

  • Data Cloud ingestion patterns: getting external data into Salesforce without a mess

    Every Data Cloud project I’ve touched hits the same wall about six weeks in. The demo worked because someone fed it clean, pre-shaped data by hand. Then someone asks “can we pull in the real feed from the call centre platform?” and the confident answers get vague fast.

    Ingestion is where Data Cloud projects quietly succeed or fail. Not the Calculated Insights, not the segmentation, not the flashy Agentforce demo sitting on top. The pipe. Get the pipe wrong and everything downstream inherits the mess, except now it’s harder to see because it’s been through a few layers of transformation first.

    Three ways data actually gets in

    Data Cloud gives you three real paths, and most orgs end up using at least two of them whether they planned to or not.

    Batch, via connectors or the Bulk Ingestion API

    This covers the bulk of what lands in Data Cloud: CRM objects through the native Salesforce connector, Marketing Cloud data extensions, files sitting in S3 or Google Cloud Storage, data from a warehouse like Snowflake or Redshift. It’s scheduled, it’s batched, and it’s forgiving if a run is a few minutes late. Good fit for anything that doesn’t need to react to an event the moment it happens: historical case data, product catalogues, loyalty tiers, order history.

    Streaming, via the Ingestion API

    This is the one teams reach for too early. Streaming ingestion exists for data that needs to show up in near real time, things like a web click, an app event, a call just logged in the contact centre. It’s genuinely useful when a Calculated Insight or a segment needs to react within seconds. It’s overkill, and more expensive to run and maintain, when the actual business need is “update it sometime today.” I’ve seen teams build a streaming pipeline for data that gets looked at once a week.

    Native connectors for Salesforce-native sources

    If the data already lives in Sales Cloud, Service Cloud, or Marketing Cloud Engagement, the native connectors do the heavy lifting without custom code. They’re the easiest path and usually the first one worth setting up, because they prove the rest of the model works before you go anywhere near a third-party source.

    The mistake that shows up in almost every org: mapping without modelling

    Data Cloud makes it very easy to wire up a source, map some fields, and watch rows land in a Data Lake Object. That’s the trap. Mapping fields is not the same as deciding what those fields mean in your data model.

    I worked with a contact-centre team that ingested case data from two systems: Salesforce Service Cloud and a legacy ticketing tool that hadn’t been decommissioned yet. Both had a field called “status.” Both got mapped straight into Data Cloud. Nobody stopped to ask whether “Resolved” in one system meant the same thing as “Closed” in the other, or whether they should feed the same Calculated Insight at all. The segment built on top of that data looked fine in testing and was wrong in production, because it was quietly blending two different definitions of “resolved.”

    Before you map a single field, write down what the Data Model Object is actually for, who’s allowed to write to it, and what “done” looks like for the data flowing into it. That document takes an afternoon. Skipping it costs weeks later, usually right after go-live when someone notices the numbers don’t add up.

    Schema drift will happen. Plan for it before go-live, not after

    Source systems change. A field gets renamed, a picklist value gets added, an API version gets deprecated. On a standard integration, that breaks loudly and you fix it in an afternoon. In Data Cloud, a schema change upstream can quietly degrade a mapping, a Calculated Insight, or an identity resolution rule without throwing an obvious error. The pipeline keeps running. It’s just running on slightly wrong assumptions.

    Build monitoring around ingestion volume and null rates, not just success and failure flags. A batch job that “succeeds” but ingests zero rows, or ingests rows with a key field suddenly empty, needs the same attention as a failed job. Most teams only find out about a quiet schema break when someone downstream notices a number that looks off, and by then the bad data has already fed a few cycles of Calculated Insights.

    Identity resolution depends on what you ingested, not what you intended to ingest

    This one trips people up because it feels backwards. You don’t design identity resolution first and then feed it data. You design ingestion carefully, because identity resolution can only work with the identifiers you actually brought in. If the source system’s email field is inconsistently formatted, or a phone number comes through with inconsistent country codes, no amount of matching rule tuning in Data Cloud fixes that at the resolution stage. The fix belongs upstream, in how the data is cleaned on the way in.

    A practical habit: before connecting any new source, list the identifiers it carries (email, phone, loyalty ID, device ID, whatever applies) and check their format against what’s already in Data Cloud. A five-minute check here saves a painful unification exercise three months in, when unified profiles turn out to be quietly duplicating because two sources wrote the same phone number two different ways.

    A sequence that actually works

    Start with one source, ideally a native connector, and get it fully modelled: DMO defined, field meanings documented, identifiers validated. Add monitoring on that single pipeline before adding a second source. Only then bring in the next source, and check its identifiers against the first before mapping a single field.

    It’s slower than connecting everything in week one. It’s also the difference between a Data Cloud instance leadership trusts and one where every number needs a caveat attached. The second kind doesn’t get used for long, however good the dashboards look on day one.

  • Koa and Salesforce’s own reasoning model: what it means for agent cost and latency

    Every Agentforce build eventually hits the same question: which model should actually answer this topic? Salesforce now gives you a real choice instead of a default. Point the agent at its own reasoning-tuned model, Koa, running inside the platform, or bring your own through the BYOLLM framework and call out to Claude, GPT, or whatever your org has already standardised on. That choice isn’t cosmetic. It changes your latency budget, your token bill, and honestly, how much you trust the agent’s output when a case gets weird.

    What Koa is actually for

    Koa sits inside the Agentforce stack as the model Salesforce built and tuned specifically for the reasoning steps an agent runs through: picking a topic, choosing an action, deciding whether it has enough grounding to answer or needs to hand off. It isn’t trying to be a general-purpose chat model. It’s trying to be fast and cheap at the narrow job of routing and tool selection, the parts of an agent’s turn that happen dozens of times before the user ever sees a sentence of output.

    That’s a different design goal to a frontier model like Claude, which you’d reach for when the actual content of the response needs real reasoning depth: summarising a messy case history, drafting a response that needs genuine judgment, working through a multi-step policy question. Mixing the two, a fast native model for orchestration and a stronger external model for the parts that need it, is where most of the interesting architecture decisions live right now.

    Why this isn’t just a pricing table exercise

    I’ve seen teams try to settle this by comparing per-token rates and calling it done. That misses most of the real cost. An Agentforce turn isn’t one model call. It’s a chain: intent detection, topic selection, grounding retrieval, action input validation, and only then a response. If each of those hops goes out to an external model over the network, you’re paying for round trips you didn’t budget for, and your users are feeling every one of them as delay. Koa running natively inside the platform skips a chunk of that network cost because it’s sitting next to the data it needs.

    Where latency actually bites

    In a contact-centre deployment, the latency that matters isn’t the model’s raw inference time. It’s everything wrapped around it: a grounding query against Data Cloud, a permission check, an Apex action with its own callout, then back to the model to decide what to do with the result. Add an external LLM into that loop and you’ve added another network hop, another cold-start risk, another vendor’s rate limit sitting between your agent and the answer. For a customer sitting on hold, a few hundred extra milliseconds per reasoning step adds up fast across a multi-turn conversation.

    This is the practical argument for using Koa, or any native reasoning model, for the orchestration layer: topic and action selection, slot filling, deciding when to escalate to a human. Reserve the external model call for the one or two points in the flow where you genuinely need deeper reasoning or a model your org has already validated for a specific kind of output.

    When I’d still reach for BYOLLM

    Native isn’t always the right call. A few situations where I’d bring in an external model anyway:

    • Your governance team has already done the work to validate a specific model for a regulated use case, and redoing that validation for a new model isn’t worth the saved latency.
    • The task needs stronger reasoning than routing requires: drafting a response that has to read as careful and specific rather than templated, or working through an ambiguous multi-step request.
    • You’ve got existing prompt engineering, evaluation sets, or fine-tuning invested in a particular model, and swapping it out would mean redoing that work for a marginal latency gain.
    • Data residency or contractual terms point you at a specific vendor regardless of what’s fastest.

    None of those are reasons to route every single turn through an external model by default. They’re reasons to be deliberate about which specific actions get the expensive call and which ones don’t.

    Designing actions so the model choice doesn’t matter later

    The mistake I’d actively guard against is baking a specific model’s quirks into how you write topics and actions. If your instructions are tuned around how one model happens to interpret ambiguous phrasing, you’ve built something fragile. Keep the action’s input schema strict, keep the instructions plain and unambiguous, and let the model, whichever one you’ve pointed at it, do the narrower job of filling in well-defined slots rather than guessing at intent from loose prose.

    That discipline pays off twice. It makes the agent easier to test, because you can swap Koa for an external model in a sandbox and check whether behaviour holds. And it means that when Salesforce next ships a meaningful update to its reasoning model, or your org decides to standardise on a different external one, you’re changing a model selector, not rewriting every topic in the agent.

    The actual decision framework

    Boiled down, here’s how I’d set the default for a new Agentforce build. Route orchestration and routine action selection to the native reasoning model first. Reserve external model calls for the specific actions where output quality depends on deeper reasoning, not just correct routing, and name those actions explicitly rather than leaving the choice implicit. Measure latency per turn, not per model call, because that’s what your users actually experience. And revisit the split every time Salesforce updates Koa or your org re-evaluates its external model contracts. This isn’t a decision you make once and forget.

    Cost and latency used to be an infrastructure conversation that happened after the agent was built. With model selection now a first-class design decision in Agentforce, it’s part of the build itself. Worth getting the split right before go-live, rather than discovering the bill, or the hold time, three months in.

  • 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.