SOLID Principles for AI Agents: Designing Agentforce’s Multi-Agent Future

Every Salesforce dev has met the god class. Four thousand lines, imports from every layer of the app, writes to the database directly, sends email, generates PDFs, and formats phone numbers on the way out. Change one thing and something unrelated breaks. Nobody remembers why line 1,847 is there, and nobody is going to be the one who deletes it.

Now give that class the ability to call other classes like it. Autonomously. In production. At 2am.

That is roughly where agent-to-agent orchestration is heading in Agentforce. Multi-Agent Orchestration, A2A protocol support, native MCP clients: the plumbing for agents to discover each other, hand off work, and coordinate across systems is landing fast. Most of the conversation right now is about what agents will do. Almost none of it is about how we should design them.

Object-oriented codebases hit this same wall in the late 90s, and Robert Martin gave us SOLID as a vocabulary for the argument. Five principles that read as academic until you inherit a codebase that ignored them. They map onto agent design better than they have any right to, so here they are, one at a time, against what Agentforce is actually asking us to build.

S: one agent, one job

Agentforce’s multi-agent model has a primary agent that owns the conversation and secondary specialist agents that take delegated work. That is single responsibility with a Salesforce logo on it.

The temptation is to build agents the way people build Flows. Start with one, keep adding, and six months later there is a Customer Agent that answers billing questions, escalates cases, recommends products, looks up orders, and generates renewal quotes. When it hallucinates, which of those five things was it even attempting?

An agent with five jobs is an agent whose failures you cannot diagnose.

The Atlas Reasoning Engine routes work based on each agent’s description, instructions, and available actions. That is a design constraint, not an implementation detail. Routing quality tracks directly with how cleanly your agents’ responsibilities separate. Two agents with overlapping scope means Atlas is picking between near-duplicates on every turn, and users experience that as routing that feels random.

Check: describe the agent in one sentence without using the word “and.” If you cannot, split it.

O: extend by adding agents, not editing them

Open for extension, closed for modification. In classic OO that meant inheritance and interfaces. In an agentic system it means the orchestration layer should not have to change when you add a capability.

A2A is built around exactly this. An agent publishes an agent card, a machine-readable resume advertising its capabilities, endpoint, auth requirements, and I/O expectations. Client agents discover remote agents by reading cards rather than through hard-coded integrations. New capability, new agent, new card. The orchestrator finds it by advertised skill.

The anti-pattern is baking knowledge of specific downstream agents into your primary agent’s instructions. “If the user asks about shipping status, invoke ACME-Shipping-Agent-v2” is a switch statement in a trench coat. When ACME ships v3, you are editing the orchestrator, which is the brittle point-to-point integration A2A exists to kill.

Check: when you add a new specialist, how many existing agents did you have to modify? If the answer is not zero, your extension point is in the wrong place.

L: agents have to be swappable

If your orchestrator delegates “check pricing” to a pricing agent, it should be able to hand that task to any pricing agent, wherever that agent runs, without the orchestration logic caring.

The trap is that A2A gives you a structural contract. Tasks, messages, artifacts. It cannot give you a semantic one. Pricing Agent A returns a discount as a percentage. Pricing Agent B returns it as a dollar amount. Structurally identical, semantically incompatible, and your downstream math is now quietly wrong in a way that sails through testing unless you test the substitution itself.

Substitution is coming whether you plan for it or not. Agentforce is deliberately pitching a mixed ecosystem: your agents, AppExchange partner agents, third-party agents over A2A, MCP-connected tools. Swapping a specialist is not an edge case, it is the product.

Check: could you swap one specialist for another vendor’s equivalent tomorrow? Whatever breaks is your real contract, and right now it probably only exists in your head.

I: thin agent cards, narrow actions

Nobody should be forced to depend on interfaces they do not use. The agent version of that is an agent card advertising forty skills backed by an action library that would embarrass a Flow pack.

Fat interfaces hurt more in agent systems than in code, for one specific reason: every advertised capability costs the model attention. Atlas reads descriptions and action lists to route. A specialist with 35 actions pays a context tax on every invocation, and the routing model wades through irrelevant options to find the one that matters. Worse decisions and higher latency, both bought with a kitchen-sink design.

Segregate hard. A quote generation agent and a quote approval workflow agent look similar until you notice one runs constantly, the other runs rarely, and they need very different guardrails. Separate cards, separate action sets, separate observability.

Check: pull the actions your agent actually executes from Command Center logs. If 80% of invocations use 20% of the advertised skills, you have two agents in one costume.

D: depend on capabilities, not agents

This is the one that makes the other four hold up. High-level modules should not depend on low-level modules. Both should depend on abstractions.

Your primary agent is the high-level module. The abstractions are capabilities: can price a quote, can check order status, can draft a case summary. The concrete implementation is whatever agent currently provides that capability, wherever it happens to live.

A2A’s discovery model is dependency inversion expressed as a protocol. The client agent asks who advertises this skill instead of calling the shipping endpoint it already knows about. Pair that with MCP on the tool side, where MCP is how an agent reaches tools and data and A2A is how agents work sideways with each other, and every dependency in the stack points at an abstraction.

Where it goes wrong in practice is leakage. Credentials, endpoints, and version-specific quirks creeping into orchestration instructions. Every time your primary agent’s prompt names a specific system, a specific auth flow, or a specific vendor’s response shape, the detail has climbed above the abstraction and you have inverted the inversion.

Check: read your orchestrator’s instructions and highlight every proper noun that is not a capability. Each one is a hard-coded dependency.

Where the analogy breaks

SOLID was written for deterministic code. Agents are not deterministic. An agent can violate its own contract with no code change at all, because the implementation is a model’s behavior on a Tuesday. Liskov substitution for a class is a compile-time question. For an agent it is a probabilistic one, and you will only ever get a confidence interval.

That is why the observability side of Agentforce 3, Command Center, interaction tracing, session health, is not a bolt-on. It is the type checker for a system whose types are vibes.

SOLID tells you where to draw the boundaries. Observability tells you whether anything is still inside them.

The teams that get multi-agent architecture right will not be the ones running the most agents. They will be the ones whose agents are boring: narrow, swappable, discoverable, individually unremarkable. Specialists that each do one thing, coordinated through contracts instead of conversation.

We spent twenty-five years learning not to write god classes. It would be a shame to spend the next five writing god agents.