Agentforce vs. an Open Self-Hosted Runtime: When to Choose Each
A company nearly signed with Agentforce until it found that half its data lived outside the suite. Here is when to choose a closed suite, when to choose open self-hosting, and when to use both.
The short version: Closed suites win inside their own ecosystem when most of your business already lives there. When data is spread across systems, must stay under your control, and you want model choice, an open self-hosted runtime, or a hybrid architecture, is often the better answer.
A company was selecting an AI agent platform, and the shortlist came together naturally: Agentforce, Copilot Studio, ServiceNow AI Agents. All three are strong, all three came recommended.
They nearly signed with Agentforce because it demoed best for the CRM scenario. Right before the final step, an architect raised a question: “The customer issues we want the agent to handle need two sources. Half require opportunities in Salesforce, and half require delivery and ticket data in our in-house systems. How does Agentforce reach the half outside the suite?”
Sales’ answer was “we can do integrations.” So they spent six weeks on an integration PoC. The conclusion was clear: it can connect, but every system outside the suite requires another sync, another definition-mapping exercise, and another pipeline to maintain. They had seven or eight such systems. In that moment, the team realized: the problem was not that Agentforce was not good enough; it was that, like the other two, it assumed a premise that did not hold for this company.
The six-week PoC bought a lesson they could have reasoned through at the start.
The Unspoken Premise: Your Whole World Lives Inside One Suite
The strength of these suites is essentially “best within the ecosystem.” Agentforce assumes your customers, processes, and objects are already in Salesforce; Copilot Studio assumes your collaboration, documents, and identity are in Microsoft 365; ServiceNow assumes your processes are already on ServiceNow. When the premise holds, they really are efficient: data ready, permissions ready, integrations ready, and the agent connects with little friction.
But this premise does not hold for many enterprises. The real enterprise often looks like this: CRM from one vendor, ERP from another, ticketing from a third, plus a pile of in-house systems and spreadsheets. The company wants to keep model choice open because models change every year. It also operates under regulatory constraints, so data cannot casually leave its environment. For that enterprise, “best within the ecosystem” becomes a constraint, because the business does not live inside any one vendor’s suite. Having to maintain a pipeline for every outside system is exactly the barrier that company hit in its PoC.
Side by Side: Not Which Is Better, but Which Fits
| Dimension | Closed suite (Agentforce / Copilot / ServiceNow) | Open self-hosted runtime (ObjectStack / ObjectOS) |
|---|---|---|
| Best for | Business already concentrated in that ecosystem | Data scattered across systems, cross-stack, must remain self-held |
| Data location | Vendor cloud | Your own infrastructure |
| Model choice | Favors first-party or bound models | Switch freely — model outside, runtime inside |
| Ownership of business definition | Grows inside the platform | Open-protocol metadata in your repo (Apache 2.0) |
| Billing | Per-action / per-seat | Per runtime and infrastructure, decoupled from usage |
| Starting posture | Move the business into the ecosystem first | Extend existing systems, no migration required |
There is no universally correct column.
First, Be Honest: A Lot of the Time, You Should Choose the Suite
Say it up front, so this piece does not become a one-sided pitch: open self-hosting is not the more noble choice. It is the right choice for a specific situation, and many companies are genuinely better suited to a suite.
First, if your world really is mostly inside one suite. If 90% of your business is in Salesforce, you do not care about data leaving that domain, and you do not plan to switch models, then Agentforce is most likely the optimal answer. Taking on a real operating burden to guard against a future lock-in risk may not be worth it.
Second, if you have no platform team. This is the classic “build vs. buy” trade-off. Open and self-hosted means you have to run it yourself: patching, guaranteeing availability, and managing upgrades. For a company without a dedicated platform team, the managed experience of a suite, with vendor support and an SLA behind it, is often more valuable than “complete control.” Control has an operating cost, and control no one can carry is a burden.
But “Buying a Suite” Saves Less Work Than You Think
Still, on the “buy” side, there’s a bill often left out of the math: the integration tax.
The suite’s quote lists the cost of seats or actions. What it often does not list is the integration work: each of your seven or eight outside systems needs a pipeline, definitions must be aligned when you build it, both sides must be maintained as they upgrade, and a field change at either end can silently break the flow. The opening company’s six-week PoC measured the down payment on this tax. “Buy a suite plus a pile of brittle integrations” looks like buying on the surface, but at its core you are still building, and building the least valuable, most brittle part.
Fold this integration tax into TCO, and the conclusion “buying is easier” only holds when you have few systems outside the suite, or when those systems do not need to be touched by the agent in the first place. The more scattered your systems, the heavier this tax becomes.
You Can Use Both: Hybrid Is Not Fence-Sitting
This leads to an option often overlooked in platform-selection debates: this is not necessarily a single-choice question.
The most pragmatic architecture is often hybrid: in the ecosystem you genuinely use heavily, keep using its suite. Let the sales agent inside Salesforce do what Agentforce does best. But for the layer that is cross-system, needs unified definitions, and needs self-held data, use an open, self-hosted runtime as the connecting tissue. The latter does not replace the suite; it does what the suite is structurally less suited for: gathering business concepts scattered across multiple systems into one unified definition that you hold yourself, with permissions and audit attached.
In other words, the open runtime can be the connecting tissue above several systems, including those suites, rather than another wall asking you to move in. Acknowledge this, and selection shifts from “which vendor do I bet on?” to “which part uses a suite, and which part uses open?” That is where many real enterprises ultimately land.
Open Self-Hosting: What Exactly Do You Get?
If you belong in the right-hand column, or if what you need to build is precisely that cross-system connecting layer, then “open and self-hosted” buys you concrete capability, not sentiment. The most telling difference is its posture toward existing systems, which is also where that opening company got stuck.
The suite wants your world to move into its environment. The open runtime assumes your world is scattered to begin with, and its job is to make existing systems support AI without forcing a migration first. That company’s customer data was half in Salesforce and half in in-house systems. On ObjectOS, it can connect both Salesforce and the in-house database as datasources, model each, and align them into one governed “customer” by a shared key:
export const Customer = ObjectSchema.create({
name: 'crm_customer',
label: 'Customer',
fields: {
name: Field.text({ label: 'Customer name', required: true }),
tax_id: Field.text({ label: 'Tax ID' }), // a shared key to align "the same customer" across systems
},
});The difference can be made concrete down to a single question. “Is this customer worth committing resources to retain?” —
- Before: the agent connected to Salesforce, saw active opportunities, answered “worth it”; it had no idea that in the in-house system this customer’s deliveries kept slipping and tickets were piling up.
- After: the agent faces one unified customer, seeing opportunities, delivery, and tickets together, and answers “the opportunities look good, but delivery risk is high — fix fulfillment first before talking expansion.”
Same model, same question. Because the “customer” beneath it is no longer split across walls, the conclusion goes from partial to whole. None of this requires rewriting a sync pipeline for each outside system. The business definition is diffable, migratable metadata in your repository; the runtime runs on your own infrastructure, enforces permissions, and records audit; the model can come from any external vendor. You have not handed “the definition of your own business” to anyone else for safekeeping.
An Honest Multiple-Choice Question
So this is not “who should be eliminated.” It is “which part goes where.” Ask yourself three questions:
- Is my business basically all inside one ecosystem, or scattered across multiple systems?
- Can I accept data flowing continuously to the vendor cloud? Can I sign off on that for compliance?
- Do I have a team to operate a self-hosted runtime?
If the first two answers lean “scattered, no,” and the third leans “yes,” then what you are looking for was never just a stronger closed suite, at least not for the cross-system layer. If all three answers lean the other way, use the suite generously; they really are easy to use. Placing yourself in the right category, including a hybrid category, matters far more than chasing whichever vendor has the newest feature. It is also cheaper than spending six weeks on a PoC only to figure it out.
Closing
What closed suites win on is “best within the ecosystem,” an advantage that is very real when its premise holds and should not be denied. What open self-hosting wins on is “still works when the premise does not”: when your world is scattered, your data must remain self-held, your model choice must remain open, your definition must stay in your own hands, and you can bear the responsibility of running it yourself.
Knowing which part should use a suite, which part should use open, and what each choice costs you matters more than any vendor’s feature list. Had the opening company asked those three questions sooner, it could have saved six weeks and a PoC.
npm i -g @objectstack/cli && os startNo migration, no moving into anyone else’s suite: create a unified object across two systems in your own environment in five minutes, then judge whether this path fits what you need.