Most Agentforce programmes still fail at the seam between agents. A service agent closes a case while a sales agent writes the same account. Each agent can look consistent inside its own scope. The collision is architectural.
Salesforce Architects already published the agentforce agent design patterns enterprise teams keep rediscovering. Greeter, Operator, and Orchestrator are not three names for “smarter chatbot.” They differ by what happens to the conversation: hand off to a human, transfer to a specialist, or stay and collate a swarm. Pick the job. Do not climb a maturity slide because Level 3 sounds better.
Overlapping scopes fail before the model does
A single agent over a narrow job is a reasonable start. Salesforce says the same: begin with a monolithic agent for common use cases, then move to multi-agent design when scale, control, and reuse require it.
The failure mode in a large org is parallel agents with overlapping scope. Service, Sales, and Field Service each get an agent. Classification descriptions sound distinct in a workshop and collide on live utterances. Two agents can both decide they own “billing” or “renewal.” Atlas reasons inside the subagents and actions you give it. It does not referee ownership you never defined.
Since April 2026, Salesforce documentation calls former topics subagents, with no functional change during the transition. The control problem is unchanged. If two subagents have similar classification language, routing is a coin toss. Test ambiguous utterances before go-live. If the same record can be updated by two agents in one window, name a writer, a reader, and an escalation path. Pattern choice does not replace that contract.
Greeter, Operator, and Orchestrator are different jobs
Read the official output types before you draw boxes.
Greeter. Natural language to determine intent, then a hand-off to a human. Salesforce’s guidance is blunt: configure it as the first contact on brand channels, collect intent, and deliver a warm transfer. It is not a multi-step operator, and it is not a swarm. Use it when the business outcome is a better human conversation, not an automated close.
Operator. Builds on Greeter. It can negotiate intent, then transfer to a specialist agent or a human. The conversation leaves the Operator. If your design still needs the original agent to answer after specialists have worked, you do not have an Operator. You have an Orchestrator with the wrong name.
Orchestrator. Manages a specialist swarm and stays the first point of contact. It passes the utterance to one or more worker agents and collates the response. Salesforce’s use case is a customer who needs several domains in one conversation, or a multi-system path that needs a single voice. That is a governance load, not a feature upgrade. Every specialist needs an owner, a subagent boundary, and a test set. If you cannot name those, do not assemble a swarm.
These three map to Salesforce’s agentic maturity levels 1, 2, and 3. That is a description of coordination complexity, not a delivery sequence you must complete. A well-owned Greeter in production beats an Orchestrator whose specialists share actions and disagree about the customer.
The catalog is larger than this trio. Listener/Feed, Answerbot, Interrogator, and Workspace sit in the same Architects guide. If a slide says four patterns cover every enterprise use case, the slide is wrong. The useful agentforce agent design patterns enterprise teams should memorise first are still Greeter, Operator, and Orchestrator, because they force an explicit decision about who remains in the conversation.
External specialists need a defined path. The companion Agentforce implementation patterns paper describes Agent2Agent (A2A) inside Salesforce, with related agents and platform events as the async transport, and Model Context Protocol (MCP) for cross-framework calls, with Agentforce as an MCP client. Confirm those behaviours in the target org and release. Do not draw a swarm across a partner endpoint until you can name the endpoint, the payload, and who can revoke it. The Agentforce 3 MCP article treats server registration as a processor and latency decision, not a toggle.
Judge and Jury is a cost, not a quality default
Judge and Jury is a separate pattern. A judge compiles a grounded prompt, sends it to two or more juror agents, and checks whether the answers are materially consistent and grounded. Salesforce’s own guidance says to use different models per juror when you can. Output type: generative insight. Maturity: level 2. It is not “Orchestrator plus safety.”
Use it when a wrong answer has a named cost: a regulated disclosure, a payment instruction, a clinical or legal statement the firm will stand behind. Do not use it on password resets and order-status lookups. Extra jurors add extra model calls and extra time. Salesforce does not publish a universal latency budget for the pattern. Measure the path you will actually run.
A common mistake is to apply Judge and Jury to every turn because a risk committee asked for “more accuracy.” Ensemble disagreement is useful only if the judge can block the response and route to a human. If the design still returns the first fluent answer, you paid for jurors and kept the original failure mode.
For routine questions, grounded retrieval plus a narrow subagent is enough. The Data 360 implementation guide maps Identity Resolution and Data Graphs when the use case needs a unified profile. Data 360 is not a tax on every agent. An agent that only reads Knowledge in one org can run without it. An agent that must speak about the same customer across billing, cases, and orders cannot.
Put rules in Agent Script and ground only what the job needs
Instructions are still probabilistic. The model interprets them. That is acceptable for tone and for “ask a clarifying question when the request is incomplete.” It is not acceptable for discount math, eligibility, consent, or “never update a closed case.”
Agent Script is the language for mixing those two layers. Expressions handle if/else, variables, action sequence, and subagent transitions. Natural-language instructions remain where the LLM should reason. The Summer ‘26 developer guide records Agent Script and the new Agentforce Builder as generally available. Confirm both in the target org. Do not plan a 2025-era “put the rule in the topic instruction” design and hope the model is obedient.
If a transition must happen, write it as a scripted condition. If the LLM may choose whether to switch subagents, expose that transition as a tool and test the refusal path. Variables hold state. Do not ask the model to remember that the caller already passed authentication.
Grounding follows the same split. Agentforce Data Libraries can index Knowledge or files for retrieval-augmented generation; Summer ‘26 also added a beta Connect API for that lifecycle. Data Graphs help when the agent must traverse relationships rather than keyword-match a document. Neither one is a substitute for source authority. Decide which repository may ground an answer, who owns conflicts, and what the agent says when retrieval is empty.
The Agentforce 360 platform article separates Agent Script from Builder access and Voice latency. Keep that split. Builder changes who can author. Script changes where determinism lives. Voice changes the latency budget. Mixing them into one “360 rollout” hides three different owners.
Observability is part of the pattern, not a dashboard afterthought. Salesforce groups monitoring under Agentforce Observability on the current Agentforce announcements page. Require session evidence for the actions and subagents you claim to control. If you cannot show which specialist answered, you do not have an Orchestrator you can operate.
When pattern ownership is split across an SI and internal teams, a program control review is the next useful step. The question is not “do we have agents.” It is whether Greeter, Operator, or Orchestrator is the job, who owns each specialist, and which rules are in script rather than prose.
What still goes wrong in production
Same classification, two owners. If “payment question” and “billing inquiry” both exist, you will spend the first month arguing with transcripts. Rewrite scopes until a blind reviewer can assign an utterance to one subagent.
Operator labelled, Orchestrator built. Teams keep the original agent in the chat while specialists work, then wonder why hand-off metrics look healthy and customers hear two answers. If the agent stays, measure collation quality and specialist latency. If it transfers, measure warm-handoff completeness and stop expecting a synthesised answer.
Rules left in instructions after Script is GA. “Apply 10% if the customer is gold” will work in a demo. In production it will fire on the wrong account, or not fire, and nobody will be able to show the rule version. Put the rule in script, Flow, or Apex. Test the miss.
Data 360 added to force a pattern. Unified profiles are required for some jobs and waste for others. If the agent never needs a cross-system customer, do not open an ingestion programme to decorate an architecture diagram.
Judge and Jury on every channel. Ensemble reasoning is a named pattern for high-cost generative answers. It is not a substitute for source control, and it is not cheaper than a human for low-stakes traffic.
Key Takeaways
- Start with Greeter when the outcome is a better human conversation, Operator when the conversation should leave for a specialist, and Orchestrator only when one agent must stay and collate.
- If the first-contact agent still answers after specialists work, you are in Orchestrator, whatever the slide says.
- Judge and Jury: extra models, extra latency, extra cost. Use it when disagreement must block the response.
- Agent Script is the home for deterministic transitions, variables, and action sequence. Instructions are for behaviour the model may interpret.
- Confirm A2A, MCP, Data 360, and Observability in the target org before you draw a swarm. The catalog is a menu. Most programmes need three conversation jobs, not every named pattern.
