Last quarter, I observed a flagship Agentforce deployment at a large financial services firm. The entire setup relied on a single agent powered by one extensive system prompt, expected to manage account queries, product questions, onboarding FAQs, and escalations all at once. The initial demo was flawless. However, about six weeks after going live, issues began to appear. The agent started blending account-specific logic with generic product responses. By that point, the system prompt had expanded beyond 8,000 tokens, and no one could pinpoint which instruction was triggering the incorrect outputs. It was a clear example of how quickly complexity can become difficult to control when everything is consolidated into one prompt.

This is the monolith trap, and it’s more common than anyone in the Agentforce community wants to admit. The Salesforce Architects team has published a clear, opinionated response to this problem: SOMA, MOMA, and a third-party (3P) agent integration model that collectively redefine what enterprise-scale Agentforce architecture actually looks like. I want to break it down with the architectural judgment this framework deserves.

The Real ProblemWhy the Monolithic Agentforce Agent Has a Ceiling

Monolithic Agentforce agents are the starting point, not the destination. For narrow, well-scoped use cases, a knowledge retrieval bot, a “summarize this Case” button on a page layout, a single agent is exactly right. But as enterprise complexity enters the picture, two problems emerge that no amount of prompt refinement can fix.

The first is attention dilution. When a single Agentforce agent carries topics, instructions, and actions spanning support, sales, billing, compliance, and technical troubleshooting simultaneously, reasoning quality degrades. The agent holds a lot of context, but reasons about it less precisely. Atlas Reasoning is powerful, but it’s not immune to the limits of what a single agent can reliably handle.

The second is maintainability collapse. When something goes wrong in production, and it will, you’re digging through one enormous system prompt to find the failure. No fault isolation. No modularity. No ability to test one domain without touching the entire agent.

This is exactly why Salesforce frames multi-agent architecture as enabling greater scale, control, and flexibility than monolithic systems. Individual Agentforce agents can be added, replaced, modified, and tested independently. When one component fails, it doesn’t compromise the entire system. That’s not a product claim, it’s a structural property of the architecture, and it matters enormously once you’re in production.

Core PatternsSingle Agent, SOMA, MOMA, and Exactly When to Apply Each

I use this analogy constantly in stakeholder conversations because it lands at every level of technical familiarity, from service reps to CTOs.

The Front DoorThe Superagent, Salesforce’s Answer to the Maze vs. Monolith Problem

Salesforce’s Agentforce documentation names a specific architectural pattern I think the community is underestimating: the Superagent, also referred to as the Primary Agent. This is the solution to a trap that’s deceptively easy to fall into as your Agentforce deployment grows.

Without a Superagent, organizations end up building a maze. Isolated specialist bots that users have to navigate themselves: “Ask the Billing bot, then log into the HR portal, then contact the Support agent.” That’s not agentic enterprise. That’s automation with a worse user experience than a phone tree.

The Superagent solves this by acting as the single, intelligent entry point across every channel. It maintains the full conversation context, understands the user’s intent holistically, decomposes complex requests into sub-tasks, and delegates to appropriate specialist Agentforce agents. All transparently. The user engages in one continuous, coherent conversation. The Superagent handles all routing and orchestration invisibly.

What makes this governance model powerful is how it threads the organizational needle. Business teams can build and own their domain specialist agents, Service, Sales, HR, Finance, launching independently without waiting on central IT. Central IT maintains unified policy enforcement and visibility through the Superagent control layer. Domain ownership and centralized governance, simultaneously. After 15 years of watching these two forces fight each other in every Salesforce implementation I’ve run, seeing an architecture that structurally resolves the tension is significant.

Salesforce calls the mechanism that makes this seamless Floating Context, a shared session memory where the user’s identity, conversation history, and relevant variables travel with every handoff. No re-authentication. No “Can you confirm your account number again?” moments. The specialist agent already knows what it needs when the Superagent delegates the task.

Under the HoodAtlas, A2A, MCP, and What Each One Actually Does

Three PatternsFrom the Salesforce Architects Playbook, Applied in Practice

The RoadmapHow I’d Actually Sequence This in a Real Agentforce Engagement

The Bigger PictureWhat This Demands of Us as Salesforce Architects

I want to close with something that isn’t in the Salesforce architecture documentation, because it’s what I actually sit with after a long implementation day.

For fifteen years, most of my work as a Salesforce architect was about connection: connecting systems, connecting processes, connecting data across org boundaries. The hard problems were integration problems. SOMA, MOMA, and 3P agent architecture changes the nature of the hard problem. It’s now about decomposition: deciding what each Agentforce agent should know, what it should act on, what it should defer, and what requires human judgment before anything executes.

That’s a genuinely different discipline. It borrows from system architecture, from organizational design, and from the kind of governance thinking that Salesforce has always pushed us toward, but with AI-specific wrinkles that none of our classic Salesforce certifications fully prepared us for. The architects who will thrive in the next five years are those who can hold data models, integration patterns, and agent cognition in their heads simultaneously, and make good decisions at the intersection of all three.

Build something narrow first. Get SOMA right before reaching for MOMA. Use AgentExchange before writing custom integration code. Turn on Observability on day one. And treat the Superagent layer as the governance architecture it is, not just the user-facing front door.

The platform is ready. The question is whether our architectural thinking has kept pace with it.