Twopir Consulting implements Salesforce Agentforce 360, configures the agents your sales, service and operations teams actually use, and builds the custom Apex, Flow and API actions the standard library does not cover. Every agent is grounded in your own CRM records, bounded by your permission model, and tested before it reaches a customer. Three services, and we tell you which one you need.
Twopir Consulting is a Salesforce Partner and HubSpot Partner, delivering CRM and revenue infrastructure for 500+ organizations — now including the agent layer that runs on top of it.
The Salesforce AI Stack We Work In
The pressure to deploy AI agents is real, and so is the gap between a demo and a working agent. Almost every stalled programme fails on the same six things — and none of them are the model.
Qualification, follow-up drafting and research eat the hours that should go to conversations. Reps who actively use AI agents in their sales workflow report saving meaningful time each week, and research time per prospect drops by roughly a third once AI takes on the groundwork.
Source: Salesforce State of Sales, 2026Routine tiers absorb the queue while complex cases wait. Adoption has already crossed the majority line: 66% of customer service organizations now use AI agents, up from 39% the year before — so the routine tier is where competitors are pulling ahead.
Source: Salesforce State of Service — AI Agents EditionConfiguration upkeep, permission archaeology and duplicate cleanup consume the hours that should go to platform strategy — the exact work an admin agent can absorb once the guardrails are set.
Source: Twopir Consulting client discovery findingsThe average enterprise now runs about a dozen AI agents, and roughly half of them operate in isolation from each other. That is a collection of AI experiments, not an agentic layer — and it is why the second agent rarely delivers what the first one promised.
Source: Salesforce State of Integration & AI, 2026An agent demoed on clean sample data behaves differently in a real org, where field-level security, sharing rules, record types and duplicates decide what it can actually see. Agents inherit the running user's access — so a data model that is merely tolerable for humans becomes the thing that breaks the agent.
No regression tests, no observability, no defined escalation path, no owner for the day an instruction needs changing. One confidently wrong answer in front of a customer is usually enough to end the programme — and it is almost always an ownership gap, not a model failure.
Agentforce 360 is Salesforce's platform for building AI agents that act inside your CRM rather than just answering questions about it. You define an agent's topics and instructions; the Atlas Reasoning Engine breaks a request into steps and evaluates each one; the agent then reads grounded data and takes real actions through Flow, Apex, prompt templates and external APIs — under your existing permission and sharing model. Salesforce renamed the platform Agentforce 360 in October 2025; most buyers still search for it as Agentforce, and both names refer to the same product.
The distinction that matters commercially: Salesforce supplies the runtime; Twopir supplies the design, the build and the governance. Salesforce ships the reasoning engine, the builders, the standard action library and the observability tooling. We decide which work should become an agent at all, model the data it needs to be grounded in, write the custom actions the standard library does not cover, and put the tests and escalation paths around it. What the client gets is neither the licence nor the config — it is a bounded agent that a named person owns on the Monday after go-live. The wider platform work this sits inside is covered on our Salesforce consulting and Agentforce pages.
It is worth being blunt about who this is not for. If your Salesforce org has no reliable source of truth for the records an agent would read, the honest sequence is data foundation first and agents second — usually starting with Salesforce Data Cloud or a focused cleanup of the objects in scope. We will tell you that in the assessment rather than after the build. Salesforce's own documentation for the platform is available here.
These four get used interchangeably in vendor decks and they are not interchangeable. Picking the wrong one is the most expensive early decision on an AI programme.
| Building block | What it is | Reach for it when | Who maintains it |
|---|---|---|---|
| Flow & Apex | Deterministic automation. The same input always produces the same output. | The rule is knowable in advance and must never vary — approvals, routing, field updates, compliance steps. | Admin (Flow) or developer (Apex) |
| Prompt Builder | Reusable prompt templates grounded in record data, invoked from a field, a Flow or an agent. | You want consistent generated text — a summary, an email draft, a knowledge article — with no autonomy attached. | Admin |
| Einstein | Predictive and generative intelligence layered onto CRM records — scoring, forecasting, generative fields. | You need a prediction or a number rather than an action — deal scoring, forecast signals, lead prioritisation. | Admin, with a data owner |
| Agentforce 360 | Autonomous agents. Topics and instructions plus an action library, planned and evaluated by the Atlas Reasoning Engine. | The work needs judgement across several steps and the agent must actually do something at the end of it. | Admin for topics; developer for custom actions |
Twopir offers all three, and they are priced, staffed and scheduled differently. Knowing which one you are buying is the difference between a four-week engagement and a four-month one.
Standing Agentforce 360 up in an org that has never run it. Licensing and permission model, the grounding layer, the first agent in production, and a release path your team can repeat.
Tailoring what Salesforce already ships to how your team actually works. No Apex, no deployment pipeline — everything here is maintainable by an admin after we hand it over.
Custom development where the standard action library runs out. This is engineering work — it is versioned, test-covered and code-reviewed like any other Salesforce release.
Each one is scoped with your oversight built in. Agents draft, retrieve and act; your team sets the guardrails and reviews what matters.
Inbound leads answered in minutes rather than days, qualified against your real criteria, and escalated to an Account Executive with the conversation attached.
What a sales manager would say about every open deal, on every deal, instead of only the ones that reach a pipeline review.
The routine tier of your queue handled in channel, with a defined line past which a human always takes over.
Internal agents that answer from your own systems, and Setup with Agentforce put to work on the configuration backlog your admins never reach.
An agent is only as good as the records it reads. This is the work that decides whether the rest of the programme is worth starting.
The part that decides whether the agent is still running in six months. Salesforce ships the tooling; we put a process and an owner around it.
An agent is defined by its action surface. These are the connections that decide what yours can actually see and do — each one a real data relationship, not a logo on a wall.
The grounding layer. Data Cloud unifies customer records from systems that never shared an identity, so an agent answers from one profile rather than four conflicting ones. Without it, agents ground only on what sits natively in the org.
Data Cloud → agent context at query time · agent actions → CRM recordsThe action surface most agents live on. Leads, opportunities, cases and knowledge are both what the agent reads and what it writes, so pipeline and queue reporting stay correct whether a human or an agent did the work.
Records → agent · agent → record updates, tasks, case status, activity logWhere approvals and escalations actually happen. Putting the agent in Slack means a rep confirms or overrides in the tool they already have open, instead of the request waiting in a Salesforce queue nobody watches.
Agent → notification and approval request · human decision → back into the runHow an agent reaches an ERP, a pricing engine or a policy service that will never live in Salesforce. This is the boundary where configuration becomes custom development — the action has to be built, tested and released.
Agent action → API call out · response → back into the agent's plan, same turnWhere marketing still owns the demand engine. Campaign membership and engagement history reach the agent so an SDR agent knows what a prospect already received, and lifecycle changes flow back so marketing stops nurturing a closed deal.
HubSpot → engagement history and campaign context · Salesforce → lifecycle stage, ownerRetrieval over the documents your answers actually live in — contracts, policies, implementation notes. Access is inherited from the source system, so an agent cannot surface a file the asking user could not already open.
Documents → indexed for retrieval · permissions → enforced at the source, not in the agentFive stages. We do not publish a fixed week count, because the honest answer is that your data and your action surface set the timeline — so each stage below says what actually drives it.
We review the org, rank candidate use cases by value and feasibility, and say which ones are not ready. Duration is driven by how many teams and systems are in scope.
Modelling the records, knowledge and permissions the agent will read. Driven by the state of your data — this is the stage that stretches when duplicates and sharing rules surface.
Topics, instructions and actions built, then covered in Testing Center before release. Driven by how many custom Apex or API actions the standard library cannot supply.
A bounded audience first, with escalation paths live from day one and a rollback that has been rehearsed. Driven by your change-management appetite, not by the build.
Traces and agent analytics reviewed against real sessions, instructions tuned, then the next use case. Continuous — this is the stage that decides whether agent two works.
Every organization's baseline is different, so these are stated as changes rather than percentages. The number that matters is the one measured against your own baseline — which is why we take that baseline during the assessment.
Leads answered at 2am, not the next business day
The routine support tier handled in channel
Admins back on platform strategy, not upkeep
CRM hygiene that improves instead of decaying
Reps adopting Salesforce because it now does work for them
Forecasts built on activity that was actually logged
Volume absorbed without adding headcount
An escalation path people trust enough to use
We will not put a percentage on this page that we cannot evidence. Twopir has published Salesforce delivery outcomes where a client baseline was measured and cleared — the Invoca and Salesforce integration built for a legal services client, giving them call attribution, automated Lead creation and closed-loop revenue reporting, and the Sales Cloud rebuild for a mid-market manufacturer, with automated activity tracking, live dashboards and a call-logging flow. Those are integration and CRM engagements, not agent deployments — we list them because they are the engineering the agent layer sits on, and because the rest of the success stories are where our evidenced numbers live.
This work is built for revenue-driven organizations already running on Salesforce. There is no strict minimum to start the conversation — the assessment scopes the right approach for the org you have today, including telling you when the answer is "not yet".
What Usually Brings a Team to Us
Working in a regulated or highly specific vertical? The same agent work is shaped differently for law firms and service organizations, and ongoing optimisation runs through our Salesforce support engagements.
Agent programmes fail on data models, permissions and ownership — the unglamorous Salesforce work. That is the work we have been doing since 2014.
Some of the work that gets scoped as an AI agent is a Flow, a prompt template, or a data-quality problem wearing a costume. Saying so in the assessment costs us scope and saves the programme.
When an agent needs an action the standard library does not ship, we write the Apex, cover it with tests and release it through your pipeline — rather than reshaping the requirement until configuration can fake it.
Duplicates, sharing rules and stale knowledge articles are what a production agent actually trips on. We fix the records first, because a well-instructed agent reading bad data is just a faster way to be wrong.
Test coverage in Testing Center, observability wired to your monitoring, a documented escalation path, and a named person who can change an instruction on Tuesday. Handover is part of the build, not a follow-on quote.
The common failure is a dozen agents that cannot see each other's work. We design the grounding layer and action library so the second and third agents extend the first instead of duplicating it.
Agentforce 360 is Salesforce's platform for deploying AI agents that carry out multi-step work inside Salesforce — sales engagement, customer service, employee support and platform administration — rather than waiting for a person to prompt every step. Einstein supplies predictive and generative intelligence on records: scoring, forecasting and generated text. The practical difference is autonomy and action. Einstein tells you something; an Agentforce agent plans a sequence, takes actions through Flow, Apex and APIs, and reports what it did. Salesforce renamed the platform Agentforce 360 in October 2025, and most buyers still search for it as Agentforce — both names refer to the same product.
Configuration ends at the edge of the standard action library. If the work can be expressed as a topic, an instruction, a prompt template, a Flow or a standard action, it is configuration — no Apex, no deployment, and your admin can maintain it. When the agent needs something Salesforce does not ship — a call into a pricing engine, an external policy check, a bulk operation larger than a Flow will hold, or a return shape the standard action cannot express — it becomes custom development: an Apex invocable action with its own test coverage, reviewed and released like any other code. The test we use with clients is whether an admin could change it on a Tuesday without a deployment.
Not for every use case. An agent can ground on records, knowledge articles and files that already live in your Salesforce org, and plenty of first agents need nothing more. Data Cloud earns its place when the answer depends on data the org does not hold — product usage, billing history, support telemetry, or a customer identity that is currently split across several systems. The assessment is where that gets decided, because the cost of adding Data Cloud is real and so is the cost of an agent that confidently answers from half a customer record.
It depends on two things far more than on the number of agents: the state of the data the agent must be grounded in, and how many actions it needs that Salesforce does not ship as standard. A configuration-only agent on clean, well-modelled records is a short engagement. The same agent on an org with duplicate accounts, unclear sharing rules and three custom API actions is a materially longer one. We deliberately do not publish a fixed week count we cannot evidence — the AI Readiness Assessment produces a scoped timeline for your org before any build work is committed.
Four layers, and no single one of them is sufficient. Grounding limits what the agent can draw on to your own cleared records and knowledge. The permission model limits what it can see and change, because an agent runs under a real user's access. Topic and instruction design defines what is in scope and what must be escalated to a human. Testing Center coverage and agent observability catch regressions before and after release. We also insist on a defined escalation path and a rollback plan at launch — the first bad answer is survivable when someone owns the response and can change the instruction that caused it.
No — and the ones we work with end up with more influence, not less. Setup with Agentforce absorbs repetitive configuration, documentation and maintenance work: flow recommendations, permission-set analysis, duplicate detection, deployment readiness checks. What it does not do is decide what the platform should become, arbitrate between two teams who both want the same field, or own the consequences of a design decision. In practice the admin role shifts from upkeep toward platform strategy, and agent ownership becomes part of the job.
Often not yet, and it is worth hearing that before you buy licences. Agents inherit your data model, your sharing rules and your record quality; an org where reps avoid logging activity and accounts are duplicated will produce agents that are confidently wrong. The usual sequence is a focused remediation of the objects the agent needs — not a full rebuild — and then the agent on top of it. That remediation is work we do, so we have no incentive to skip it; we simply prefer to sell it in the right order.
An AI Readiness Assessment with a Twopir Agentforce architect maps your sales, service, admin and reporting workflows, ranks the candidates by value and feasibility, and tells you which ones are not ready yet. No generic deck. A direct conversation about your Salesforce org.
Salesforce architecture · revenue operations · AI agents your team will actually trust
