Agentforce or build your own agents? The build-vs-buy math that actually decides it

Every enterprise evaluating AI agents eventually hits the same fork, and it’s usually framed as a religious war: buy the packaged platform (Agentforce) or build your own on a raw stack (an LLM API plus a framework like LangGraph or the OpenAI and Claude agent SDKs). The vendor decks make it sound like a values question — control versus convenience, open versus locked-in. It isn’t. It’s an arithmetic question with a crossover point, and the teams that get it wrong are the ones who answered it with a slogan instead of a spreadsheet.

I’ll say the uncomfortable part first: for most companies already standardised on Salesforce, whose agents mostly read and write CRM data, Agentforce is the correct default — not because it’s technically superior in the abstract, but because the total cost of building the same governance, grounding, and observability yourself is far higher than it looks, and you’d be rebuilding capabilities Salesforce already amortises across every customer. But “most” isn’t “all,” and the exceptions are real and expensive to get wrong. This post is the framework for telling which one you are, before you commit a year of roadmap to the answer.

What you’re actually comparing

The mistake is comparing “Agentforce” to “an LLM.” That’s not the comparison. An agent in production is a stack, and when you build your own you own every layer of it. Lay the two side by side honestly:

Buying Agentforce, you get as managed services:

• The reasoning/orchestration layer — the Atlas reasoning engine that decides which topic and action to run.
• The safety layer — the Einstein Trust Layer, which sits between every prompt and the model doing masking, grounding, audit logging, and toxicity filtering.
• Grounding on your data through Data 360, including retrievers and the search index.
• Identity, sharing, and permissions inherited from the platform — the agent runs as a user and sees exactly what that user’s governance rules allow.
• Testing, observability, and lifecycle tooling — Testing Center and Command Center.
• A choice of foundation models under the hood, swappable without re-plumbing.

Building your own, you own and operate:

• The LLM provider and contract (OpenAI, Anthropic, Google, or a self-hosted open model).
• The orchestration framework — LangGraph, the OpenAI Agents SDK, the Claude Agent SDK, or hand-rolled. LangGraph runs in production at companies like JPMorgan, Uber, and LinkedIn, so this is a legitimate path, not a toy one.
• A vector database and the entire RAG pipeline — chunking, embedding, retrieval, re-ranking.
• Hosting, scaling, and the on-call rotation when it falls over at 2 a.m.
• Your own guardrails, PII masking, prompt-injection defence, and audit trail — the Trust Layer’s whole job, rebuilt.
• Evaluation harnesses, regression suites, and CI gates for non-deterministic behaviour.
• Every integration to Salesforce data you need, plus the permission model to keep the agent from reading records the end user can’t.

Look at the second list and the real question resolves itself. You’re not choosing a model. You’re choosing whether to operate a platform. That’s the frame everything else hangs on.

Buy-versus-build for agents isn’t “which model is smarter.” It’s “do we want to be in the business of running an agent platform” — because building your own means you now are, forever.

The TCO components both sides leave off the slide

Each side has costs the other side’s sales motion conveniently omits. Put them all on one page.

What Agentforce advocates underplay — consumption cost at scale. Agentforce meters usage, and at high volume the meter is the whole conversation. Flex Credits price each action an agent takes at 20 credits — about $0.10 at list (a 100,000-credit pack lists at $500), or you can use the older per-conversation meter at $2 per conversation. The full pricing breakdown is its own topic, but the headline for this decision is that cost scales with usage and doesn’t stop. A well-scoped service interaction runs a few actions ($0.20–$0.50); at ten million interactions a year, that’s real money, every year, forever. And the metered agent usage often isn’t even the biggest line — Data 360 grounding credits are billed separately and quietly.

What build-your-own advocates underplay — the platform you now operate. The LLM API bill is the small part of a custom stack, and quoting only it is how build proposals lowball. The real cost is engineering: building and maintaining the RAG pipeline, the eval harness, the guardrails, the observability, the Salesforce integration and its permission model, and staffing the on-call rotation that keeps it alive. That’s a team — several senior engineers, indefinitely — not a line item. It’s also the part that never appears in the “look how cheap the tokens are” comparison, and it’s usually the deciding cost.

The crossover is genuinely a function of scale. Below roughly a million agent conversations a year, the fixed cost of operating a custom platform dominates and Agentforce’s managed services win on TCO — you’re renting capabilities you couldn’t build for less. Above it, the per-unit consumption meter can grow past the fixed cost of running your own, and build starts to pencil out — if you actually have the engineering muscle to run it well, which is the assumption most build cases quietly make and few can honestly hold. Run this with your own numbers; the point isn’t the exact threshold, it’s that there is one, and that it moves with volume, not with vibes.

The model question is smaller than you think

A common reason teams reach for “build” is model choice — the belief that a packaged platform traps you on one vendor’s LLM. In Agentforce specifically, that belief is out of date.

Agentforce runs the Atlas reasoning engine over a choice of foundation models, not a single hardcoded one. The Salesforce-default option is a managed mix of trusted models (currently including GPT-4o) that Salesforce tunes for accuracy and cost. Beyond the default, the supported set spans OpenAI models, Google Gemini, and — following the Salesforce–Anthropic partnership — several Anthropic Claude models, with an AWS-hosted Bedrock option for teams that want the model running in that boundary. You can even override the model per subagent, and route a cheap classifier model to routing while a stronger model handles the hard reasoning. For anything the standard set doesn’t cover, Model Builder and the bring-your-own-model paths let you plug in your own.

