What this is

Each agent is a prompt — its instructions — paired with a model. When you run an agent against a Salesforce case, it reads the case, investigates as needed, and proposes exactly one action. Agents never act on their own: every proposal waits in the Review queue until a human approves or rejects it.

You can create an agent in minutes from the Agents screen, and dry-run its prompt against a real case before saving ("Test on a case") to see what it would propose.

How a run works

Every step below is recorded and visible in the run inspector — tool lookups, the model call, and the final decision, each with inputs, outputs, and timing.

1. You trigger a run from the Dashboard (agent + Salesforce case ID). The run appears instantly with status "queued".
2. A background worker picks the job off a queue and starts the agent.
3. The agent investigates: it can call read-only Salesforce tools to verify current data before deciding.
4. It produces one structured proposal (action + payload + confidence + rationale). The system injects the real record IDs — the model is never trusted to supply them.
5. The proposal lands in the Review queue. A new run on the same case supersedes any older pending proposal, so the queue holds at most one per case.
6. A human approves or rejects. On approval, the executor performs the Salesforce write and the action is marked applied.
7. Every transition — run start, proposal, approval, write, failure — is written to the append-only audit trail.

What agents can do

Four write operations (all human-approved before execution) and three read tools for mid-reasoning lookups:

• update_case — change Case fields (status, routing, ownership)
• close_case — close a Case with a reason
• add_comment — post a CaseComment
• update_contact — change fields on the case’s Contact record (e.g. a person’s Title)
• get_contact(contact_id) — read a contact’s current Name, Title, Email, Phone
• get_case(case_id) — re-fetch the case record
• query(soql) — any read-only SOQL query

Agents verify before they act

Because agents can look up live data, they reason about the current state of Salesforce rather than a stale snapshot. In practice: an agent asked to set a title that is already correct will check the contact first, see the request is already satisfied, and propose closing the case instead of a redundant write — and you can watch it do so, step by step, in the run inspector.

Built on Google ADK 2.1.0

Agents run on Google’s Agent Development Kit (ADK) 2.1.0. Each run is an ADK LlmAgent executing a tool-calling loop: the model may call the read tools while thinking, and ADK enforces a strict structured-output schema on the final answer only — combining tools with enforced output structure is an ADK 2.x capability.

Models are served by Azure OpenAI through ADK’s LiteLLM adapter; runs execute on a queue-driven worker, so the UI never blocks on a model call.

Safety model

Safety is structural — enforced in code, not by asking the model nicely:

• Write tools are physically absent from the model’s toolset. The agent receives only the three read tools, so no prompt injection or model error can mutate Salesforce mid-run.
• Writes happen on a separate path: the agent can only record a proposal; the actual Salesforce call is made by the approval executor after a human clicks Approve.
• Record IDs (case, contact) are injected by the system from known data — IDs produced by the model are discarded.
• Proposals that don’t meet the action contract are rewritten into an escalation that spells out the gap for the reviewer.
• Every decision and action is written to an append-only audit log that cannot be updated or deleted.