Agentforce limits that shape your architecture: agents, subagents, actions, and the governor-limit collision

Most Agentforce projects don’t fail on a limit. They get reshaped by one, usually late, usually after the design is set, usually in the form of a runtime exception nobody budgeted for. You build a single agent that does everything, and somewhere around the fourteenth topic you discover there’s a fifteenth-topic wall. You wire an action that loops over a batch of records, and the reasoning engine calls it three times in one turn and throws Too many SOQL queries: 101. You promise a stakeholder the agent “remembers the whole conversation,” then watch it forget turn two of a twelve-turn thread.

None of these are bugs. They’re the platform telling you, after the fact, what its shape is. This post front-loads that shape: the numeric caps that decide how you partition an agent, the timeouts that decide what runs synchronously, and, the one that surprises seasoned Salesforce developers most, how the Atlas reasoning loop consumes Apex governor limits in a way a trigger or a Flow never does. Get these in front of the whiteboard instead of into the incident channel.

The caps that decide your topology

Start with the structural limits, because they’re the ones that force architecture decisions you can’t easily reverse later. As of the 2026 releases, an Agentforce (Default) agent lives inside three nested ceilings:

20 active agents per org. This is the one large enterprises hit first. You cannot give every department its own fleet of a dozen agents inside one org and stay under it. It pushes big programs toward either careful consolidation or a multi-org footprint.
15 subagents per agent. In the April 2026 terminology refresh, topics became subagents and the Topic Selector became the Agent Router, same mechanism, new names. Each agent routes across at most 15 of them.
15 actions per subagent. Each subagent groups a bounded set of actions the router can invoke once it lands there.

Multiply those out and a single agent tops out at 15 × 15 = 225 actions in the absolute best case, but you never get near that in practice, because a subagent crammed with 15 near-synonymous actions is exactly the design that makes the router pick the wrong one. The real constraint is classification quality, not the arithmetic ceiling, which is why designing subagents and their classification descriptions matters more than counting slots.

The important reframe: the 15-subagent cap is why multi-agent orchestration is an architecture requirement, not a stylistic choice. When a single agent’s scope exceeds 15 coherent subagents, you don’t cram. You split into a supervisor that delegates to specialist agents. Teams often reach for multi-agent orchestration for the elegance of clean handoffs; just as often, they reach for it because they ran out of subagents. Both are valid reasons. Know which one is driving your design, because they lead to different topologies, the elegance case wants a few well-bounded specialists, the cap case wants you to reconsider whether the agent is doing too much at all.

The timeouts that decide what runs synchronously

The second family of limits governs time, and here the documented numbers matter because they set a hard budget on what an action body can do before the platform gives up.

The Agent API, the headless interface behind any custom-app or channel integration, enforces a 120-second timeout on a request, returning an HTTP 500 when a turn exceeds it. That 120 seconds is the whole turn: the reasoning, every action the engine decides to call, and the response generation, end to end. It is not 120 seconds per action. If the router fires three actions in a turn and each does real work, they share that budget.

Underneath the turn budget sits the execution ceiling on the action itself. Practitioners consistently report a roughly 60-second wall on synchronous action execution, which lines up with the invocable-method execution context an Apex action runs inside, and Salesforce’s own guidance is unambiguous about the consequence: long-running work does not belong in a synchronous action body. A callout that waits on a slow external system, a transform over thousands of rows, a document-generation step, anything that flirts with those seconds should be moved off the conversational transaction entirely. We’ll get to how in a moment.

Two more time-and-volume limits worth knowing before you promise anything:

The Models API rate-limits embeddings and feedback endpoints at 1,000 requests per minute per org, returning HTTP 429 on exceed. If you’re doing your own embedding-heavy grounding pipeline alongside the agent, that ceiling is shared org-wide.
On Government Cloud, the Agent API base endpoint is api.gov.salesforce.com, not api.salesforce.com. A one-line detail that silently breaks an integration built against the commercial endpoint.

The memory window: six turns, and why “remembers the conversation” is a half-truth

