Why your Agentforce agent feels slow, and how to get the first token back faster

The demo was instant. You typed a question, the agent answered before you finished reading it, everyone nodded, and the project got funded. Then it went to production, met a real org with real topics and real grounding, and now there’s a two-second pause before the first word shows up and a spinner your customers are learning to distrust. The instinct in the room is to blame the model, “GPT is slow today”, and the instinct is almost always wrong.

Latency in an Agentforce agent is a systems property, not a model property. Between the moment a customer presses enter and the moment the first word streams back, the platform runs a reasoning loop that may call an LLM more than once, pulls grounding out of your data, executes one or more actions, and screens the whole thing through guardrails. The model’s own inference time is one term in that sum, and frequently not the largest. If you want a fast agent, you have to know where the seconds go, and most of the big levers are configuration you own, not infrastructure you wait on.

This post is the anatomy of a slow turn: what happens end to end, why the number that matters is time-to-first-token rather than total time, what Salesforce changed in the runtime to claw seconds back, and the concrete moves that make your agent feel fast without rewriting it.

The one metric that decides “feels fast”

Start with the right target, because optimizing the wrong number wastes a sprint. There are two latencies in every agent turn and they are not the same:

• Time-to-first-token (TTFT), how long the customer stares at nothing before the first word appears.
• Total response time. How long until the answer is complete.

Perceived speed is almost entirely TTFT. An agent that starts streaming a coherent answer in 800ms and finishes in six seconds feels faster than one that sits blank for three seconds and then dumps the whole reply at once, even though the second one “finished” sooner on paper. This is why streaming matters and why the platform streams tokens as they’re generated: as long as the first tokens arrive quickly and the text keeps moving, the human brain reads it as responsive. The corollary is the trap: anything that happens before the first token (classification, planning, grounding, guardrail screening) is dead air the customer feels, and that pre-inference work is exactly where slow agents lose.

So the goal isn’t “make the LLM faster.” It’s shrink the pre-inference stretch and start streaming as early as possible.

Where a turn spends its time

Here’s the sequence behind a single message, in the order it runs. The Atlas reasoning engine, the part of Agentforce that decides what to do, drives most of it:

1. Classify the topic. The engine reads the utterance and the conversation and decides which topic is in play. Historically this was an LLM call.
2. Plan. Within the chosen topic, it selects which action(s) to run and in what order, given the instructions and the actions available.
3. Ground. It retrieves the data the answer needs (CRM records, a Data 360 retriever doing semantic search, knowledge articles) and assembles the context window.
4. Act. It executes the selected actions: a Flow, an Apex invocable, an external API call. Each action’s own runtime is now inside your turn.
5. Generate. It calls the LLM to compose the response over everything gathered, and streams the result.
6. Screen. Guardrails and the Einstein Trust Layer check inputs and outputs along the way.

Every one of those steps costs wall-clock time, and only step 5 is “the model answering.” A turn that feels slow is usually slow because steps 1–4 ran long before step 5 could start streaming: several LLM round-trips stacked in series, a retriever scanning more than it needs, an action waiting on a sluggish downstream system. The model gets the blame because it’s the visible part; the latency was spent upstream.

The single most useful reframe: each extra LLM call in the reasoning loop is a full network-plus-inference round-trip you pay before the customer sees anything. Two calls in series can easily be the difference between a fast agent and a slow one, independent of which model you picked.

What Salesforce changed in the runtime

This is worth understanding because it tells you exactly which levers matter. Salesforce pulled the same ones. When the platform’s own engineers set out to make Agentforce faster, they didn’t swap in a faster model as the headline move. They attacked the reasoning loop, and reported roughly 3–5x faster response times from it.

The changes they’ve described publicly:

• Fewer LLM calls before streaming. The runtime consolidated the number of LLM calls from four to two before it starts streaming output. Directly cutting time-to-first-token, because those calls ran in series ahead of the first token.
• A specialized small model for classification. Topic classification, step 1 above, was moved off a general-purpose LLM onto a purpose-built small language model (Salesforce calls it HyperClassifier). A small model tuned for one job returns faster than a large general model asked to also classify.
• Deterministic filters instead of an LLM safety pass. Input safety screening that used to be an LLM call was replaced with an enhanced framework where agent authors define deterministic rule-based filters for sensitive topics. A rule evaluates in microseconds; an LLM screening call is another round-trip.
• Consolidated model and data execution. Collapsing multi-stage reasoning and Data 360 execution together removed a reported chunk of multi-stage reasoning latency measured in seconds, not milliseconds.

