Agentforce behavior is built from several layers that answer different questions: what kind of work should handle this request, what guidance should shape the reasoning, what business capability can the agent execute, and what deterministic controls should govern the path? In 2026 Salesforce changed one important term in that model: beginning in April, agent “topics” are called subagents. Salesforce states that the functionality did not change, so older material and search queries may still use the former name.
For the Salesforce Agentforce Specialist, separating subagents, instructions, actions, and Agent Script helps prevent an agent from becoming one giant block of prose. Each layer has a different responsibility, and reliability improves when those responsibilities are explicit.
Subagents organize a domain of responsibility
A subagent groups behavior around a recognizable area of work. It helps the agent determine which set of instructions and capabilities should apply to a user request. A service agent might have subagents for order status, returns, account updates, or troubleshooting rather than treating every conversation as one undifferentiated reasoning problem.
The boundary should be meaningful to the business. If two subagents have nearly identical purpose and overlapping instructions, classification becomes harder and maintenance doubles. If one subagent covers every possible request, it stops providing useful structure.
Design names and descriptions so the intended scope is clear. The classification layer needs enough semantic separation to distinguish “refund an order” from “track an order,” while related work can still share underlying actions.
A subagent should also have a clear exit condition. If it owns returns, it needs to know when the request has been resolved, when control should move to another subagent, and when human escalation is required. Without an exit model, agents can loop between instructions or continue asking for data after the workflow has already reached a terminal state.
Overlap reviews are useful before deployment. Give reviewers a list of representative utterances and ask which subagent should own each one. If experienced team members disagree repeatedly, the boundary is probably too vague for reliable automated classification.
Instructions tell the agent how to behave inside that responsibility
Instructions provide natural-language guidance about goals, constraints, tone, sequencing, and decision criteria. They can tell the agent to verify an order number before discussing a shipment, avoid promising a refund until eligibility is checked, or ask for clarification when a customer provides an ambiguous identifier.
Good instructions are specific enough to guide behavior but not so long that priorities become contradictory. If one instruction says “always solve the issue without escalation” and another says “escalate whenever identity cannot be verified,” the agent needs an explicit precedence or deterministic branch to avoid inconsistent outcomes.
Instructions should describe policy, not hide executable business logic in prose. A statement such as “refunds over $500 require manager approval” may belong in guidance, but the actual approval check and transaction should be implemented through a governed action or deterministic flow rather than trusting the language model to remember a numerical rule.
Actions give the agent permission to do work
An action is a callable capability the agent can use to retrieve data, update systems, invoke automation, or perform another business operation. The agent should not be able to perform an operation merely because the instruction mentions it; the capability must exist and be available in the agent design.
Actions create an important governance boundary. A “Get Order Status” action can expose only the fields required to answer the customer. A “Cancel Order” action can enforce eligibility and authorization before making a change. This is safer than giving an agent broad, undefined access to underlying data and expecting instructions alone to constrain behavior.
Design action names, inputs, and outputs so the reasoning layer can use them correctly. Ambiguous actions produce ambiguous plans. If two actions both seem to “update customer,” clarify which fields and conditions each owns or consolidate the capability.
Actions should also expose errors in a form the agent can reason about. A generic “500 error” gives the workflow little guidance. A structured result such as not_authorized, not_eligible, or system_unavailable allows Agent Script to route to different recovery behavior without asking the language model to infer what a backend failure meant.
That separation makes audit trails stronger. Reviewers can distinguish a policy decision made by deterministic logic from a conversational explanation generated around that decision. In regulated or high-impact workflows, that distinction can be more important than stylistic fluency.
Agent Script adds deterministic structure to agent workflows
Salesforce describes Agent Script as the language for building agents in Agentforce Builder. It combines natural-language instructions with programmatic expressions so builders can define conditions, transitions, variables, subagent selection, and action execution with more predictable control.
This is important because not every decision should be left to language interpretation. A business rule such as “if the order total is above the approval threshold, route to the approval path” is clearer as an explicit condition. A sequence such as verify identity, retrieve the account, then run a transaction can be represented as controlled transitions rather than hoping the model chooses the same order every time.
Agent Script does not eliminate generative reasoning. It creates a framework around it. The agent can still interpret language and generate responses where flexibility is useful while deterministic expressions govern the points where policy and sequence require precision.
Canvas and Script views represent the same underlying design
Current Agentforce Builder lets users work with Agent Script through different authoring experiences. Canvas view summarizes the design into visual blocks, while Script view exposes the language directly for advanced editing. Builders can also use conversational assistance to describe desired behavior and have the system produce or modify the underlying structure.
The important concept is that the visual editor and the script are not separate agents. They are different ways to inspect and change the same behavioral model. Teams should choose the view that makes the current task easiest while still reviewing the resulting logic.
Visual authoring can improve collaboration with administrators and business owners. Script view can make complex conditions, transitions, or variable behavior easier to inspect precisely. Both benefit from version control discipline and testing.
Use variables and transitions to preserve context deliberately
Variables carry information through the agent workflow. A verified customer identifier, selected order, eligibility result, or computed business value can be stored and reused instead of being re-derived from conversational text at every step.
Transitions make the allowed movement between parts of the workflow explicit. After identity verification, the agent might move to an order-management subagent. If verification fails, it might move to an escalation path. These transitions create understandable control flow around the model’s flexible language processing.
Keep variables scoped to what the workflow needs. Storing excessive sensitive context “just in case” creates privacy and debugging problems. Naming also matters: verifiedCustomerId is more useful than a generic variable named value1.
Action chaining should represent a business transaction, not a guessing game
Agent Script can control when actions run in sequence, sometimes described as action chaining. The key design question is which steps are prerequisites. If an action changes data, earlier steps should establish the identity, authorization, and business state required for that change.
For example, a cancellation workflow may first retrieve the order, then check whether it is cancellable, then perform the cancellation, and finally retrieve the updated state for confirmation. Each action has a narrow purpose, and the script controls the order. The agent should not call the mutation first and discover afterward that the order was ineligible.
Failures need paths too. If the eligibility action returns an error or a backend system is unavailable, define whether the agent retries, explains the limitation, offers an alternative, or escalates. Reliable workflows model failure as a normal branch rather than an exceptional surprise.
Governance improves when policy is split across the right layer
Use subagents to define responsibility, instructions to define behavioral guidance, actions to expose approved capabilities, and Agent Script expressions to enforce deterministic policy and sequence. This separation makes reviews more productive because security teams can inspect actions, business owners can review instructions and policy branches, and builders can test classification and transitions.
It also prevents overloading prompts. A 200-line instruction block that mixes customer tone, data access, numerical thresholds, transaction sequencing, and escalation policy is difficult to audit. Splitting the design into explicit components makes changes smaller and their impact easier to predict.
Test the behavior at each layer
When an agent gives the wrong result, identify which layer failed. Did the request route to the wrong subagent? Did the correct subagent have ambiguous instructions? Did the agent select the wrong action? Did the action return unexpected data? Did an Agent Script condition send the workflow down the wrong branch?
Testing at that granularity makes remediation targeted. Rewriting every instruction because one action has a faulty input mapping can introduce new errors. Likewise, changing an action because the classifier selected the wrong subagent treats the symptom rather than the cause.
The Salesforce Agentforce model is becoming more structured as agent workflows move into production use. The terminology may evolve—such as topics becoming subagents—but the design principle remains stable: flexible language reasoning should operate inside clear responsibilities, governed actions, and deterministic controls wherever the business requires predictable behavior.