Salesforce Open-Sourced Agent Script: Can Business Rules and AI Reasoning Finally Work Together?

Salesforce’s open-sourced Agent Script gives Sydney and NSW businesses a practical way to combine fixed operating rules with AI judgement in one reviewable agent specification. It can lock identity checks, approval thresholds, action sequences and escalation conditions while leaving classification, explanation and exception interpretation to a large language model.

The breakthrough is not fully autonomous AI. It is a clearer control boundary, provided organisations first resolve policy ownership, data access, testing and change-control responsibilities.

Enterprise AI has spent several years oscillating between two unsatisfactory models. Traditional workflow engines are dependable but struggle with ambiguity. Large language models can interpret complicated requests but may not apply the same operational rule consistently.

Salesforce’s Agent Script attempts to place both approaches inside the same reviewable file.

The Missing Layer Between Policy Manuals and AI Prompts Most businesses do not lack rules. They have service policies, authority limits, escalation matrices, contract conditions, safety procedures, privacy requirements, quoting controls and project-delivery standards.

The problem is that these rules are usually distributed across procedure documents, emails, spreadsheets, software settings and the experience of individual employees. When an AI agent is introduced, teams frequently try to compress that fragmented operating model into a long natural-language prompt.

A prompt may tell an agent to verify a customer, avoid unauthorised discounts and escalate sensitive complaints. It does not necessarily guarantee that the agent will perform those steps in the correct sequence, use the current approval threshold or prevent an unavailable action from being selected.

Salesforce describes Agent Script as a control plane for agentic decisions . Instead of choosing between a fully scripted workflow and a largely autonomous reasoning loop, an organisation can decide how much control to apply to each individual decision.

That per-decision boundary is the significant development. It creates a possible operating contract between the people who write business policy and the systems that execute it.

What Salesforce Has Actually Open-Sourced Agent Script is a single-file, indentation-sensitive language developed for configuring agent behaviour. It can:

Define typed variables Retain state Specify conditional logic Control action availability Organise subagents Place natural-language reasoning instructions around deterministic procedures Salesforce has made the language specification and much of its development toolchain publicly available through the Salesforce Agent Script open-source repository .

The repository includes:

The parser The linter The compiler Language-server capabilities Editor integrations The formal specification A browser-based playground This makes an Agent Script file capable of being reviewed, compared, validated and moved through a software development lifecycle.

A proposed change to a refund threshold, access condition or escalation path can potentially appear as a visible code difference rather than a silent edit buried inside a visual builder or sprawling prompt.

Important limitation: Salesforce has not open-sourced the production runtime. The public toolchain can parse, lint, inspect and compile Agent Script, but executing Agentforce agents still depends on Salesforce’s managed environment. An open specification does not currently mean a completely vendor-neutral runtime.

A Rule Can Change What the Model Is Allowed to See and Do Conventional prompts often give an LLM a broad set of instructions and tools, then rely on the model to decide when each tool should be used. Agent Script can narrow that choice dynamically.

Its conditions are re-evaluated as the conversation and stored state change. An action can remain absent from the model’s available toolset until a required condition has been satisfied.

Consider a customer-service agent dealing with an account-level request. Before identity verification, the agent may be able to explain the verification process but have no access to the account-retrieval action.

Once a verified state is recorded, the action can become available. The model is not merely told not to use the tool. It is not offered the tool until the rule allows it.

The same pattern can apply to:

Payment approvals Project variations Contractor dispatch Document release Refund authority Property-access instructions It moves critical controls from behavioural advice into executable conditions.

Three Decision Lanes Are Better Than One Autonomous Queue A workable enterprise agent should not treat every decision as either completely automated or completely manual. Operations teams need at least three decision lanes.

Deterministic rule

Suitable work:

Identity gates Approval limits Required fields Restricted actions Mandatory sequences Eligibility conditions Typical control:

Typed variables Conditional expressions Action availability Fixed transitions Primary owner: Operations, compliance and system owners.

AI reasoning

Suitable work:

Intent classification Summarisation Information extraction Explaining options Interpreting unstructured requests Typical control:

Bounded instructions Approved data sources Limited tools Evaluation scenarios Primary owner: Product, operations and AI teams.

Human authority

Suitable work:

High-value variations Legal conclusions Safety exceptions Disputed facts Sensitive complaints Residual-risk acceptance Typical control:

Escalation Approval queues Evidence packages Recorded decisions Primary owner: Authorised managers and specialists.

The practical value of Agent Script is not that it eliminates one of these lanes. It can make the boundaries between them more explicit.

What This Could Look Like in Sydney Property Operations Consider an agent receiving enquiries for flooring removal and installation works in a Sydney apartment building.

The customer may provide an address, several photographs and a preferred installation date, but omit whether:

The property is occupied The property is strata managed A service lift has been booked Parking and waste access have been arranged Asbestos and hazardous-material risks have been assessed A purely scripted form can collect standard answers but may struggle when the customer describes the project informally.