Notice the pattern: remove serial LLM round-trips, use the smallest model that can do each job, and make deterministic what doesn’t need a model. Those are the same three levers available to you in configuration.

Lever one: match the model to the job

Agentforce lets you choose the model, and you get to make the model-selection call, including, in a multi-agent setup, overriding the model per subagent. This is the lever teams reach for last and it’s often the cheapest win, because model families differ enormously in TTFT.

The distinction that matters for latency is fast models versus reasoning models. A fast model (the Gemini Flash and Claude Haiku class of models available in Agentforce) is built to return the first token quickly. A reasoning model (the o-series, GPT-5-class, Gemini “thinking” variants) deliberately spends time on hidden chain-of-thought before it answers. That’s the feature, and for a hard planning problem it’s worth it. But pointing a reasoning model at a simple classify-or-summarize task means paying its thinking latency for work a fast model finishes in a fraction of the time.

The rule: use the largest model only where the reasoning is hard, and a fast model everywhere else. A tier-1 service agent answering grounded FAQ questions does not need a reasoning model’s deliberation; it needs to start streaming. If your platform supports per-subagent model override, route the narrow, well-grounded subagents to a fast model and reserve the heavyweight model for a open-ended supervisor.

There’s a cost dimension underneath this too: reasoning models burn more tokens on hidden thinking, and tokens are the unit of the Flex Credits bill. So matching model to task usually makes the agent both faster and cheaper, the rare optimization with no trade-off.

Lever two: shrink the reasoning surface

Every topic and action you add is something the planner has to consider on every turn. An agent with sixty overlapping topics and a hundred actions doesn’t just misclassify more. It plans more, and planning is LLM work that happens before the first token.

Keep the reasoning surface small and sharp:

• Fewer, well-separated topics. Overlapping topics force the classifier to work harder and increase the odds of a wrong branch that then has to recover. Clear boundaries classify faster and more reliably. This is the same design that keeps agents accurate. See designing topics and subagents.
• Only the actions a topic needs. Scope actions to topics so the planner chooses from a short list, not the whole catalog.
• Split a bloated monolith into a supervisor with specialists. Each subagent in a multi-agent design reasons over a smaller context, which is faster per turn than one giant agent reasoning over everything.

The instinct to “add one more topic, it can’t hurt” is exactly how a fast pilot becomes a slow production agent. It can hurt, and it does, on every single turn.

Lever three: make grounding lean

Grounding is a double latency cost: the retrieval itself takes time, and everything it returns lands in the context window, which enlarges the prompt the model then has to read before it can generate. Fat grounding is slow twice.

• Retrieve narrow. A retriever that scans a huge, poorly chunked corpus is slower than one hitting tight, single-topic chunks, and the cost of a Data 360 query tracks the data scanned, not the rows returned, so lean retrieval is faster and cheaper together.
• Chunk knowledge properly. Long monolithic articles force retrieval to pull big blobs; single-topic chunks return the relevant paragraph and keep the context small.
• Prefer a merge field or a data graph over a semantic search when the question is deterministic. If the answer is “this customer’s current balance,” fetch the field. Don’t run a vector search to find it. Climb the grounding ladder only as high as the question needs.
• Don’t over-ground “just in case.” Every extra document you stuff in is more tokens the model reads before the first token comes out, and more chance it fixes on the wrong detail.

Lever four: fix the slow action, don’t hide it

When an agent turn is slow and the model and grounding are lean, the culprit is usually an action waiting on a downstream system. An agent action that calls an external order-management API sits inside the turn, if that API takes four seconds, your agent takes at least four seconds, and no model choice fixes it.

Treat agent actions like any other integration on a latency budget:

• Make external callouts fast or asynchronous. If a downstream call is slow and the result isn’t needed to compose the reply, don’t block the turn on it. For long-running work (a refund that takes a minute to settle, a document that takes time to generate) acknowledge in the conversation and complete the work out of band rather than holding the customer on a spinner.
• Keep Apex actions inside governor limits and off the slow path. A governor-limit collision or an unbounded SOQL query in an invocable action is latency (and failure) you feel directly in the turn.
• Watch the action, not just the agent. Instrument each action’s runtime so you can see which one is slow instead of guessing that “the agent” is slow.

