Apply the Orchestration Density Framework to Your Next Automation Decision

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.

Understand what Orchestration Density measures

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 

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

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

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.

Interpreting the factors in combination

Put the three factors together and you get a composite score that maps to an architectural pattern. 

• Low density means Flow or Apex leads, even if it makes tool calls 
• Medium density means Agent Script does more of the work, calling Flow or Apex actions as needed
• High density is where one or more agents are the only practical architecture

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 case 1: Outage notifications belong in Flow, not an agent swarm

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.

• Execution path: The trigger is binary. A threshold is crossed or it is not. You can draw every branch before you build. There are no blank nodes. 
• Goal complexity: Is this an outage? That is a metric threshold. Who gets notified? That is a segment rule. What does the message say? That is a controlled template. Every decision is rule-resolvable. 
• Modality Mix: Structured monitoring metrics in, controlled messages out. Nothing unstructured in the workflow.

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. 

Use case 2: Plausible is not the same as correct on quote pricing

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. 

• Execution path: A quote follows a defined structure you can draw before you build. It is fully specifiable.
• Goal complexity: Discount eligibility is a rule, tier pricing is a rule, and regional adjustment is a rule. Every decision is rule-resolvable. The prompt template is not adding reasoning. It is wrapping rules in prose. And if you can write the rules in prose, you can write them in logic. 
• Modality mix: Structured data in, structured data out.

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. 

Use case 3: Let the agent scope and CPQ price

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. 

• Execution path: The broad shape of the conversation is knowable, but the specific path depends entirely on what the customer says, and you cannot draw every branch because the next step is not determined by data but by what the customer says next and what the agent judges it still needs to know. Partially specifiable. 
• Goal complexity: Deciding which question to ask next, how to handle an ambiguous answer, and when enough information has been collected to hand off are judgment calls, not rules. They are judgment-resolvable at the conversation layer and rule-resolvable on the pricing. 
• Modality mix: Natural language in, structured quote inputs out. 

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.

Use case 4: Inbound customer service has no deterministic alternative

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.

• Execution path: You do not know what questions the customer will ask, in what order, or how they will frame the issue. Further, the next step is not determined by data but by what the customer says and what the agent judges it needs to do next. Non-specifiable.
• Goal complexity: The same agent must handle a simple entitlement question and a complex multisystem billing dispute without knowing which one it is facing until the conversation unfolds, and every response requires contextual reasoning rather than a condition it could have evaluated at design time. Judgment-resolvable throughout.
• Modality mix: Natural language throughout, with no structured fields to reason from.

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.

Use case 5: Lead nurturing can’t be drawn in advance

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.

• Execution path: You do not know which leads will respond, what they will ask, or what objections they will raise, and because the next step depends on what the lead does next rather than a condition you could have evaluated at design time, the path cannot be drawn in advance. Non-specifiable.
• Goal complexity: Qualifying, nurturing, objection handling, and meeting booking are competing objectives that shift in priority depending on what the lead does next, and you cannot write a rule for an objection you have not seen yet. Judgment-resolvable throughout.
• Modality mix: Natural language in, structured CRM updates out, with the agent interpreting the conversation and writing back to structured records.

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.

Apply the framework before you open any builder

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.