Here is the limit that most often collides with a stakeholder promise. The agent’s working context is the most recent six turns, agent and user messages combined. Beyond that window, earlier turns fall out of the reasoning context.

This is not the whole story of agent memory. Salesforce threads more context than the raw window suggests, and there’s a real distinction between session state, grounding, and durable memory that we pulled apart in what “memory” means in Agentforce. But the six-turn window is the operational reason a long conversation degrades: the finite context crowds out the beginning of the thread, so the agent re-asks a question it already got an answer to, or forgets a constraint stated ten turns back. Salesforce calls the general phenomenon context rot, and the six-turn number is the concrete edge of it.

The fix is not to wish for a bigger window. It’s to stop relying on the window to hold facts that have to be exactly right. Capture the verified customer ID, the case number, the confirmed selection into a variable the moment you have it, and reference that variable downstream, a named slot survives well past six turns, where a conversational mention does not. If your agent forgets things inside one session, the answer is almost always variables, not memory.

One more display limit that trips up list-heavy agents: when an action returns records to show the user, the “View More” experience caps at 50 records, even when more match. An agent that says “here are all your open cases” and there are 80 of them is showing 50. Design the action to filter or paginate rather than dumping an unbounded set.

The collision nobody warns you about: the ReAct loop meets governor limits

Now the part that catches experienced Salesforce developers off guard, because it violates an assumption that’s been safe for a decade.

The Atlas reasoning engine runs a ReAct loop. Reason, Act, Observe. It reasons about what to do, calls an action, observes the result, and reasons again. The consequence that matters for limits: the engine can call the same action more than once inside a single turn. It might call your lookupOrder action, see the result doesn’t fully answer the question, and call it again with different parameters, all before it responds to the user.

For a decade, an Apex developer could reason about governor limits by looking at one entry point: a trigger fires, a batch runs, a Flow executes, and you count the SOQL and DML in that transaction. The agent breaks that mental model, because the number of times your action runs in a turn is decided by a probabilistic reasoning loop, not by your code. An action that issues 40 SOQL queries is perfectly safe called once and throws System.LimitException: Too many SOQL queries: 101 the moment the engine calls it three times in a turn against a shared budget.

The standard synchronous Apex governor limits still apply to the transaction the action runs in: 100 SOQL queries, 150 DML statements, 10 seconds of CPU time in a synchronous context. What’s changed is that you no longer fully control how many times you spend against them. The runtime errors teams report from production agents (Too many SOQL queries: 101, Too many DML statements: 151, Apex CPU time limit exceeded) are very often this: a per-call-safe action, multiplied by a reasoning loop, blowing a per-transaction budget.

Three design rules follow directly, and they’re not optional if you’re exposing Apex to an agent:

Write every action as if it will be called repeatedly in one turn. Keep each action’s governor footprint small and predictable. An action that does one bounded lookup and returns is safe under multiplication; an action that loops over a collection issuing a query per element is a landmine.
Bulkify inside the action, never across calls. Agentforce actions don’t bulkify the way a trigger does: each invocation is its own transaction with its own fresh governor budget, and the engine calls them one record’s worth at a time. So the classic “handle 200 records in one transaction” instinct doesn’t map. Bulkify the work within a single action’s body (one query for the set it’s given), and don’t assume the platform will batch your calls for you.
Push heavy work asynchronous. Anything that risks the CPU or callout ceiling (a slow external callout, a large transform, a document build) belongs in a Queueable, a future method, or Batch Apex kicked off by the action, not done in the action. The action’s job becomes “start the work and tell the user it’s running,” which also keeps you under the 120-second turn budget. For event-driven work, a triggered agent acting on a platform event is often the right shape instead of a synchronous conversational action.

Cost is a limit too

The caps above are hard walls; the credit meter is a soft one that shapes design just as much. Every turn the agent takes (every trip through the reasoning loop, every action call, every grounding retrieval) has a cost, and a bloated context inflates it on every single turn. Stuffing full conversation history back into the prompt to fake statefulness past the six-turn window doesn’t just risk context rot; it multiplies your token bill by the length of the conversation. The levers that keep an agent under its limits (small actions, tight grounding, variables instead of re-derivation, clean subagent boundaries) are the same levers that keep it under its Flex Credit budget. Efficiency and correctness point the same direction here, which is a mercy.

