💬 In plain words: Salesforce Agentforce enforces strict limits: 15 subagents per agent, 15 actions per subagent, and up to 20 active agents per org. The 15-subagent limit directly shapes your design, preventing a single "catch-all" enterprise agent.
📌 Example: Meridian Energy wanted a single agent to handle outages, billing, tariffs, meter readings, complaints, and new connections. Because six distinct domains require dozens of subagents, building one giant agent fails. The solution is creating one targeted agent per domain.
Core Architectural Concepts & Boundaries
- Org Capacity: Maximum of 20 active agents per Salesforce org.
- Agent Scoping: Up to 15 subagents (topics) per agent.
- Action Allocation: Up to 15 actions per subagent.
- Execution Limits: A strict 60-second timeout applies to any individual action call.
- Governor Limits: Standard synchronous Apex limits still apply inside a conversational turn (100 SOQL queries, 150 DML statements).
- ReAct Execution Loop: The reasoning engine uses a Reason-Act-Observe loop. It can invoke the same action multiple times in a single turn, so unoptimized actions will consume limits fast.
- Deployment Lifecycle: Agents must be deactivated to edit metadata or configuration, then reactivated for testing and production use.
Agentforce Hard Limits Overview:
├── 20 active agents per org
├── 15 subagents per agent <-- Primary architectural constraint
├── 15 actions per subagent
├── 60s execution timeout per action
└── Standard Apex limits per turn (100 SOQL / 150 DML)
└── ReAct loop may trigger repetitive calls per turn
🧠 Key Rule: 20 agents, 15 subagents, 15 actions, 60 seconds.
🧭 360 Card — Managing the 15-Subagent Ceiling
- Rule: Design for hard ceilings from day one using domain-scoped agents rather than a single monolithic enterprise bot.
- Gain: Avoid costly mid-project redesigns when scaling capabilities past sprint three.
- Price: Managing multiple specialized agents requires more deployment pipelines, permission sets, monitoring, and versioning overhead.
- Limits: Hard numerical thresholds enforced at runtime and setup.
- Anti-Pattern (The Monolith): One enterprise agent sounds easy to govern, but it cannot scale across multiple business domains.
- Future State: Advanced orchestrator patterns that coordinate across subagents rely on multi-agent capabilities—verify feature release status before committing your architecture.
- At Scale: In practice, intent routing precision often degrades before you even hit the 15-subagent threshold.
Interview & Design Review Q&A
Q: What are the primary limits in Agentforce, and which one dictates your technical architecture?
🎯 Say this first: 20 active agents per org, 15 subagents per agent, 15 actions per subagent, and a 60-second timeout. The 15-subagent ceiling is the key architectural driver.
- The Numbers: Always state the 20/15/15/60 rule clearly alongside standard Apex execution limits.
- Execution Mechanics: Highlight that the ReAct engine can invoke an action multiple times per conversational turn, meaning inefficient queries or logic quickly breach limits.
- Architectural Impact: Explain that the 15-subagent cap makes monolithic bots impossible, requiring clean business domain boundaries.
- Design Strategy: Use domain-scoped agents and orchestrator patterns when building large-scale implementations.
2-Minute Architecture Self-Check
Q1: What does the reasoning router evaluate to choose a path?
A1: It evaluates each subagent's description field—not the underlying actions or private instructions.
Q2: If an agent gives the right answer using the wrong subagent, is that a pass?
A2: No, it fails. Subsequent conversational turns will lack the correct actions, contextual data, and permissions required for downstream tasks.
Q3: How many subagents can a single agent host?
A3: Exactly 15. This boundary requires architects to modularize bots by domain rather than combining everything into one.