Agentforce has changed what’s possible for teams building on Salesforce to be safe here It has also introduced a decision that many teams still struggle to make well: when does a requirement actually call for an agent, and when does it not?
Reach for an agent too early and you introduce latency, cost, and reasoning unpredictability into processes that a deterministic flow could handle reliably in milliseconds. Avoid agents for too long and you leave meaningful value on the table. Architects need a way to make these decisions using repeatable criteria, not instinct.
The Determining Agentic and Traditional Workflow Automation Decision Guide outlines the Orchestration Density framework, a structured way to measure the reasoning complexity of a workflow and map it to the right architectural pattern before opening any builder. The principle stays the same no matter the underlying use case: start with the lowest density level that can achieve the goal.
This post provides an overview of the Orchestration Density framework and five real-world automation use cases that demonstrate how to apply the framework across different requirements.
Orchestration Density measures the reasoning complexity of a workflow’s path toward a goal. Three factors determine it, evaluated in sequence: execution path, goal complexity, and modality mix.
Execution path is the most important and the first factor to evaluate. Can you fully specify the workflow at design time? If you can draw every branch and outcome without leaving a blank node, traditional automation is your starting point.
A blank node is not a gap to fill in later. It is a signal that the next step cannot be known until runtime, not because the data is missing, but because the step itself depends on something that cannot be anticipated at design time. That is where an agent belongs.
One nuance: a fully specifiable path does not automatically rule out an agent pattern. Agent Script provides deterministic control within an agentic context, which is the right choice when you need conversational handling or a defined escalation path alongside a structured workflow. But if the path is fully specifiable and has no reasoning requirement, then traditional automation is the answer.
Goal complexity asks one question about each decision point: can you write the rule? If every decision can be expressed as an explicit condition, complexity is low regardless of how many conditions exist. Flow can handle enormously complex logic, hundreds of conditions, multiple objects, and sophisticated branching – and still be the right answer.
The signal that points to an agent is when the decision space is genuinely open: when the right outcome depends on context that cannot be reduced to a field value. The distinction is rule-resolvable versus judgment-resolvable, not simple versus complex.
Modality mix identifies the infrastructure the workflow requires. Structured CRM fields, semi-structured documents (like email bodies or case transcripts), and real-time unstructured streams (like live audio or telemetry), each require different capabilities.
A high modality mix does not automatically mean high Orchestration Density. A single AI step called from an otherwise deterministic flow can be enough. Modality mix tells you whether reasoning is required on the data, not what the orchestration pattern should be.
Put the three factors together and you get a composite score that maps to an architectural pattern.
Before evaluating any requirement, draw the process. Map every branch, annotate every input and output, and mark every decision point as rule-resolvable or judgment-resolvable. The structure of that diagram is your assessment.
Use the Determining Agentic and Traditional Workflow Automation guide to map your requirements to the right Salesforce tool.
The use case: a swarm of autonomous agents deciding when to send proactive outage notifications, with each agent responsible for assessing impact and determining the right message for its customer segment. The reasoning sounds plausible. Outage impact varies by segment, and the right notification depends on context.
Run it through the framework.
Orchestration Density: low.
All three factors point away from an agent. But the nonfunctional requirements close the case completely. Outage notifications require message consistency: legally reviewed, brand-safe, identical for every customer in the same segment. They require a full audit trail: when a customer challenges why they received a particular message, you need to show exactly what was sent and why. And they require speed: flows execute in milliseconds. An agent reasoning about whether something qualifies as an outage adds latency to a time-critical process.
The agent swarm also removes the one thing you need most in an incident: a named decision owner. When something goes wrong, “the agents decided” is not an answer.
This is a Flow and Apex use case.
The use case: an agent using a structured prompt template to generate pricing estimates for quotes, handling the variable inputs of product mix, volume tiers, discount eligibility, and regional pricing. When you demo it, it looks great. Well-formatted, professional, plausible numbers. That surface quality is the trap.
Run it through the framework.
Orchestration Density: low.
That verdict does not change no matter how complex the pricing rules are. Complexity does not change the density level. Rule-resolvable is rule-resolvable.
The deeper problem is what large language models (LLMs) actually do: they predict the next token. They are not calculating. Two identical inputs can produce different outputs due to model version changes or prompt drift. A commercial commitment cannot depend on that. Salesforce CPQ and Apex encode pricing rules explicitly, producing the same defensible number every time, traceable to a specific rule in a dispute.
The use case: the same quoting domain as the previous example, but with a different question. Instead of generating the pricing estimate, the agent handles the scoping conversation first, asking about product mix, volume, use case, and timeline, handling follow-up questions, ambiguous answers, and the customer who is not quite sure what they need yet. Once it has a complete picture, it hands structured inputs to CPQ to do the calculation.
Run it through the framework.
Orchestration Density: medium.
The domain is identical and the right answer is completely different. The agent scopes and CPQ prices, not the other way around, and that boundary between agent and deterministic logic is deliberately designed. The agent handles the part of the problem that cannot be specified in advance, and CPQ handles the part that must produce the same defensible number every time.
The use case: an Agentforce agent on a customer portal handling product and billing questions, grounded in Salesforce Knowledge, with a defined escalation path to a human when confidence is low.
Run it through the framework.
Orchestration Density: high.
Importantly, there is no lower-density alternative to reach for first, because there is no flow that can handle this. The path cannot be drawn, which means the agent is not replacing a deterministic process but filling a gap that deterministic tooling was never able to fill. The grounding in Knowledge and the explicit escalation path are not optional additions to make this production-ready. An agent that cannot say it does not know and route to a human is not a successful customer service agent.
The use case: an agent that qualifies inbound leads, handles objections, books meetings, and manages multitouch email outreach autonomously, handing off to Flow when a lead meets qualification thresholds.
Run it through the framework.
Orchestration Density: high.
One architectural point worth making explicit: the deterministic parts should stay deterministic. CRM lookups are tool calls, escalation rules are explicit conditions, and the handoff to the rep when qualification thresholds are met is Flow. The boundary between agent and Flow is a design decision, and getting it right is what separates a production-ready implementation from a demo. The reason this clears the high-density bar is straightforward: you cannot write a flow for objections you have not seen yet, and if you cannot write the rule, you need the reasoning.
The five use cases above are not edge cases. They are the kinds of requirements landing in architecture reviews right now, and the pattern across them is consistent. The ones that fail share a structure: specifiable paths, rule-resolvable decisions, and a solution that adds reasoning overhead where determinism would do the job better, faster, and with a cleaner audit trail. The ones that pass share the opposite: paths that cannot be drawn in advance, decisions that require judgment, and in some cases no deterministic alternative at all.
When you apply the framework, there are three questions to ask every time. Can you draw every branch? Can you write the rule? Does it need to process or produce unstructured data? You have just applied them to five real use cases and the framework worked the same way each time, regardless of how complex or agent-shaped the requirement looked on the surface.
Before your next automation requirement, reach for those questions before you reach for any builder. If the path is fully specifiable, start with Flow. If every decision is rule-resolvable, keep it deterministic even if the rules are numerous and complex. If you find blank nodes or judgment calls, that is when an agent is called for. Remember, always start at the lowest density level that can achieve the goal.
For a structured way to work through the composite score and map it to a specific architectural pattern, the Determining Agentic and Traditional Workflow Automation Decision Guide has the full decision matrix. Use it as your starting point, then pressure-test against your latency, cost, and auditability constraints before you commit to a pattern.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。