Salesforce redesigned Agentforce to split agent reliability across four separate systems instead of relying on one giant prompt. Its first version broke down after about eight instructions crammed into a single prompt, since models started skipping rules. The new stack uses Agent Script for deterministic rule enforcement, Data 360 for unified customer profiles, the Agent Context Engine to trim prompt size (one example dropped from 124,000 to 9,000 tokens), and Agent Identity for scoped permissions. Salesforce agents have completed 7 billion Agentic Work Units, with 3.2 billion in a single quarter, and its APIs handle 9.6 billion calls daily.
Table of contents
Only 30% of AI agent pilots reach production. What separates them? (Sponsored)The naive design: one large promptHow Agentforce is builtWhere the agent runsWhat’s nextQuestions this post answers
Why does an LLM start ignoring instructions when a prompt has too many rules packed into it?
Instructions in a single prompt are just text, not enforced rules, so a model can skip them as more pile up. Salesforce's Agentforce team found this held for up to eight instructions but failures began after that. A separate benchmark, IFScale, tested 20 models with up to 500 instructions in one prompt and found even the best model followed only 68% of them at 500. Anyone debugging flaky agent prompts can track emerging reliability patterns like this on daily.dev.
How much can a context management layer reduce the token count sent to an LLM agent per request?
In Salesforce's comparison, an insurance agent question without context management pulled 124,000 tokens from various data sources, while the same question through its Agent Context Engine used only 9,000 tokens. After a follow-up question, a naive session reached about 300,000 tokens versus 65,000 tokens with context management, showing the gap widens as conversations continue. Teams sizing agent context budgets can compare approaches like this on daily.dev before committing to one.
How can an AI agent call hundreds of MCP tools without loading all their definitions into its context window every request?
Instead of exposing every tool definition, a server can expose a small index with just a handful of tools, for example discover, describe, and dispatch. The agent first searches for what it needs via semantic search, reads the matched tool's contract, then dispatches the call. The Salesforce MCP Server implements this pattern with only four tool definitions total. Developers designing MCP tool integrations can follow patterns like this on daily.dev to control context bloat.
Share this post