Anyone can demo an agent. Production is the hard part.

It depends on what the agent has to know. An agent that only reads standard CRM records and runs Salesforce actions can work without it. The moment you want the agent to answer from knowledge articles, documents or other unstructured content, that content has to be indexed and retrievable — and in current Agentforce that indexing and retrieval runs on the Salesforce data platform. Treat it as a cost line in the business case from the start, not a surprise discovered during build.

On a healthy org with a clearly defined use case, a first agent typically runs nine to sixteen weeks from assessment to a governed production launch. The variable is almost never the agent build — it is the state of the knowledge and data underneath it. Orgs that need article remediation or profile resolution first should expect the grounding stage to be the longest one, and we size that honestly at the assessment rather than discovering it in week six.

Agentforce agents operate inside Salesforce's existing security model — object permissions, field-level security and record sharing all still apply to whatever user the agent runs as. The real risk is not the platform ignoring those rules; it is an agent user being given a broad permission set for convenience during a pilot and nobody narrowing it before launch. That is why we design the agent user and its least-privilege access as a deliverable, and re-verify it as part of the release check.

Salesforce has offered Agentforce on more than one commercial model — including per-conversation pricing and consumption-based credits, alongside user licensing — and the published rates change, so confirm current pricing with Salesforce directly. What matters architecturally is that the design drives the bill: how many actions a conversation triggers, how chatty the agent is, and how much data the grounding layer holds. We model expected consumption during the assessment and design agents to be economical, and we test with consumption in mind because evaluation runs consume budget too.

Only if you need it to act. A scripted bot follows a decision tree you maintain by hand and hands off when the tree runs out. An Agentforce agent reasons about intent, retrieves grounded content, and executes real Salesforce actions under your permission model, with the conversation and its outcome recorded against the record. If your bot's main failure mode is “it answered, then a human still had to do the work”, that gap is the case for moving. If it is answering well and no action is needed, keep it.

Twopir Consulting is a Salesforce Partner and a HubSpot Partner, founded in 2014, with 40+ consultants and 500+ clients across the US, Canada, UK, UAE, Australia and New Zealand. We implement and support Agentforce; you licence it from Salesforce. Keeping those separate matters, because it means our advice about whether you need it is not a commission conversation.

You design for it rather than hope against it. That means grounding answers in approved content instead of open-ended generation, scoping topics so the agent declines what it was not built for, requiring human approval on irreversible actions, and setting escalation triggers on low confidence and on explicit customer frustration. It also means keeping the audit trail so an incident can be reconstructed exactly, and shipping behind a staged rollout with a rollback path so a bad release affects a slice of traffic rather than all of it.