The use case was chosen for its demo value
Impressive in a boardroom, rare in the queue. A first agent should take the dullest high-volume job you have, because that is where the payback and the training data live.
Salesforce · Agentforce Implementation
One agent, in production, doing a job you can measure.
An Agentforce implementation is the work of taking one clearly defined job, building an agent that does it inside your Salesforce org, and putting that agent in front of real traffic under controls your security team has approved. Twopir Consulting runs that whole path — use case, grounding, topics and actions, testing, governance and launch. Scoped to one agent, finished, then repeated.
12+
250+
500+
15+
Trusted by 500+ organizations — including teams who brought us in after a first AI project stalled, and teams starting from a blank Agent Builder.
Implementation Scope
- Salesforce Partner
- Agentforce for Service
- Agentforce for Sales
- Employee Agents
- Data Library Setup
- Flow & Apex Actions
- Messaging & Web Channels
- Sandbox to Production
Six ways a first agent runs out of runway
These are the specific failure modes we are called in to fix, and every one of them is a decision made — or avoided — in the first three weeks. An implementation is mostly a sequencing problem.
Nobody wrote down what success looks like
Without a containment or accuracy target agreed before the build, the launch review becomes a debate about vibes, and the second agent never gets funded.
Grounding was treated as a later phase
Teams build topics and actions first, then discover the content the agent must quote is stale or missing. The build stalls waiting on knowledge work nobody scheduled.
Security saw the agent for the first time at UAT
The permission model, data boundaries and Trust Layer settings then get designed under launch pressure — which is how a two-week slip becomes a quarter.
Testing meant one person trying a few questions
An agent does not answer identically twice. Ad-hoc testing cannot tell you whether a change improved it, so every release becomes a leap of faith.
It launched to everyone at once
A big-bang cutover removes your ability to learn cheaply. Staged exposure — one queue, one region, one channel — turns a potential incident into a tuning cycle.
What It Involves
What an Agentforce implementation actually covers
An Agentforce implementation is five pieces of work, not one. You define the job and how you will know it is being done well; you make the knowledge and data behind it retrievable; you build the agent — topics that classify intent, instructions that bound behaviour, and actions that do the work; you configure the controls, meaning the agent user's permissions, Trust Layer settings and escalation rules; and you release it through a sandbox and a staged rollout rather than straight into the queue. Skip any one and the others get more expensive.
Keep the roles distinct. Salesforce provides Agent Builder, the Atlas reasoning engine that classifies intent and plans, the action framework, the data library and retrieval, the Einstein Trust Layer, and the Testing Center. Twopir Consulting provides the architecture and the labour: which topics exist and where their boundaries sit, what each action does and what it must never do, how the content gets indexed, how the thing is tested, and how it gets from a sandbox into production without surprises. You get one agent doing a named job, with a number attached to how well it does it.
Scope discipline is the whole game. We implement one agent per engagement. A second topic area is a second increment with its own test set, not a bigger version of the first. Teams that try to launch a general-purpose agent covering eight areas at once produce an agent that is mediocre at all eight — and impossible to debug. We work with growing, mid-market, and enterprise organizations that need help with complex CRM implementations, integrations, and business system challenges, and this sequencing is what makes the complex ones finish.
This is the implement offer — and the two next to it
If you already have an agent, an implementation is probably not what you need. Read across before you scope: the wrong one of these three costs weeks.
Implement — this page
You have no production agent. We take one job from definition to launch, including the grounding and governance underneath it.
- Right when: nothing is live yet
- Typical length: 9–16 weeks
- Output: one governed agent, measured
- Includes grounding and release engineering
- Ends with hypercare and a named owner
Configure
An agent exists and misbehaves. Declarative work only — topics, instructions, actions and channels — usually measured in weeks, not months.
- Right when: it is live but wrong
- No new code, no new licences
- Fastest path to a behaviour change
- Often follows a short diagnostic
- Customization & configuration →
Build on
The action you need does not exist. Engineering work — Apex, complex Flows, external APIs and MCP-exposed tools, multi-agent patterns.
- Right when: configuration cannot reach it
- Runs alongside an implementation or after
- Needs a developer sandbox and code review
- Deployed as metadata, not clicks
- AI agent development →
Everything between the decision and the first real conversation
Six workstreams run inside a single implementation. They are sequenced, not parallel — each one produces the input the next one needs.
Discovery & Use Case Definition
We turn “we want an AI agent” into a specification: which requests it handles, which it refuses, what it is allowed to do, and the number that says it worked.
- Request-volume and intent analysis
- In-scope and explicitly out-of-scope intents
- Containment and accuracy targets
- Escalation and human-handoff rules
- Consumption estimate for the business case
Agent & Topic Architecture
The structural decision that determines everything afterwards: how many topics, where their boundaries sit, and how the agent tells them apart under real phrasing.
- Topic decomposition and boundary design
- Classification descriptions and scope statements
- Natural-language instructions and guardrails
- Example utterances from real transcripts
- Overlap testing between adjacent topics
Action Build & Integration
The part that makes it an agent rather than a search box. Standard actions where they fit, Flow where logic is declarative, Apex and APIs where it is not.
- Standard action wiring and input mapping
- Flow-based actions for record and process work
- Apex and API actions for external systems
- Prompt templates for generated content
- Error handling and graceful failure paths
Knowledge Grounding & Data Setup
Making the content answerable: a data library over the right sources, indexed and retrievable, with the article gaps found before launch rather than by a customer.
- Data library creation and source selection
- Knowledge article audit and remediation
- Data Cloud ingestion where profiles need resolving
- Retriever configuration and grounding tests
- Data & knowledge integration →
Controls & Sign-Off
Run in parallel with the build, not after it. The agent user, its permissions, Trust Layer configuration and the audit evidence your risk owner needs to approve a launch.
- Agent user and least-privilege permission sets
- Object, field and sharing boundary review
- Einstein Trust Layer configuration
- Human-in-the-loop rules on irreversible actions
- Governance & security →
Testing, Rollout & Hypercare
A written test set before the build, batch evaluation during it, a staged launch with a rollback path, and two to four weeks of hypercare while real traffic finds the edges.
- Test set built from real historical requests
- Batch evaluation of topic and action selection
- Guardrail and refusal testing
- Staged exposure by queue, region or channel
- Testing & deployment →
The systems a first agent usually has to touch
Almost no agent lives on Salesforce data alone. These are the connections that come up in implementation after implementation, and what moves across each one.
Messaging channels
Web messaging, in-app chat or WhatsApp carry the conversation in; the session, transcript and outcome flow back to the Case or Lead, so the agent's work is visible to the human who picks it up next.
Salesforce Knowledge
Published articles and their attachments are indexed into a data library. Retrieval reads from it one way; nothing writes back, but the questions the agent could not answer become your article backlog.
Experience Cloud
Where the agent serves logged-in customers or partners on a portal, identity context comes from the site and the agent's record access is scoped to that user — the highest-risk permission boundary in most builds.
ERP & billing systems
Order status, invoices and entitlements usually live outside Salesforce. An API-backed action reads them live at conversation time, which beats a nightly sync that is wrong by the time anyone asks.
Marketing automation
Where Account Engagement, Marketo or HubSpot owns demand, the agent reads engagement and scoring as qualifying context and writes its qualification outcome back, so attribution and nurture logic still hold.
Document repositories
Policies, manuals and contracts in SharePoint, Drive or a DMS are ingested and indexed so the agent can cite them. Access rules on the source have to be mirrored, not assumed.
Case routing & queues
Escalation is an integration, not a fallback message. The agent hands the conversation to the right queue with its transcript, its confidence and what it already tried, so the human does not start over.
Reporting & observability
Session outcomes, topic distribution, escalation and latency feed dashboards from day one, so the launch review reads numbers rather than anecdotes — and the tuning backlog writes itself.
Five phases, and what each one needs from you
Timelines assume a reasonably healthy org and one use case. The client-side column is the honest part — implementations slip on availability far more often than on build complexity.
Discover
Request analysis, scope boundaries, success criteria and a consumption estimate — enough to stop the build before it starts if the numbers do not work.
Ground
Data library, retriever and any Data Cloud ingestion, plus the article remediation the retrieval tests prove is needed. Usually the longest phase on an older org.
Build
Topics, instructions, actions and the automation behind them, in a sandbox, evaluated against the test set at the end of every iteration.
Harden
Permissions, Trust Layer, guardrail and refusal testing, audit evidence, and the sign-off session with whoever owns risk.
Launch & Hypercare
Staged exposure with daily review, fast tuning cycles while real traffic finds the edges, then handover to a named owner or to managed services.
| Phase | What Twopir delivers | What we need from you |
|---|---|---|
| Discover | Scope document, in and out-of-scope intents, success metrics, consumption estimate. | Access to request history or transcripts, and the process owner for two workshops. |
| Ground | Data library, retriever configuration, retrieval test results, article gap list. | A content owner who can approve article edits, and a decision on what is in scope to fix. |
| Build | Topics, instructions, actions, automation and prompt templates in a sandbox. | A sandbox that mirrors production, and subject-matter review of agent responses. |
| Harden | Agent user and permission design, Trust Layer configuration, guardrail test evidence. | The security or risk owner, early enough to raise objections before launch week. |
| Launch | Staged rollout plan, rollback path, live dashboards, daily tuning during hypercare. | An operations contact during hypercare, and agreement on the exposure schedule. |
Implementations we have taken to launch
Agent implementations rest on conventional delivery discipline: scope, integration, testing and a real launch. These are Twopir engagements where that discipline is the story.
★★★★★
Twopir helped us identify the right AI tools and select the best-fit platform for our needs. Their team provided end-to-end support — from consulting to implementation — delivering an AI-powered chatbot and automation system that improved our lead routing and customer engagement.
Mathias Bensimon Director · AI platform selection & chatbot implementation AI Implementation
Professional Services Firm — AI Document Automation
Automating email attachment processing and Salesforce data routing.
40% Reduction in manual document processing time
2× Admin throughput without added headcount
100% Automated classification & CRM routing
★★★★★
Working with Twopir Consulting was a game-changer for our organization. They designed and implemented a comprehensive Service Cloud + Experience Cloud solution that perfectly aligned with our customer support and partner portal needs. Their proactive approach, attention to detail, and post-go-live support have been outstanding.
Andrew Stewart Consultant · Service Cloud & Experience Cloud implementation Service Cloud
Professional Events Organization — CRM Integration
Salesforce–MeetMax integration for a corporate networking organization.
100% Elimination of manual data sync between platforms
360° Unified client view across events & CRM
0 Manual reconciliation tasks post-integration
We implement one agent properly
A first Agentforce implementation is a credibility exercise as much as a technical one. It has to work, it has to be defensible, and it has to make the second one easier to fund.
Scope is a deliverable, not a conversation
Every implementation starts with a written list of what the agent handles and what it explicitly refuses. That list is what makes testing possible and stops the build drifting for a quarter.
Grounding is scheduled first, not discovered late
We test retrieval before topics are built. If the content cannot answer the questions, we would rather know in week three than in user acceptance testing.
The security conversation happens in week one
Permissions, data boundaries and Trust Layer settings are designed alongside the build. Risk owners are in the room early, which is the cheapest way to protect a launch date.
We build the actions, not just the agent
Our Salesforce practice writes the Flows, Apex and integrations the agent triggers, so “the agent can do it” and “the system can do it” are settled in the same engagement.
Launch is staged, and reversible
First traffic is a slice, not the queue. There is a rollback path, live dashboards and daily review during hypercare — so a surprise is a tuning cycle rather than an incident.
Implementation questions we get asked first
Pick the highest-volume request your team already answers the same way every time, where the answer is documented and the follow-up action is a known Salesforce operation. Order and account status, password and access requests, appointment changes, policy questions and inbound qualification all fit that shape. Avoid anything where the answer depends on judgement, where the process is undocumented, or where being wrong has legal or financial consequences — those are candidates for a later increment with human approval built in.
Partly, and only the parts the agent touches. You do not need a perfect org — you need the objects, fields and knowledge in scope for this one use case to be accurate and consistently populated. Where an agent has to read a field that half the records leave blank, or trigger a Flow that nobody trusts, that is remediation work we scope explicitly rather than absorbing invisibly. The readiness assessment exists to draw that line before a build starts.
Less than a platform migration, more than a configuration change. Expect a process owner for two workshops in discovery, a content owner who can approve article edits during grounding, subject-matter reviewers to sanity-check agent responses during the build, a security or risk owner for one sign-off session, and an operations contact during hypercare. The single biggest cause of slippage we see is not build complexity — it is a content owner who cannot get to article edits for three weeks.
Yes, and we do — building against production is not something we would recommend for an agent that can write records. Two caveats worth planning for: the sandbox needs to resemble production in data shape and permissions or your test results will not transfer, and agent testing consumes the same AI capacity that production use does, so sandbox evaluation is a real line in the consumption budget rather than a free activity.
Two to four weeks of hypercare, where we review sessions daily and tune topics, instructions and grounding while real traffic finds the edge cases the test set missed. After that the agent needs an owner, because agents drift as products, prices and articles change. Some clients take that in-house with our enablement; others move onto managed services, where we hold monitoring, releases, knowledge upkeep and a quarterly review. Either way, the handover is a decision we make deliberately rather than a document we email.
Usually, and usually without starting over. Most stalled agents we inspect have the same three problems: topics that overlap so intent classification is unstable, grounding that returns the wrong passage, and no test set to tell whether a change helped. Those are configuration and content problems, not platform problems. We start with a short diagnostic, and if the fix is declarative we scope it as a configuration engagement rather than selling you an implementation you do not need.
Next Step
Tell us the job. We will tell you the scope, the sequence and the weeks
Bring one process you want an agent to own. We will walk through the intents it would cover, the content it would need, the actions it would run, and what would have to be true before it sees a customer — then put a phase plan against it.
Salesforce, CRM & AI delivery for growing and mid-market companies · Contact the team
