.jpg)

If your Agentforce agent isn't following instructions the way you wrote them, the problem is almost never the AI; it's the architecture. Vague subagent names, overlapping descriptions, instructions doing too much, and business logic buried in natural language are responsible for the majority of agent failures in the field.
The good news: nearly all of it is fixable. This guide covers the Agentforce agent design patterns that work, with examples you can copy directly.
Agentforce agent design is the practice of structuring AI agents: their subagents, actions, and instructions, so they route correctly, execute reliably, and stay within defined boundaries.
Most agents fail because three core elements get blurred:
When these overlap, the agent gets confused. The habits below are how you keep them cleanly separated.
A subagent is a focused worker that owns one job. Three things define a good one: its Name, Classification Description, and Scope. Get all three right and routing largely takes care of itself.
The name tells the routing layer what this subagent handles. Vague names are one of the most common causes of routing failure.
Avoid names that overlap with other subagents, even slightly. If two subagents could plausibly claim the same request, routing will misfire.
This is where most routing problems start. The classification description tells the agent when to choose this subagent. It needs to cover the full range of requests in natural language, not technical shorthand, and it must be distinct from every other subagent's description.
The second version works because it maps to the actual language customers use, covers edge cases, and doesn't compete with adjacent subagents.
Scope prevents a subagent from wandering into work that isn't its job. Always define both what it can do and what it cannot.
You can read order records and create return requests. You cannot issue refunds, change prices, or edit customer account details."
The "cannot" list matters as much as the "can" list.
Actions are the tools an agent calls to get things done. How you name and describe them determines whether the agent reaches for the right one.
Every action name should describe exactly what it does: no guessing, no abbreviations.
An action's instruction tells the agent what it does and when to use it. One to two lines is the right length, but make them earn it.
Key rule: Only mark an input as required if its value is guaranteed to be available before the action runs. If a required input isn't present at runtime, the action won't execute, even if everything else is configured correctly.
Instructions guide the agent's reasoning. They don't compute, they describe. Understanding that distinction is what separates clean agent design from brittle agent design.
Be explicit about order of operations: "First verify identity using the 'Verify Customer' action, then provide account information."
Tie actions to the situations that trigger them: "Use the 'Track Order' action when a customer asks about delivery date or package location."
If a request needs classifying before anything else happens, write that under its own heading: "Classification Guidelines", then handle the steps that follow under a separate section. Splitting them gives the agent clear context about prerequisites.
Hold shared rulesL formatting standards, global do's and don'ts, tone guidance, in one place so you're not repeating them inside every subagent.
When you mention subagents, actions, or variables inside instructions, consistent formatting helps the agent recognize them.
New builder note: In Canvas view, type @ to pull subagents, actions, and variables directly into the script, the quoting convention above is primarily a legacy-builder habit.
A few rules that apply across the entire agent design, not just individual subagents:
These two features ensure the agent has the right data and only the right options available to it.
For an agent deployed on both a public signup page and a logged-in Experience Cloud site:
Filters keep restricted actions out of the picture, lower decision complexity, and steer the agent down the right path without relying on instructions to do the work.
The new Agentforce Builder introduces Agent Script, and it directly addresses the biggest pain point in agent design: getting agents to follow logic reliably.
What's actually new:
Three ways to build:
Better debugging. The new builder adds step-by-step tracing, you can see exactly what the agent did at each moment and how long each part took. A significant upgrade over guessing why a response went sideways.
If your agent isn't behaving, resist the urge to add more words to the instructions. The fix is almost always structural, a clearer boundary, a deterministic rule, or a value stored in a variable instead of left to chance. Design it like a system, and it will behave like one.
At MIDCAI, our team specializes in a wide range of Agentforce implementations, from subagent architecture and action design to Agent Script, context variable strategy, multi-agent builds, and Experience Cloud deployments. If you're building from scratch or untangling an agent that isn't working, we can help you get it right.
Got questions? We’ve got answers. Explore common queries to understand how we work and what to expect.
An Agentforce subagent is a scoped AI worker within an agent that owns a specific job — like handling password resets or processing payment transactions. It's defined by a name, a classification description that tells the routing layer when to use it, and a scope that draws its boundaries.
Most agent failures trace back to structural problems, not AI limitations: overlapping subagent descriptions that confuse routing, business logic written as natural-language instructions instead of Flow or Apex Actions, missing "cannot" boundaries in subagent scope, or required Action inputs that aren't available at runtime.
Instructions guide the agent's reasoning, they describe sequences and trigger conditions. Actions execute tasks — they interact with records, run logic, and return outputs. Business logic belongs in Actions (Flow or Apex), not instructions. Instructions that try to compute decisions are unreliable.
Best practice is to stay under 10–15 actions per subagent. More than that increases the risk of misclassification and slows execution.
Get in touch with us for any enquiries and questions
Define your goals and identify areas where technology can add value to your business
We are looking for passionate people to join us on our mission.
where your skills fuel innovation and your growth powers ours