Salesforce’s September 14 Agentforce announcement describes specialized agents across service, sales, shopping and operations. It also points to Agent Script, which the company calls an open-source language for combining model reasoning with deterministic business rules. The announcement includes customer performance examples, but these are selected vendor-reported cases rather than an independent benchmark. The more useful product question is where flexible judgment ends and a rule that must always hold begins—and how a user can see that boundary when an agent acts.
Not every step should be probabilistic
A model is useful when a customer describes an unusual problem or a seller needs to research a complex account. It is less appropriate as the sole authority for a refund ceiling, a permission check or a contractually required approval. An effective agent system can use reasoning to understand intent and choose the next step while a deterministic rule constrains the action. The exact division depends on risk, but it should be deliberate rather than an accidental prompt convention.
Think of a shopping agent that compares products, answers questions and prepares checkout. Language generation can explain a tradeoff; the price charged and inventory reserved must come from authoritative systems. A good UX shows when a suggestion is provisional and when an external transaction is about to occur. People need an opportunity to check the facts at the point of commitment.
Policy authors need their own interface
If a business rule shapes agent behavior, someone must write, test and update it. That person may be a service lead or compliance owner rather than a developer. A useful rule editor should show plain-language purpose, exact conditions, example cases, owners and version history. It should warn when rules conflict or leave a gap. A natural-language summary is helpful, but the executable representation still needs review.
Changes should be evaluated on representative historical cases before they reach live customers. When a rule changes, show the expected effect: which requests would have a different outcome, what escalation volume might change and which connected systems are affected. That makes governance a product workflow instead of an emergency process after an agent makes a costly mistake.
Orchestration multiplies ambiguity
Salesforce describes multi-agent orchestration across roles and systems. A task may begin in sales, cross into fulfillment and finish in support. Ownership can disappear at the seams: which agent has the current truth, who is allowed to act and what does the customer see if one participant fails? The interface should maintain one understandable task state even when several specialized agents collaborate behind the scenes.
Give each handoff an explicit input, expected output and fallback. If an agent cannot complete a step, a human should receive the history and the precise blocker. Avoid forcing the person to reconstruct a chain of bot messages. An orchestration graph is useful for operators, but the customer usually needs a simpler account: what has been completed, what is pending and whom to contact.
Verify outcomes, not just automation
The announcement lists headline customer results across different products and contexts. Those figures should not be combined into an average expectation. A prospective buyer needs definitions: what counted as resolved, which channels were included, how often a human corrected the result and what the comparison period was. Vendor case studies can suggest questions; they cannot substitute for a test with your customers and policies.
Pilot one journey with a small set of permitted actions and a known escalation route. Measure incorrect action rate, customer effort, human review time and the consistency of rule application. Include exceptions and adversarial inputs. If the agent makes good suggestions but the user cannot tell when it is about to act, the product still has a control problem.
A clearer contract for agent products
The promise of Agent Script is that a company can give probabilistic reasoning a stable boundary. Whether that promise works in practice depends on the quality of rules, integration and review. Product teams can use the distinction regardless of vendor: write down what must always happen, what the agent may decide, and what requires a human to confirm.
The resulting interface should not expose every implementation detail to every customer. It should reveal enough at the moment of consequence: the action proposed, the source of authority, and the path to correct an error. That is how agent flexibility can coexist with a predictable business experience.
Questions to take into your next review
- Which actions are constrained by executable rules rather than prompts?
- Who reviews rule changes against real exceptions?
- Can the customer distinguish a suggestion from a committed action?