AI in Salesforce is an architecture problem before it is a model problem.

Readiness is a specification, not a feeling. We assess four things: whether records resolve to one customer, whether the fields the AI would reason over are actually populated, whether stage and process definitions match how you sell today, and whether someone owns each system feeding the data. Our readiness audit produces a written verdict on each, a prioritised list of what to fix first, and the pre-activation baseline the programme will later be measured against. If the answer is that you are not ready yet, that is the finding we deliver — with a remediation plan and a cost.

They are three different layers, not three competing products. Data 360 — which Salesforce renamed from Data Cloud in October 2025 — is the data foundation: it ingests and harmonises data from across your systems into unified profiles. Einstein is the embedded intelligence layer that scores, forecasts and generates content using that data. Agentforce 360 is the autonomous layer: agents that take action rather than only recommending it. Agentforce and Einstein both depend on the quality of what Data 360 gives them, which is why we design the data layer first. We cover the individual products in more depth on our Agentforce and Einstein pages.

The boundary is concrete. If the behaviour can be expressed through Salesforce's own configuration surface — agent topics, standard actions, instructions, prompt templates, scoring setup, flows — it is configuration: declarative, faster, and maintainable by an administrator. The moment the agent needs to do something that surface cannot express, it becomes custom development: Apex actions, Lightning Web Components, or an API integration to a system outside Salesforce. That crossing changes the engagement, because custom code needs a developer, automated test coverage and a release process. We name which side of the line a requirement falls on during scoping, not after the invoice.

Not always, and this is worth getting right before you buy anything. An agent whose job is contained entirely within Salesforce records — answering from knowledge articles, updating a case, qualifying against CRM fields — can often be grounded on your existing CRM data. Data 360 becomes necessary when the agent needs context that lives outside Salesforce: product usage, billing status, support history from another platform. The honest test is to write down what the agent must know to do its job, then check where that data currently lives. We do that mapping in the readiness audit so the licensing decision follows the architecture rather than leading it.

It depends almost entirely on the condition of the data, which is why we audit before quoting. A readiness audit typically runs two to four weeks. Where the foundation is already sound, a first configured capability with guardrails tested and an effect measure attached typically follows in four to eight weeks. Where the data layer needs remediation first, that phase typically takes four to ten weeks and has to happen before activation is worth starting. These are typical ranges for a mid-market to enterprise org, and we confirm them in scoping against your actual environment rather than quoting them blind.

That is where a large share of our AI engagements start. Capability can be live and still be commercially inert, and the cause is usually one of a small set: the agent is grounded on data nobody trusts, the scoring is calibrated against stage definitions that no longer describe the sale, or no baseline was captured so nobody can tell whether anything moved. We diagnose which of those is true, fix the layer underneath, and re-activate in sequence — usually without starting the org over. This sits inside our wider Salesforce consulting practice.