An agent is not a chatbot
A classic chatbot follows a decision tree someone drew in advance: if the customer says A, reply B. An agent works differently. You give it a goal and a set of permitted actions, and it decides at run time which steps to take: which records to look up, which knowledge to quote, which flow to call, when to hand off to a human. That autonomy is what makes agents useful for work that decision trees could never cover. It is also what makes them worth supervising: two identical questions can take two different paths through your org.
What a Salesforce agent is made of
An Agentforce agent is assembled from a small number of parts, all of which live in your org as configuration:
- Topics: the jobs the agent is allowed to work on, each with its own instructions and boundaries.
- Instructions: natural-language rules for how the agent should behave inside a topic.
- Actions: the things the agent can actually do. Actions are backed by Salesforce flows, Apex, prompt templates, or API calls.
- Knowledge and data: the records, articles and retrieved context the agent grounds its answers in.
- Guardrails and channel settings: where the agent runs, as which user, and what it must refuse.
The model does the reasoning, but everything that touches your data goes through these parts. That is good news for governance: it means an agent's permitted behaviour is inspectable, because it is written down in metadata rather than hidden in model weights.
The part most teams miss: the org underneath
An agent's real behaviour is the product of its own configuration and everything it stands on. The agent runs as a user, so profiles and permission sets decide what it can read and write. Its actions call flows and Apex that other teams maintain. Its answers quote knowledge articles that editors update. Change any of those, and you have changed the agent, even though nobody opened the agent builder. This is why reviewing the agent's prompt is never enough to say what the agent will do.
Where agents show up on Salesforce
In practice, Salesforce agents cluster around a few kinds of work:
- Service: answering customer questions, deflecting and triaging cases, drafting replies for a human to send.
- Sales: qualifying and following up inbound leads, preparing reps before calls, keeping records current.
- Internal help: answering employee questions from policy and knowledge, raising requests in the right systems.
- Operations: multi-step jobs that cross objects, like assembling renewal or quote information from several records.
Choosing which of these to hand to an agent first, and which rules keep the automation accountable, is a topic of its own: see getting the most from Salesforce with agents.
The question to ask before you switch one on
Not "is the model smart enough", but "can we write down what this agent may and may not do, and would we know if it stopped complying?" If the answer is yes, you have an agent you can operate. If the answer is no, you have a demo. Huscribe's job is turning the first answer into a signed approval and a schedule of checks, so the agent you run stays the agent you approved.