A purely reasoning-based agent may understand the request but prematurely suggest dates, prices or access arrangements that have not been confirmed.

A mixed control model could operate as follows:

AI interpretation: Classify the requested works, identify the likely property type and extract the stated rooms, flooring materials and programme constraints. Deterministic completeness check: Require occupancy, parking, lift, access, waste-transfer and strata information before the project can move to scheduling review. Restricted action: Prevent the agent from confirming a booking while building access or required approvals remain unverified. AI explanation: Explain which missing details are holding the programme and why those details affect delivery. Human authority: Route unusual substrates, hazardous materials, substantial variations, disputed scope or non-standard access conditions to an authorised project manager. Deterministic handover: Release the approved booking, project brief or contractor instruction only after the necessary states and approvals have been recorded. The model handles language and ambiguity. The operating rules control when the business may make a commitment.

The Hardest Work Happens Before Anyone Writes the Script Agent Script can express a business rule, but it cannot determine whether the underlying rule is current, lawful, internally consistent or operationally practical.

Before scripting begins, the organisation needs a rule inventory. This is a deeper exercise than collecting existing procedure documents because many real-world rules are undocumented or applied differently by different teams.

The discovery process should identify:

Which event activates each rule The information needed to evaluate it The system regarded as the authoritative source The action permitted or prohibited by the rule The person authorised to approve an exception The evidence that must be retained The rule owner and review date What should happen when required data is missing or contradictory Elyment’s earlier analysis of documenting workflows before AI is allowed to change live systems remains relevant here.

A reviewable language improves control only after the operating process itself has been made reviewable.

Rule Ownership May Become More Important Than Model Selection Businesses often assign an AI project to a technology team, even though the most consequential decisions concern operational policy.

A developer can implement a condition stating that variations above a certain value require approval. The developer should not have to decide:

What that value is Whether GST is included Whether the threshold applies cumulatively Whether the threshold changes by project stage Who may approve an emergency exception Those are operating-model decisions. They may involve finance, legal, compliance, project delivery, customer service and executive risk ownership.

Every load-bearing rule should therefore have:

A named business owner An approved source policy A version and effective date Test scenarios covering ordinary and exceptional cases A defined change-approval pathway A rollback process if the change produces unintended outcomes The agent file can become the executable expression of policy, but it should not become the place where policy is invented without authority.

Deterministic Logic Can Still Produce the Wrong Result The word deterministic can create a false sense of safety. Code may apply a rule consistently and still produce an unacceptable outcome because the input, rule or connected action is wrong.

Incorrect source data

Operational example: The customer record shows an outdated authority level or property-access contact.

Required control: Source validation, freshness checks and accountable data ownership.

Incomplete rule

Operational example: A price threshold is coded without considering cumulative variations or the project stage.

Required control: Scenario review by finance and operations.

Wrong classification

Operational example: AI categorises a safety complaint as a routine service enquiry.

Required control: Conservative escalation triggers and classification testing.

Tool-side failure

Operational example: The agent follows the correct sequence, but the connected system creates a duplicate booking.

Required control: Idempotency, transaction checks and reconciliation.

Policy drift

Operational example: The script still applies a superseded approval limit.

Required control: Effective dates, review schedules and controlled releases.

Exception overload

Operational example: Staff routinely bypass the formal rule because it does not reflect live project conditions.

Required control: Exception analysis and policy redesign.

A reliable system therefore needs more than valid syntax. It needs reliable data, controlled integrations, meaningful tests and post-deployment reconciliation.

Open Source Improves Inspection, Not Automatic Portability Open-sourcing the specification and tooling gives developers, researchers and enterprise teams greater visibility into how Agent Script is structured.

It also allows coding tools to inspect the formal language rather than guessing what valid output should look like.

That can improve:

Code generation Validation Editor support Internal review Experimentation Discussion of common agent-specification patterns Businesses should nevertheless distinguish four separate concepts:

An open language specification Open development tools A portable agent definition An open, interchangeable production runtime Agent Script currently provides the first two most clearly.

Salesforce states that execution is conceptually decoupled from specification, but its production runtime remains proprietary.

Procurement teams should therefore assess:

Platform licences Data architecture Integration costs Model availability Observability Exit arrangements The effort required to reproduce agent behaviour elsewhere Why the NSW Governance Context Matters Agent Script is a technical control mechanism, not a compliance framework.

Sydney organisations still need to assess the legal, privacy, consumer, security and accountability consequences of the decisions their agents make.

The NSW AI Assessment Framework is mandatory for NSW Government agencies rather than private businesses.

However, its emphasis on risk identification, documented controls, accountability, transparency, privacy, security and residual-risk acceptance provides a useful assurance benchmark for private operators and government suppliers.

The 2026 framework was expressly updated to capture newer capabilities, including agentic AI. This is relevant where an agent can move beyond producing content and begin selecting actions, changing records or influencing consequential decisions.

