Guide

Managing AI Agents in Salesforce: A Live Oversight Framework

Setting an agent's permissions decides what it is allowed to touch. Live oversight is a different job: watching what it actually does once it's running.

Quick Answer

Salesforce's live oversight of AI agents in Agentforce is a dedicated product called Agentforce Observability, separate from the permission sets that decide what an agent can access. It traces every session, lets you drill into individual conversations and subagents, clusters conversations by shared intent so you can see what people are actually asking for, scores each interaction for relevance and helpfulness, tracks the credits each agent consumes, and raises near-real-time alerts on metrics like escalation time and latency so an admin can step in. None of that replaces a human: Agentforce still needs a person to accept what an agent proposes before anything is treated as done, and observability is how that person knows where to look first.

Permissions decide access; oversight decides what you actually saw

Managing an Agentforce agent's permissions, who can build it, who can talk to it, and what its own user record can read or write, is a one-time setup decision enforced by Salesforce's standard sharing rules and profiles. It answers 'what is this agent allowed to do.'

Live oversight answers a different question: 'what is this agent actually doing, right now and over time.' An agent can be permissioned perfectly and still misread an intent, loop on a bad tool call, cost more in model credits than it's worth, or hand off to a human too late. Permissions are the fence. Oversight is watching what happens inside it.

  • Permissions: a configuration decision, set once and reviewed occasionally.
  • Oversight: an ongoing activity, watching live and historical agent behavior.
  • An agent can be correctly permissioned and still behave badly inside that boundary.

Agentforce Observability: what it actually shows you

Agentforce Observability is Salesforce's name for the tooling that watches agents after they're live. It lets you investigate every Agentforce session in detail, drilling into specific subagents and segmenting conversations by intent and sentiment, and it provides session-level tracing across every user interaction so you can see where an agent stalled or an action underperformed.

An intent-clustering view groups conversations that share a similar underlying ask, which is how a team notices a pattern (a feature everyone is confused about, a question the agent keeps mishandling) instead of reading transcripts one at a time. A Quality Score is attached to interactions to measure relevance and helpfulness per exchange, and a usage view tracks the model credits each agent consumes so cost doesn't surprise anyone.

  • Session tracing: drill into any session, down to individual subagents and actions.
  • Intent clustering: groups conversations by shared intent, to spot patterns instead of one transcript at a time.
  • Quality Scores: a relevance and helpfulness measure attached to each interaction.
  • Credit usage: tracks what each agent costs, per agent, over time.

Alerts turn oversight into something you act on

A dashboard someone checks once a week is monitoring in name only. Agentforce Observability includes near-real-time alerts on key metrics, configurable for things like escalation time and response latency, so an admin can make a targeted change to an agent's configuration while the problem is still live rather than finding it in a retrospective.

This is the piece that makes 'live' in live oversight mean something. Session tracing and intent clustering are mostly useful after the fact, for understanding a pattern. Alerts are what let a team catch a single agent degrading today, before it generates a week of bad interactions.

  • Alerts fire near-real-time on configured metrics, not on a scheduled report.
  • Escalation time and latency are two of the metrics you can alert on.
  • The point is to intervene while the agent is still misbehaving, not after.

What observability does not replace

A dashboard, however good, still needs a person deciding what to do with what it shows. Salesforce's Agentforce Testing Center is the separate, earlier-stage tool for defining test scenarios and checking an agent's responses before it goes live at all; observability picks up once it's live and talking to real people. Treat the two as different stages of the same job, not competing tools.

And no monitoring dashboard substitutes for the basic design decision underneath Agentforce: every action an agent can take, updating a record, sending an email, triggering a Flow, has to be explicitly added to its configuration first. Observability tells you how an agent used the actions you gave it. It will not tell you to take an action away that you never should have granted; that's still a configuration review, not a monitoring one.

  • Testing Center is pre-launch validation; Observability is post-launch monitoring.
  • An agent's available actions are still a configuration decision, made before any session happens.
  • Monitoring shows behavior inside the permissions you set; it doesn't correct the permissions themselves.

Building the oversight workflow

A live oversight setup for Agentforce has a natural order: decide what you'd be alerted about before you need the alert, not after an incident teaches you the hard way.

Start narrow and widen as you trust the signal. An alert threshold that fires constantly gets ignored within a week; one that never fires is not actually watching anything.

  • Turn on session tracing for every production agent before it talks to real users, not after.
  • Set alert thresholds on escalation time and latency that reflect what 'too slow' or 'too stuck' actually means for that agent's job.
  • Review the intent-clustering view on a schedule, looking for a pattern of confusion rather than a single bad session.
  • Track credit usage per agent so a cost spike is visible before the bill is.
  • Keep a named human responsible for acting on each alert category; an alert no one owns is noise.

Where this stops being Salesforce's problem, and where Forkbench fits

Agentforce Observability watches agents that run inside Salesforce, talking to Salesforce users through Salesforce's own infrastructure. It has nothing to do with the coding agents your developers run locally to write the Apex, Lightning Web Components, or Salesforce CLI scripts that build and maintain an Agentforce deployment in the first place. Those are two different agents doing two different jobs, and Salesforce's live oversight tools only ever see the first one.

Forkbench is a desktop app for macOS that runs that second kind of agent, local coding agents, in a terminal on your Mac. It has no connection to Salesforce and cannot watch, trace, or score what an Agentforce agent does inside your org; that visibility only exists inside Salesforce's own product. What Forkbench does is narrower and local: its Vault can hold a Salesforce connected-app secret or CLI token in your Keychain so a local coding agent authenticates to your org by name instead of reading the credential from a project file, and a Thread can be locked to its folders with the macOS kernel sandbox. The lock bounds the filesystem only, not the network, so a locked agent can still reach Salesforce's API if the command it's running is allowed to.

  • Agentforce Observability sees agents running inside Salesforce; it has no visibility into your local coding agents.
  • Forkbench runs local coding agents on your Mac; it has no visibility into Agentforce, and makes no claim to.
  • Forkbench's Vault protects the deployment credential a local agent uses, not anything about how Agentforce behaves.

Related: How to manage AI agent permissions in Salesforce, Give an agent deploy access without the credential, How Forkbench handles your local secrets, Download Forkbench for Mac

Frequently asked

  • What's the difference between Agentforce permissions and Agentforce Observability?

    Permissions are a one-time configuration deciding what an agent is allowed to access. Observability is ongoing monitoring of what the agent actually does once it's live: session tracing, intent clustering, quality scores, and alerts.

  • Can Salesforce alert me when an Agentforce agent is struggling?

    Yes. Agentforce Observability supports near-real-time alerts on metrics such as escalation time and latency, so an admin can intervene while a problem is current rather than finding it later in a report.

  • Does Agentforce Observability replace testing an agent before launch?

    No. Agentforce Testing Center is the pre-launch tool for defining scenarios and checking responses. Observability monitors agents that are already live and talking to real users; the two cover different stages.

  • Can Forkbench monitor my company's Agentforce agents?

    No. Forkbench runs local coding agents on a developer's Mac and has no connection to Salesforce or to Agentforce. A Salesforce deployment token can still live in its Vault, so a local agent uses the token by name without the raw value ever reaching its prompt.

  • Does watching session traces tell me whether an agent's actions were too broad?

    No. That's a permissions and configuration question, decided before the agent runs, not something a monitoring dashboard corrects after the fact.

Keep reading