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.