So “we need model flexibility” is rarely a real reason to build the whole stack yourself anymore — the flexibility largely exists inside the platform. The genuine model-level reasons to build are narrower and worth stating honestly: you need a fine-tuned or open-weight model Agentforce doesn’t host, you have a hard data-residency requirement the platform’s hosting options don’t meet, or your reasoning is so specialised that you need orchestration control the Atlas engine doesn’t expose. Those are real. “We might want to switch models someday” usually isn’t.

When building your own is the right call

Buying is the default, not the law. Build genuinely wins in specific, recognisable situations — and if you’re in one, the crossover math above is already on your side.

• You’re not a Salesforce shop. If your systems of record, your customer data, and your team’s skills don’t live in the Salesforce ecosystem, half of Agentforce’s value — inheriting CRM data, permissions, and grounding for free — doesn’t apply to you. You’d be paying platform overhead to bridge to data that lives elsewhere. Build closer to your actual stack.
• The agent’s core job is your differentiator, not a standard pattern. Agentforce is superb at the common shapes — service deflection, sales assist, employee help. If your agent is the product — a novel reasoning workflow that’s the thing customers pay you for — you probably want to own it end to end rather than express it in a configuration surface built for CRM patterns.
• You operate at a scale where consumption pricing loses to fixed cost. Past the crossover, and with a platform team that can run agents to a real reliability bar, owning the stack can be cheaper per unit. Both halves of that sentence have to be true.
• You have hard requirements the platform can’t meet — a model, a data-residency posture, or an orchestration pattern that genuinely isn’t supported. Confirm it’s actually unsupported first; a lot of “Agentforce can’t do X” turns out to be “we didn’t know Agentforce does X.”

Notice what’s not on that list: “we want control” as a feeling, “open source is philosophically better,” “our engineers would enjoy it.” Those build sympathy, not agents. The reasons to build are structural, and if you can’t point to a structural one, you’re about to rebuild the Trust Layer for fun.

Most enterprises end up hybrid — and that’s fine

The real-world answer for large organisations is rarely all-or-nothing. The common landing spot: Agentforce for the standard, CRM-adjacent scenarios — service, sales assist, internal help desk — where its managed governance and grounding are exactly what you’d otherwise rebuild, and a custom stack for the two or three workflows that are your actual differentiator or that live outside Salesforce entirely.

If you go hybrid, the interoperability layer matters more than either agent. This is what MCP — the Model Context Protocol — is for: it lets a custom agent call Salesforce-governed actions, and lets Agentforce reach external tools, without either side hand-building a bespoke bridge to the other. Design the seams first. A hybrid estate with no interoperability standard is two silos wearing a trench coat, and you’ll pay for the integration you didn’t plan.

The takeaway

Buy-versus-build for agents is a cost-and-capability decision, not an identity. Buying Agentforce rents you a reasoning engine, a trust layer, grounding, permissions, and lifecycle tooling that are genuinely expensive to build well — which is why, for the Salesforce-centric, CRM-shaped majority, it’s the right default and the “build it cheaper ourselves” case usually collapses once you price the platform you’d have to operate. Building your own wins when you’re not a Salesforce shop, when the agent is your differentiator, when you’re past the scale where consumption pricing loses to fixed cost and can staff a platform team, or when you hit a hard requirement the platform can’t meet. Most large organisations land in the middle and run both — at which point the question stops being “which agent” and becomes “how do they interoperate,” which is the MCP question. Answer it with your own numbers and your own requirements, not a vendor’s slogan, and you’ll pick the side of the line you’re actually on. If you want a sober second opinion — and an honest read on whether your case is genuinely a build case — that’s exactly the call our Agentforce practice makes with clients before a roadmap gets committed, and the ROI calculator is a fair place to start the math.

Understanding the basics

Is it cheaper to build my own AI agents than to use Agentforce?

It depends entirely on scale and on whether you can operate a platform. Below roughly a million agent conversations a year, Agentforce’s managed services (reasoning engine, trust layer, grounding, permissions, observability) usually win on total cost, because building and running those yourself requires a standing engineering team that dwarfs the LLM API bill. Above that volume, Agentforce’s per-action consumption pricing can grow past the fixed cost of a custom stack — but only if you actually have the engineers to run agents to a production reliability bar. The LLM tokens are the small part of a custom build; the RAG pipeline, guardrails, evals, integration, and on-call are the real cost.

Can I choose which LLM Agentforce uses?

Yes. Agentforce runs the Atlas reasoning engine over a choice of foundation models rather than a single fixed one. The Salesforce-default option is a managed mix of trusted models, and the supported set includes OpenAI models, Google Gemini, and Anthropic Claude models (with an AWS-hosted Bedrock option). You can override the model per subagent, and use Model Builder or bring-your-own-model paths for models the standard set doesn’t cover. Because of this, “we need model flexibility” is rarely on its own a reason to build a fully custom stack.

When should an enterprise build its own agent stack instead of using Agentforce?

Build when there’s a structural reason: you’re not a Salesforce shop and your data and skills live elsewhere; the agent’s core reasoning is your actual product rather than a standard CRM pattern; you operate past the scale where consumption pricing loses to fixed cost and can staff a platform team; or you have a hard model, data-residency, or orchestration requirement the platform genuinely can’t meet. Wanting “control” or preferring open source as a philosophy are not structural reasons — they lead to rebuilding capabilities like the Einstein Trust Layer that Salesforce already amortises across every customer.

---

Weighing Agentforce against a custom agent build and want the math done honestly — including the platform costs both vendors leave off the slide? Talk to us. Telling clients which side of the line they’re actually on, before they commit a roadmap to it, is a big part of what we do.