You can’t tune what you can’t see

All of the above assumes you know where the seconds are going, and most teams don’t. They have a vague sense that “it’s slow” and no per-step breakdown. That’s what Agentforce observability and Command Center are for. The session traces, exported over OpenTelemetry, show the turn broken into its phases, so you can tell a slow retriever from a slow action from a slow generation. Optimize against the trace, not against the vibe. A team that instruments first usually finds the real culprit is one action or one bloated retriever, not the thing they were about to spend a week replacing.

Voice makes all of this non-negotiable. On a chat channel a customer will tolerate a beat of silence; on a voice agent the same pause is a dead-air gap that breaks the conversation, so the TTFT budget is tighter and every lever above matters more.

Takeaways

• Optimize time-to-first-token, not total time. Streaming means the answer that starts fastest feels fastest. Everything before the first token (classify, plan, ground, screen) is dead air the customer feels.
• The model is rarely the bottleneck. Serial LLM calls in the reasoning loop, fat grounding, and slow actions usually cost more than inference. Salesforce’s own 3–5x speedup came from cutting LLM calls (four to two), moving classification to a small model, and replacing an LLM safety pass with deterministic filters, not from a faster model.
• Match model to task. Fast models (Gemini Flash, Claude Haiku class) for narrow, grounded work; reasoning models only where the planning is hard. It’s usually faster and cheaper.
• Keep the reasoning surface small. Fewer, cleaner topics and scoped actions mean less planning per turn. Split monoliths into a supervisor with specialists.
• Ground lean and fix slow actions. Retrieve narrow, chunk knowledge, prefer deterministic fetches, and don’t block a turn on a slow external callout.
• Instrument first. Use Command Center session traces to find the real culprit before you optimize.

A fast agent isn’t the one on the biggest model. It’s the one that does the least work before it starts talking (the fewest reasoning round-trips, the leanest grounding, the quickest actions) and then streams. Get those right and the spinner your customers learned to distrust mostly disappears.

Understanding the basics

Why is my Agentforce agent slow?

Almost always because of work that happens before the model starts generating, not the model itself. A turn classifies the topic, plans which actions to run, retrieves grounding, executes actions, and screens through guardrails, and several of those steps can be LLM round-trips or slow external calls that stack up in series ahead of the first token. Fat grounding (a retriever scanning too much, over-stuffed context) and slow agent actions (an external API the turn waits on) are the most common culprits. Use Command Center session traces to see which phase is costing the time before you change anything.

What is time-to-first-token and why does it matter more than total time?

Time-to-first-token (TTFT) is how long the customer waits before the first word of the answer appears. Because Agentforce streams tokens as they’re generated, perceived speed is dominated by TTFT: an answer that starts in under a second and streams for several seconds feels faster than one that sits blank and then appears all at once, even if the second finishes sooner. Optimizing latency means shrinking the pre-inference stretch (classification, planning, grounding, screening) so streaming can start as early as possible.

Does choosing a faster LLM fix Agentforce latency?

It helps, but it’s rarely the whole answer. Model choice matters, a fast model like the Gemini Flash or Claude Haiku class returns the first token much sooner than a reasoning model that spends time on hidden chain-of-thought, so pointing a reasoning model at a simple task is a common, avoidable latency cost. But if the slowness comes from serial reasoning calls, heavy grounding, or a slow action the turn waits on, a faster model won’t rescue it. Fix the reasoning surface and the actions first, then match the model to the task.

How many LLM calls does an Agentforce turn make?

It varies by design, but the reasoning loop can make several: historically topic classification, planning, and generation were separate calls, each a full round-trip before streaming. Salesforce has said it re-architected the runtime to consolidate LLM calls from four to two before output streams, and moved topic classification onto a specialized small model rather than a general LLM. The practical lesson for your own agents: every extra reasoning call and every scoped-in topic adds planning work before the first token, so keep topics and actions few and sharp.

---

Chasing a slow agent and not sure whether it’s the model, the grounding, or an action? Talk to us, instrumenting the turn and pulling the right lever is exactly the work that turns a sluggish pilot into an agent people trust.