From telling to doing
Software has spent thirty years getting better at telling you things. Reports, dashboards, alerts, and lately assistants that summarise beautifully and change nothing. The step that is now available is different in kind: software that acts.
That opportunity is the reason AI sits at pillar five rather than pillar one. An agent that can act is only useful if it can be trusted to act, and trust is assembled from the four pillars underneath it.
Talk to an expertWhat an agent needs
Where AI sits in the sequence
AI is pillar five because it is the only one that returns the investment made in the other four.
The difference between collation and activation
Almost everything sold as AI collates. Rather less activates. The difference is whether the state of a system changes without a person doing it.
Take a renewal at risk. A dashboard tells you the account has gone quiet and the score has dropped. An assistant tells you why, summarising the last four conversations and the open case. An agent books the call, drafts an offer inside the discount policy, checks the credit position, and puts it in front of the account manager to approve or change.
The first two produce information. The third produces a changed record. Both are useful, they are bought for different reasons, and it helps to know which you are buying.
The tools, and where each one runs
Salesforce is where the record lives. It is not automatically where the thinking has to happen, and since the Agentforce 360 announcements in late 2025 that has stopped being a philosophical point. Anthropic and OpenAI models now run inside the Salesforce trust boundary, and Model Builder lets you register your own. The question is no longer whether you can use the best model for a job, it is whether anyone has decided which job needs which model.
| Tool | Where it runs | What it is | Tells or does | Best fit |
|---|---|---|---|---|
| Agentforce | Salesforce | The agent platform. Agent Builder, multi-agent orchestration, human-in-the-loop controls. Einstein Copilot was folded into it. | Does | Work that lives in Salesforce, where the actions are Salesforce actions |
| Agent Builder | Salesforce | Where agents are defined: their topics, the actions they may take, and the boundaries around them. | Does | Teams building their own agents rather than buying a fixed one |
| Prompt Builder | Salesforce | Grounds generated text in live record data through retrieval, so output reflects the account rather than the average. | Tells | Any generation task where accuracy against the record matters |
| Einstein | Salesforce | The predictive layer: scoring, forecasting, recommendations, next best action. Older than the generative wave and still the right tool for ranking. | Tells | Prioritisation and forecasting, where a ranked list is the output |
| Data Cloud / Data 360 | Salesforce | Harmonises and resolves identity across sources, with zero-copy to the major warehouses. The grounding layer. | Neither, it enables both | Any agent that needs to see beyond one org |
| Tableau Einstein and Pulse | Salesforce | Surfaces metric changes in the flow of work, in Slack, email and Salesforce, rather than waiting to be opened. | Tells | Teams who need to notice something changed, not query it |
| Slack AI | Salesforce | Summarises channels and threads, and can surface Salesforce records into the conversation. Claude is now embedded here too. | Tells | Businesses already running on Slack |
| Anthropic Claude | Both | Available inside Agentforce 360 and the first model fully contained within the Salesforce trust boundary, with traffic held in the Salesforce VPC. Also usable directly. | Both | Regulated work, long documents, and anywhere the data cannot leave the boundary |
| OpenAI GPT | Both | GPT-5 runs in Agentforce 360, and Agentforce is reachable from inside ChatGPT for records, conversations and Tableau views. | Both | Teams already working in ChatGPT who want the record alongside it |
| Model Builder / BYO | Both | Register an external model, including Azure OpenAI, Google Gemini or Claude on Amazon Bedrock, with calls routed through the Einstein Trust Layer. | Enables both | Where you have an existing model relationship, or a model tuned to your domain |
| Agnostic and headless | External | An assistant outside Salesforce using Salesforce as the trusted source and action engine, through the Headless 360 pattern. | Does | Decisions spanning systems Salesforce does not own |
The tools in the “tells” column are mature and frequently the right purchase. The distinction matters at the point someone expects a change in a record and receives a recommendation instead.
Our position on which to use is unglamorous: the right tool is the one that fits the job, and that is rarely the same tool twice. Salesforce-native is the shortest path when the work, the data and the users are already in Salesforce. A frontier model earns its place when the reasoning is genuinely hard, the documents are long, or the domain is specialised. Being a Salesforce partner does not oblige us to pretend the answer is always inside Salesforce, and being interested in the wider AI landscape does not mean reaching for it when Flow would have done.
Augment is where the investment comes back
Augmentation sits on top of everything else, and it is the only layer that pays the others back. A secure, well-governed, connected estate is worth having on its own terms. It becomes worth considerably more when something intelligent can act across it.
This is also why augmentation cannot be bought first. An agent placed on top of weak foundations does not compensate for them, it inherits all three at once and acts on them at machine speed.
What it can do
Specific work, taken off specific desks, rather than another dashboard. A sample of what is already possible inside a Salesforce estate.
Sales
- Brief before every call. Last twelve months of activity, open cases, invoice position, what changed since you last spoke. Ready before the meeting, not requested after it.
- Quotes drafted inside policy. Pulls current pricing, applies the discount rules, flags anything needing approval.
- Silent pipeline chased. Deals with no activity for a set period followed up automatically, in your tone, with the context attached.
- CRM updated from the conversation. Notes, next steps and stage changes written from a call summary rather than typed at 6pm.
Service
- Case triaged and routed on arrival. Read, categorised, prioritised and sent to the right queue with a suggested resolution attached.
- Known answers resolved end to end. The recurring fifth of your tickets closed without a person, with an audit trail.
- Draft replies grounded in your knowledge base, not generic text, ready for an agent to check and send.
- Escalations raised with the detail already gathered. Environment, history, contract, previous cases, attached to the engineering issue.
Finance and operations
- Credit position surfaced before a commitment is made, not after the invoice bounces.
- Order exceptions caught at entry. Wrong pricing, missing terms, unusual quantity, flagged while it is still cheap to fix.
- Chasing sequenced by likelihood and relationship rather than by whoever is oldest on the report.
- Month-end anomalies explained, with the underlying records assembled rather than hunted.
Marketing
- Segments built from real behaviour across service, sales and finance, not just campaign engagement.
- Consent respected everywhere automatically, including the systems marketing does not own.
- Content variants produced against real segment data, then measured against pipeline rather than opens.
- Attribution assembled from the systems that hold the answer, rather than approximated in a spreadsheet.
What an agent needs
An agent needs five things in place. The model is one of them.
- Grounding it can trust. Unified, current, permissioned data. Without it the agent is fluent and unreliable, which is worse than useless because it is persuasive.
- Reach into the systems where work happens. Raising the order, updating the case, sending the document: those are the steps that finish the work, and each one needs a route into the system holding the record.
- A permission model that means what it says. An agent acts as someone. Every shortcut in your permissions becomes an action it can take.
- Guardrails. What it may do unattended, what needs a human, what it may never do, and what happens when it is unsure.
- An audit trail. Who asked, what it saw, what it did, when. “The agent did it” is not an answer to a regulator, a customer or a board.
An agent inherits your permission model.
The moment software acts on a person’s behalf, every permissions shortcut in your org becomes something it can do, at speed and without hesitating. The over-permissioned profile nobody got round to fixing stops being a tidiness issue and becomes an operational one. This is why Security is pillar one and AI is pillar five, and it is the single strongest argument for doing them in that order.
Where to build an agent
We are a Salesforce partner, and the right place to build an agent is not always inside Salesforce. Where each applies is set out below.
Agentforce is the natural choice when the work lives in Salesforce. Where the grounding is Salesforce data and the users are already there, the agent inherits the permission model, the sharing rules and the audit trail rather than having them rebuilt around it. That is a real architectural advantage and it is not easily replicated.
It is not automatically right when the decision spans systems Salesforce does not own, when you are deliberately avoiding a single-vendor dependency, or when a much cheaper model would do the job perfectly well. Those are all legitimate positions and none of them makes you a difficult client.
What makes the choice genuinely open is the Headless 360 pattern: the assistant does not have to live inside Salesforce. Salesforce can remain the trusted source of record and the engine that carries out the approved action, while the interface a person actually talks to sits somewhere else entirely. That decouples where the intelligence runs from where the trust is held, which is what makes an agnostic approach practical rather than a compromise.
Sometimes the right answer is not an agent at all. A well-built Flow costs a fraction of the price, runs deterministically and never needs explaining to a compliance officer. That applies more often than the current discussion suggests.
What decides whether it reaches production
Plenty of AI projects reach a working demonstration and stop there. The two factors that most often decide it are the same two pillars underneath. Both can be put right.
- It cannot see. Grounded in partial, duplicated or stale records, so it answers confidently and wrongly. People catch it being wrong twice and stop asking. That is Data, pillar two.
- It cannot act. Nothing is connected, so the best it can offer is a suggestion, and a suggestion engine is an extra step in someone’s day. It gets switched off within a quarter. That is Integration, pillar four.
An AI programme that fails for these reasons was never an AI problem. It was a foundations problem that only became visible when something tried to use them. Businesses that did the unglamorous work first tend to find the AI step surprisingly short.
It also means the honest sequencing question is not “which AI tool” but “what would an agent need to see and touch to do this job, and does that exist yet”.
How we approach AI
Start with a decision that is repeated, valuable and currently slow, rather than with a technology or a department-wide rollout.
Where we would tell you not to
Four situations where we would advise against AI work, at least for now. It is a short list and it is honestly meant.
None of these are permanent objections. They are sequencing, and in most cases the work to clear them is smaller than the AI programme it protects.
How to begin with AI
Three starting points, depending on where the estate is now.
From collation to activation
With the four pillars underneath in reasonable shape, this step is shorter than most people expect. Where they are not, knowing that before anyone signs anything is worth the hour it takes to find out.
Salesforce AI: frequently asked questions
A chatbot answers. An assistant summarises and recommends. An agent completes the task: it retrieves what it needs, decides within the boundaries you set, and changes the state of a system, leaving the judgement calls with a person. The practical distinction is whether the state of a system changed, or whether information was presented.
Both are viable. Agentforce is the natural fit where the grounding is Salesforce data and the actions are Salesforce actions, because it inherits your permission model, sharing rules and audit trail rather than reconstructing them. Where the decision spans systems Salesforce does not own, or you are deliberately avoiding single-vendor dependency, an agnostic approach can work well. The Headless 360 pattern means the assistant does not have to live inside Salesforce for Salesforce to remain the trusted source and the action engine.
In our experience almost never because of the model. They fail because the agent cannot see, being grounded on partial or unreliable data, or because it cannot act, having nothing integrated to reach. Both are foundations problems that only become visible when something tries to use them, which is why we treat data and integration as prerequisites rather than parallel workstreams.
It is as safe as your permission model, which is the point. An agent acts as someone, so any over-permissioned profile becomes a set of actions it can take. Before giving an agent the ability to act we would want to see permissions reviewed, guardrails defined for what it does unattended, and an audit trail recording what it saw and did.
One decision that is made repeatedly, matters commercially, and is currently slowed down by someone gathering information from several places. Build that properly, measure it against how it worked before, and widen only once it has been reliable long enough to be boring. Starting department-wide tends to spread effort thinly across processes that have not each been examined.
When the data has not been assessed, when nothing is integrated, when the process is undefined, or when a well-built Flow would do the same job deterministically for a fraction of the cost. None of those are permanent objections, they are sequencing, and clearing them is usually smaller work than the AI programme they protect.
Get in Touch
A structured look at the whole estate
Our health check, and the usual starting point when the honest answer is that nobody is quite sure what state the org is in. It covers all five pillars rather than AI alone, because an AI answer that ignores the four underneath it is guesswork.
- What you have: objects, automations, integrations and who owns them
- What has been superseded, duplicated or quietly abandoned
- Where the estate is exposed, and where the data will not support what you want to build
- A prioritised view of what to do first, with the reasoning attached
It ends in a document you can act on or hand to someone else. Fixed price, and the scope is agreed before it starts.