Get in Touch
About Us Insights Newsroom Gallery Why AtomicNorth Get in Touch

Agentforce
and Salesforce AI

An agent is only as good as the data it is grounded in and the permissions it inherits. Most of the work in a serious Agentforce engagement happens before anyone writes a topic or an action, and most disappointing pilots skipped it.

Data readiness, then grounding, then permissions, then behaviour. In that order.

FirstData readiness

An agent grounded in inconsistent data is confidently wrong at scale.

ThenPermissions

An agent inherits access. Permission debt becomes a disclosure problem.

Proven byTesting

Behaviour tested against real cases, including the ones it should refuse.

Measured byCost per action

Consumption understood at pilot scale before anything is rolled out.

What we do

The work that happens before the agent

Agentforce is straightforward to demonstrate and hard to deploy responsibly. The gap between those two is almost entirely data and access.

Data readiness

The grounding data assessed honestly: duplicates, stale records, fields that three teams fill in differently, and knowledge articles contradicting each other.

This is where most of the effort goes and where most pilots did not. An agent grounded in inconsistent data does not fail loudly; it answers confidently and wrongly.

A grounding set you would stand behind.

Grounding and retrieval

What the agent can see, from which objects and knowledge sources, with retrieval scoped so answers come from the records that should inform them.

Over-broad grounding is the usual cause of an agent being technically right and practically useless.

Answers traceable to a source.

Permissions and disclosure

The agent's access modelled deliberately, tested against roles, and reviewed as a security change rather than as a configuration detail.

An agent inherits the permission model it runs under. Years of accumulated access debt becomes visible the moment it starts answering questions.

An agent that cannot say what it should not.

Topics, actions and handoff

What the agent handles, what it does, and the point at which it stops and hands to a person, with that boundary chosen deliberately rather than discovered.

The handoff is a design decision. An agent that will not let go is worse than no agent.

A boundary everyone agreed on.

Testing behaviour

Tested against real cases, including the ones it should decline, the ambiguous ones and the ones where the right answer is to escalate.

Testing only the happy path tells you what the demo does, not what the deployment will do.

Behaviour you have evidence for.

Consumption and cost

Usage measured at pilot scale and projected before rollout, so the economics are understood while the decision is still reversible.

Consumption-based pricing rewards measuring first. A pilot that nobody costed is a rollout nobody can budget.

A number you can take to finance.

From pilot to something you can defend

StageOneQualify

Which decisions or interactions are worth automating, and is the data to support them good enough today. Both answers are needed before anything is built.

Where the honest answer is no, we say so. A pilot built on data that is not ready produces a convincing demo and an unusable deployment.

You receive:

A go or no-go, with reasons

The use cases ranked by value and by data readiness, and a plain statement of which are viable now and which need work first.

This is yours whether or not the engagement continues.

StageTwoPrepare

The grounding data cleaned, deduplicated and made consistent. Knowledge sources reconciled. The permission model reviewed as a security change rather than a setting.

This is the unglamorous majority of the work, and skipping it is the single most reliable way to produce a disappointing agent.

You receive:

A grounding set and an access model

The data the agent will use, in a state you would defend, and a documented access position tested against each role.

Both are useful on their own, agent or no agent.

StageThreeBuild and test

Topics, actions and the handoff boundary built, then tested against real cases: the ones it should answer, the ones it should refuse, and the ambiguous middle.

An agent is tested on what it declines as carefully as on what it answers.

You receive:

A test record, including the refusals

Case-by-case results with the expected and actual behaviour, and the consumption each case generated.

Rollout is a decision made on this evidence.

StageFourRun and watch

In production with conversations sampled and reviewed, consumption tracked against forecast, and behaviour re-tested after every change to data, permissions or prompt.

An agent is not a deployment, it is an ongoing position. Its inputs change underneath it.

You receive:

A monthly agent review

Volumes, handoff rate, sampled quality, consumption against forecast, and any behaviour that changed without anyone intending it.

Reported whether or not it was a good month.

01
Readiness

What has to be true before an agent is useful

Assessed in stage one. Where something is not ready, the honest options are fix it first or pick a different use case.

Agentforce and Salesforce AI: readiness, condition, why it matters, how we check it, if it is not true
ConditionWhy it mattersHow we check itIf it is not true
Consistent dataThe agent answers from records, so inconsistency becomes confident errorField-level profiling across the grounding objectsClean first, or narrow the use case
Reconciled knowledgeContradictory articles produce contradictory answersReview of the knowledge base for conflicts and stalenessReconcile before grounding
Defensible permissionsThe agent inherits access and will surface what it can seeAccess tested per role against sample recordsFix the access model first
A real decisionAutomation needs something worth automatingVolume and value of the interaction, measuredPick a different use case
An agreed handoffAn agent that will not escalate is worse than noneThe boundary defined and signed off with the service ownerDefine it before building
Measured consumptionRollout economics have to be known while reversibleUsage captured during the pilot and projectedDo not scale until it is
Position

Useful where it is useful, and we will say where it is not

We will not tell you that an agent will transform your service desk. What we will do is tell you, before you spend anything meaningful, whether your data can support the use case you have in mind.

Sometimes the answer is that the data work is worth doing on its own merits and the agent is a later question. That is a real outcome, and it is cheaper to reach in stage one than in month six.

Talk to an expert
  • No outcome promisedWe do not quote deflection rates or savings. Yours will depend on your data, your cases and your handoff boundary.
  • Data work counted honestlyThe preparation is most of the effort and is scoped as such, not hidden inside a build estimate.
  • Reversible by designPilot scale, measured consumption and a defined boundary, so stopping is a decision rather than a write-off.

Scope and targets are set after discovery, against the org as it stands.

Questions we get asked

Before you send an RFP

Do we need Data Cloud to use Agentforce?

It depends on where the grounding data lives and how much of it sits outside Salesforce. If everything relevant is already in the org and consistent, you may not. If the answer spans several systems, something has to unify it first. We will tell you which case you are in during stage one rather than assuming the larger one.

How long before we see something working?

A demonstrable agent is quick. A deployable one depends almost entirely on the state of your data and permissions, which is why stage one exists. We would rather give you a real date in week two than an optimistic one in week zero.

What does it cost to run?

Consumption-based, which is exactly why we measure it at pilot scale and project it before any rollout. Anyone who quotes you a running cost before seeing your case mix is guessing.

Is our data safe in an agent?

The agent operates within the permission model it runs under, which is the reason that model gets reviewed as a security change here rather than treated as configuration. The uncomfortable part is usually not the AI; it is the access debt the AI makes visible.

Ask the hardquestion first.

Not whether an agent can do it. Whether your data can support it. We will answer that one before you commit to anything.

Get in touch +91-120-4849200