A note on numbers that move

Two honest caveats. First, these caps are release-versioned. The 20/15/15 structure and the timeouts reflect the 2026 releases; Salesforce revises platform limits, and the exact figure you build against should be confirmed on the current “Agentforce (Default) Considerations” and Agent API considerations pages in Help before you commit an architecture to it. Treat this post as the map of what kinds of limits exist and how they interact, the shape is stable even when a specific number ticks.

Second, the terminology moved under everyone’s feet in April 2026. Topics became subagents, the topic selector became the agent router. Older blog posts (and older muscle memory) still say “15 topics.” Same wall, new sign. When you’re reading community troubleshooting threads, mentally translate.

The takeaway

The limits that reshape an Agentforce build aren’t hidden. They’re just not handed to you at the moment you’d want them. Put them on the whiteboard: 20 agents per org decides whether you’re single-org or multi-org; 15 subagents and 15 actions decide when you split into orchestrated specialists; 120 seconds a turn and ~60 a synchronous action decide what runs inline versus async; six turns of memory decides what you promise about “remembering,” and pushes the important facts into variables; and the ReAct loop over standard governor limits decides how you write every Apex action: small, bulkified within itself, and heavy work pushed off the conversational transaction. Design against those from the first sketch and the platform stops surprising you. Design without them and you’ll meet each one exactly once, at runtime, in production.

Understanding the basics

How many agents, topics, and actions can you have in Agentforce?

As of the 2026 releases, an Agentforce (Default) agent is bounded by three nested caps: up to 20 active agents per org, up to 15 subagents (formerly “topics”) per agent, and up to 15 actions per subagent. In practice you rarely approach the theoretical 225-action ceiling of a single agent, because a subagent packed with near-duplicate actions degrades the Agent Router’s ability to pick the right one. Classification quality caps you well before the number does. When a use case needs more than 15 coherent subagents, that’s the signal to split into a supervisor agent delegating to specialist agents rather than cramming. Confirm the current figures on Salesforce’s “Agentforce (Default) Considerations” page, since platform limits are revised per release.

Why does my Agentforce agent throw “Too many SOQL queries: 101”?

Because the Atlas reasoning engine runs a ReAct (Reason–Act–Observe) loop and can call the same action more than once within a single turn. An Apex action that issues, say, 40 SOQL queries is safe when called once but blows the 100-query synchronous governor limit the moment the engine calls it three times against the same transaction budget. The fix is to write actions with a small, predictable governor footprint, bulkify the work inside each action’s body rather than assuming the platform batches your calls, and push anything heavy (slow callouts, large transforms) into asynchronous Apex (Queueable, future, or Batch) started by the action instead of executed inside it.

What is the Agentforce action timeout?

The Agent API enforces a 120-second timeout on an entire turn (reasoning, every action the engine calls, and response generation combined) returning HTTP 500 when it’s exceeded. That budget is shared across all the actions fired in the turn, not granted per action. Separately, synchronous action execution runs inside an invocable-method context with its own execution ceiling (practitioners consistently report roughly 60 seconds), which is why long-running work should be moved off the synchronous action body and run asynchronously. Verify the exact current figures in the Agent API considerations documentation.

How much conversation does an Agentforce agent remember?

The working reasoning context is the most recent six turns (agent and user messages combined); earlier turns fall out of the window, which is the concrete edge of what Salesforce calls context rot. That’s why long conversations start re-asking questions they already answered. The mitigation isn’t a bigger window. It’s capturing facts that must be exactly right (a verified ID, a case number, a confirmed selection) into variables the moment you have them, and referencing those variables downstream, since a named variable persists for the whole session while a conversational mention does not.

Trying to work out whether your agent should be one agent or five, what belongs in a synchronous action versus an async job, and how to keep the reasoning loop from blowing your governor limits? Talk to us, designing around these caps before they design around you is exactly the architecture work that decides whether an Agentforce build survives production.