The Office of the Australian Information Commissioner’s guidance on privacy and commercially available AI products confirms that the Privacy Act applies when AI systems handle personal information.

Organisations need to understand:

What information enters the agent Where that information is retained Which connected actions can retrieve further data Whether information is disclosed to service providers Who can inspect or correct the resulting records From 10 December 2026, relevant Australian Privacy Principle entities will also face additional privacy-policy transparency obligations where they arrange for computer programs to use personal information to make decisions that could reasonably be expected to significantly affect an individual’s rights or interests.

The Australian Government’s Guidance for AI Adoption provides a broader governance reference for organisations developing, customising or using AI in complex and higher-risk settings.

Where agents communicate prices, inclusions, timelines or service commitments, existing consumer-law obligations also remain relevant.

NSW businesses should review NSW Fair Trading guidance on dealing with customers and the ACCC’s guidance on false or misleading claims .

An AI-generated representation is still a representation made through the business’s service channel.

A Practical Production Pathway Moving from a promising Agent Script demonstration to a controlled operating system requires a staged project rather than an immediate connection to live customers and records.

Define the operating outcome. Specify the service, transaction or project result the agent is expected to support. Avoid starting with a general ambition to automate a department. Map decisions and authority. Identify each material decision, the evidence it requires and the person or rule authorised to make it. Allocate the decision lane. Decide whether each decision belongs to deterministic logic, bounded AI reasoning or human approval. Restrict data and actions. Give the agent only the information and tools required for the approved use case. Elyment’s analysis of giving AI agents reliable business context explains why access to more information is not the same as access to better information. Build scenario-based tests. Include normal requests, missing data, conflicting information, repeated actions, policy exceptions, hostile instructions and downstream system failures. Release through controlled stages. Begin with read-only or recommendation modes before enabling record changes, customer commitments or financial actions. Monitor outcomes, not only uptime. Review rule execution, agent classifications, escalations, overrides, customer complaints, duplicate actions and unexpected tool sequences. Control every rule change. Treat changed thresholds, conditions, tools and prompts as production releases with documented approval and regression testing. This sequencing aligns with the broader need to prepare business systems before AI agents move from idea to production and to contain autonomous agents inside properly segmented environments .

Where Implementation Costs Will Actually Appear Agent Script may make agent logic easier to inspect, but the script itself is unlikely to be the largest programme cost.

Expenditure will typically concentrate around:

Policy discovery and reconciliation Data cleanup and authoritative-source selection Integration and permission design Simulation and regression testing Privacy, security and legal review Human escalation capacity Monitoring and incident investigation Ongoing policy and script maintenance Organisations with inconsistent business processes may discover that the AI programme is exposing an operational-design problem rather than creating one.

If five employees apply five different versions of a rule, writing an agent specification forces management to decide which version is authoritative.

That decision can improve the underlying business even before an agent is deployed.

The Questions Boards and Project Sponsors Should Ask Which decisions are fixed by code, and who approved those rules? Where is the model permitted to interpret, classify or choose an action? Which actions remain unavailable until defined conditions are satisfied? What happens when the required data is missing, stale or contradictory? Can reviewers see exactly what changed between agent versions? Which scenarios must pass before a release reaches production? Who reviews overrides, complaints and unexpected agent behaviour? Can the organisation suspend an action without disabling the entire service? What would be required to move the workflow to another runtime or platform? Who accepts the residual risk after technical controls are applied? These questions move the conversation away from whether an agent appears intelligent and towards whether the operating system around it is accountable.

Review the rule boundary before the agent reaches live customers and projects.

Map deterministic controls, reasoning permissions, data sources, approval limits, human escalation and release sequencing before an AI agent is connected to operational systems.

Request an Operational AI Project Review

Rules and Reasoning Can Work Together, but the Boundary Must Be Designed Agent Script addresses one of the most important weaknesses in enterprise agent design: the assumption that an organisation must choose between rigid workflows and open-ended AI reasoning.

A reviewable specification can preserve deterministic controls around identity, authority, sequence and action availability while allowing a model to interpret language, assemble context and manage less predictable interactions.

That does not make an agent automatically safe, compliant or operationally correct. It makes the control boundary more visible and potentially easier to test, approve and change.

For Sydney and NSW organisations, the opportunity is not to convert every policy into code or let AI resolve every exception.

It is to build a more disciplined operating model in which the business can identify:

Which rules must never be improvised Which judgements may be delegated Which decisions must remain with an authorised person Sources and Further Reading Salesforce: Agent Script as a control plane for agentic decisions GitHub: Salesforce Agent Script open-source repository NSW Government: NSW AI Assessment Framework Office of the Australian Information Commissioner: Privacy and commercially available AI products Australian Government: Guidance for AI Adoption NSW Fair Trading: Dealing with customers Australian Competition and Consumer Commission: False or misleading claims