Skip to main content
    SupportContact

    Specialist agents for Salesforce operations

    Specialist agents that run operational work in Salesforce.

    Ortoo Orchestrator coordinates specialist agents, each owning a stage of the workflow. Bounded behaviour. Observable decisions. End to end, inside Salesforce.

    Specialist agent design

    Each agent owns one job. That is what makes it reliable.

    Specialist agents on Ortoo Orchestrator replace opaque, brittle generalists with bounded units of execution, designed for production safety.

    Bounded behaviour.

    Each specialist owns one role, one set of tools, and one body of knowledge. It reads context, decides within scope, and hands off.

    Observable decisions.

    Splitting work across specialists makes orchestration traceable and recoverable. Not a chatbot, but verifiable execution logic.

    Specialists, not super-agents.

    We avoid the fragility of a single agent reasoning through an entire workflow in one prompt. Specialisation keeps behaviour consistent at scale.

    Every agent under your governance.

    You define the role, the tools, and the data each agent can touch. AI runs inside the guardrails your team sets.

    Super-agent

    One brain attempting everything

    • 01Reasons through everything in one prompt
    • 02Opaque chain of thought
    • 03Single point of failure
    • 04Hard to govern at the edges
    Outcomes: Opaque

    Ortoo agents

    A sequence of specialists

    • 01Each agent owns one task
    • 02Clear handoffs between steps
    • 03Traceable per agent run
    • 04Governed per role and tool
    Outcomes: Predictable

    Hybrid execution

    AI, deterministic, or both.

    Every agent step uses the right mechanism for the job. AI handles interpretation. Deterministic logic handles certainty. Human review handles judgment. Mix the three per step. Run agents with no AI at all, or apply AI selectively where interpretation adds real value.

    See how Ortoo Orchestrator works
    Hybrid execution diagram showing deterministic and agent layers running inside one Ortoo workflow.

    Agent anatomy

    Role, tools, knowledge, and governance. Configured into every agent.

    Every Ortoo agent is built from the same components. Configured once, reused across every workflow that needs it. Governed by IT, observable in production. The anatomy is consistent. The behaviour of each agent depends on how you configure it.

    Role

    The agent's defined purpose and decision logic. Triage, routing, resolution, enrichment, classification, supervision. The role fixes which stage of the workflow this agent owns and what success looks like there.

    Context

    The Salesforce data the agent reads at runtime: account history, case content, related records, structured fields. Scoped per agent. The agent sees what its role needs, nothing more.

    Knowledge

    Grounded reference material the agent draws from: product docs, policy guides, FAQ libraries, internal manuals. Retrieval is structured, not free-form. The agent uses sources, not speculation.

    Boundaries

    Configured limits on the agent's behaviour: confidence thresholds, escalation rules, approval gates, exception handlers. Part of the agent definition, not added after the fact. They cannot be changed at runtime.

    Tools

    The specific actions the agent can take: read fields, update records, call APIs, post to channels, trigger workflows. Configured per agent. Tools outside the configuration cannot be reached at runtime.

    Structured output

    Every agent returns typed fields against a defined schema: category, priority, confidence, recommended action, response draft. Validated before the next step acts on it. No free text into operational workflows.

    Memory

    What persists across runs: prior decisions, context from earlier steps in the same workflow, recent interaction history where relevant. Scoped per agent and per workflow. No uncontrolled state.

    Role

    The agent's defined purpose and decision logic. Triage, routing, resolution, enrichment, classification, supervision. The role fixes which stage of the workflow this agent owns and what success looks like there.

    Context

    The Salesforce data the agent reads at runtime: account history, case content, related records, structured fields. Scoped per agent. The agent sees what its role needs, nothing more.

    Knowledge

    Grounded reference material the agent draws from: product docs, policy guides, FAQ libraries, internal manuals. Retrieval is structured, not free-form. The agent uses sources, not speculation.

    Boundaries

    Configured limits on the agent's behaviour: confidence thresholds, escalation rules, approval gates, exception handlers. Part of the agent definition, not added after the fact. They cannot be changed at runtime.

    Tools

    The specific actions the agent can take: read fields, update records, call APIs, post to channels, trigger workflows. Configured per agent. Tools outside the configuration cannot be reached at runtime.

    Structured output

    Every agent returns typed fields against a defined schema: category, priority, confidence, recommended action, response draft. Validated before the next step acts on it. No free text into operational workflows.

    Memory

    What persists across runs: prior decisions, context from earlier steps in the same workflow, recent interaction history where relevant. Scoped per agent and per workflow. No uncontrolled state.

    Agent collaboration

    Defined sequences, clear handoffs.

    Agents do not improvise. Workflows define which agent runs first, what it produces, and which agent picks up next. A supervisor agent can coordinate exceptions. Context passes between agents at every handoff, structured and validated.

    Agent-to-agent orchestration: supervisor coordinating sequential specialist agents

    Context passes between agents at every handoff.

    Why orchestrated agents

    Agents alone vs agents inside Ortoo.

    A standalone agent answers a prompt. An orchestrated agent does operational work. The difference is the system around it.

    Standalone agent

    Answers prompts in isolation

    What is missing:

    • No shared context across runs
    • No deterministic fallback
    • No native Salesforce trust boundary
    • No work-item accounting

    Useful for one-off tasks. Not enough to run work end to end.

    Agents inside Ortoo

    Specialists that execute work

    enrichment, triage, routing, resolution

    What you get:

    • Context handed off between agents
    • Deterministic steps where needed
    • Runs inside Salesforce security
    • Priced per work item handled

    A standalone agent is a feature. An orchestrated agent is operational infrastructure.

    Your starting point

    Three ways to run agents on Salesforce.

    Most teams considering adopting AI agents are weighing three paths. Native Salesforce tools. A DIY build on Flow, Apex, and direct LLM calls. Ortoo Orchestrator as the execution layer. Each has trade-offs. The honest summary is below.

    Native Salesforce

    Agentforce + Flow + Apex

    • Salesforce-native by default
    • Conversational AI through Agentforce
    • Deterministic logic through Flow and Apex
    • Limited multi-step agent orchestration
    • One AI provider, one model architecture

    Best for: conversational AI and copilot patterns. Not built for multi-agent operational orchestration.

    DIY build

    Flow, Apex, direct LLM calls

    • Maximum flexibility on every detail
    • Engineering owns every line of the lifecycle
    • Governance built from scratch per workflow
    • Each agent is a custom integration
    • Months to first agent in production

    Best for: teams with deep engineering capacity and tolerance for owning AI governance internally.

    Ortoo Orchestrator

    Configured agents, orchestrated by Ortoo

    • Configured, not coded
    • Native to Salesforce, runs inside your org
    • Governance configured once, enforced system-wide
    • BYO LLM provider, per-agent model selection
    • Weeks to first agent in production

    Best for: operations teams running real workflows who need governed agentic AI without the build cost.

    See the full Agentforce comparisonSee the full DIY comparison

    Governance

    Every agent under your control.

    Governance is not a wrapper around agents. It is part of the agent's anatomy. Configured per agent, enforced, audited per run.

    1. 01

      Bounded behaviour

      Each agent operates inside the role you define, under your Salesforce permission model. What the agent cannot do is as explicit as what it can. Limits are structural, enforced by Salesforce.

    2. 02

      Validated output

      Every agent returns typed fields against a defined schema. Validated before the next step acts on it. Schema mismatches stop the workflow at validation, not in production.

    3. 03

      Confidence thresholds

      Set the threshold per agent. Below it, the workflow drafts for human review or escalates. Above it, the agent acts and the decision is logged.

    4. 04

      Observable decisions

      Every agent run is logged: trigger, context, decision, action, confidence. Audit trails are queryable and exportable.

    Adoption

    Adopt AI without taking on AI risk.

    Most enterprises are stuck between AI experimentation and AI in operations. Tools are deployed, agents run pilots, results look promising. Then production reality hits: unpredictable outputs, no audit trail across tools, cost sprawling across agent actions and tokens. Ortoo Orchestrator is the bridge from experimentation to scaled operations, with governance configured from day one.

    Stage 1

    Experimenting

    Where most teams are now. You have AI tools deployed: Copilot, Agentforce, ad-hoc prompts. They generate text, answer questions, demo well. They do not run operational workflows. No central control. No audit trail across them. Each tool sits in its own silo.

    Stage 2

    Piloting

    Where many teams get stuck. AI agents start performing tasks: classification, triage, enrichment. Real work, real volume. But execution becomes unpredictable as AI, automation, routing, and integrations interact. One bad output cascades. Cost surfaces in invoices, not in workflows. The team owning the platform spends more time stabilising than expanding.

    Stage 3

    Operating

    Where Ortoo Orchestrator takes you. AI runs as governed operational infrastructure. Specialist agents handle their stage. Every decision is logged. Cost is tracked per workflow, capped per agent. Governance is configured once and enforced. New agents are added without rebuilding the foundation. The team controls the system, not the other way around.

    You start with one agent. You expand incrementally. The governance scales with you.

    Agent types

    Specialists by design.

    Ortoo ships proven agent patterns across service, revenue, and industry workflows. All fully configurable and customisable.

    Explore custom agents
    1. 01

      Enrichment

      Adds missing context. Looks up account history, pulls external data, populates structured fields on the record.

      See it in production
    2. 02

      Triage

      Reads incoming work and identifies what it is. Account, intent, urgency, language, attachments, eligibility.

      See it in production
    3. 03

      Classification

      Assigns category, type, priority, and tags. Turns unstructured content into structured fields the rest of the workflow can act on.

      See it in production
    4. 04

      Routing

      Sends work to the right queue, team, or owner. Considers workload, capacity, skills, language, and SLA risk.

      See it in production
    5. 05

      Resolution

      Drafts responses, updates records, completes the workflow step. Handles the work or hands off for human review.

      See it in production
    6. 06

      Supervisor

      Oversees workflow progression. Handles exceptions, escalates blockers, ensures each step completes within policy.

      See it in production
    7. 07

      Custom

      Configure your own agent for any operational task. No code. Same anatomy, same governance, same observability.

      Explore custom

    The lifecycle

    Configure, run, govern.

    Agents are built through configuration, executed by the orchestration engine, and operated with full visibility. The same lifecycle governs every agent your team ships.

    Step 1

    Build

    Configure the agent's anatomy. Role, context, tools, knowledge, structured output, boundaries, memory. No code. Operations teams build through the configuration layer.

    Step 2

    Execute

    The orchestration engine runs the agent. Coordinates handoffs. Manages context passing. Applies confidence thresholds. Logs every decision. Workflows compose from agents the same way agents compose from tools.

    Step 3

    Operate

    Monitor agent runs, decisions, and costs. Adjust thresholds. Add new versions. Roll back changes. Ortoo handles the operational concerns. The team focuses on the workflow.

    See the full execution model

    The numbers

    Built for production

    6+
    Specialist agent types
    100%
    Configurable, no code
    BYOM
    Any LLM, any vendor
    100%
    Salesforce native
    Customers

    Specialist agents in production

    120k+
    Records processed in 3 months

    Assent Compliance

    Assent runs 16 distinct use cases across 16 teams using specialist agents. One configuration model. One governance framework. Different agents handle compliance enrichment, supplier triage, and request classification. Sixteen teams. One system. In production: near-100% routing across 5 languages and 15 of 16 critical workflows at Assent Compliance.

    33.6k
    Hours reclaimed annually

    Cars.com

    Cars.com used to spend 60% of senior agent time on manual case triage. Specialist agents now handle triage and classification automatically. Senior agents focus on resolution. Annual capacity reclaimed: 33,600 hours.

    Customer story

    Common questions

    Questions teams ask about specialist agents.

    How is a specialist agent different from an Agentforce agent?

    +

    Agentforce agents are conversational and assistive: chat patterns, single-task help, copilot-style interaction with users. Specialist agents are operational: bounded role, structured output, observable decisions, composable into multi-step workflows that run in the background. The two patterns serve different jobs.

    See the full Agentforce comparison

    Are we locked in to your AI provider or model choices?

    +

    No. Each agent calls the LLM provider you choose, through your own API key, under your contract with the provider. Model selection is per-agent. Different agents can use different models. Switch providers without rebuilding workflows. The orchestration layer stays the same when your AI choices change.

    How do we recover when the AI makes a bad call?

    +

    You set the confidence threshold per agent. Below the threshold, the workflow does not act on the agent's output. It drafts for human review, asks for clarification, or escalates to the path you configured. Above the threshold, the agent acts and the decision is logged for audit. Bad calls are caught at the agent boundary, not after they have cascaded.

    Do we end up with too many agents to manage?

    +

    Most production workflows compose from three to six agents, plus a supervisor agent coordinating exceptions. Assent runs sixteen distinct use cases across sixteen teams using the same configuration model. Agents are managed at the system layer, not as individual integrations. Adding the seventh agent costs the same effort as adding the second.

    Where does our data actually go when agents run?

    +

    The agent itself runs natively on the Salesforce platform. It inherits Salesforce permissions, sharing rules, and field-level security. When the agent needs interpretation, the LLM provider you configured gets called through your own API key, under your contract with that provider. No external infrastructure to provision. No data movement outside the trust boundaries you control.

    How do we know a new agent will not break production?

    +

    Every agent is versioned. New versions can be tested in sandbox against real workflow data before production. Rollback is supported. Changes do not require code deploys. The same lifecycle governs every agent change you ship.

    Should we just build agents ourselves with Flow and Apex?

    +

    Some teams do. The trade-off is total cost of ownership, time to first agent in production, and the governance you have to build from scratch. The detailed comparison covers what your engineering team gets back when the lifecycle is configured rather than coded.

    See the DIY comparison

    Who in our team configures the agents?

    +

    Salesforce admins. Operations teams. Anyone who can configure a Flow or a routing rule. No Apex, no Java, no custom AI engineering required. The configuration layer is built for the people closest to the work.

    What stops an agent from hallucinating in production?

    +

    Three structural controls. Grounded retrieval: the agent draws from your knowledge sources (product docs, policy guides, FAQ libraries) rather than free-form generation. Structured output: every agent returns typed fields against a defined schema, validated before the next step acts on it. Confidence thresholds: below your configured threshold, the output does not flow downstream. Hallucinations are caught by the architecture, not the agent.

    Further reading

    Where to go next?

    Execution deep-dive

    How Ortoo Orchestrator executes work in Salesforce.

    The full system model. Execution architecture. Hybrid AI and deterministic logic. Native to Salesforce.

    Read the deep-dive

    Compare

    Ortoo versus building it yourself

    The case for buying instead of building. Total cost of ownership, time to first workflow, and what your engineering team gets back.

    See the DIY comparison

    Agentforce comparison

    Ortoo vs Agentforce: how they fit together.

    What each is built for. How they complement each other. When to use each pattern.

    Read the comparison

    Put agents to work.

    Start with one workflow. One agent. Validate it. Expand across service, revenue, and operations as you go.