Strategy & Insights
September 1, 2026

Headless 360 gave you 100 endpoints. Now what?

Salesforce solved the access problem in April. The architecture problem is still sitting on your desk.

Yoav Kolodner, CEO, Tribal
Headless 360 gave you 100 endpoints. Now what?

Headless 360 turned 25 years of Salesforce capability into APIs, MCP tools, and CLI commands. That's the access half of agent readiness, and it's genuinely done. The other half is deciding which of those endpoints an agent should be allowed to call, which of your existing Flows quietly assume a human is watching, and where you need to build something new. That's architecture work, and no catalog does it for you.

At TrailblazerDX in April, Parker Harris put the whole thing in one question. Why should you ever log into Salesforce again.

It's a good question and the platform now has an answer. Headless 360 ships 100+ new tools and skills. Hosted MCP servers cover SObject reads, mutations and deletes, Flows, Invocable Actions, the API Catalog, Data 360, Tableau Next, and Prompt Builder templates. Any MCP-compatible client connects over OAuth 2.0 with PKCE. Field-level security, object permissions, and sharing rules are respected at every call. On the build side, the DX MCP Server gives Claude Code, Cursor, and Windsurf live access to the org from a terminal.

The rebuild behind it took about 2.5 years. It's real work and it removes a real blocker.

Then you sit down on Monday to actually build an agent, and you find the blocker moved rather than disappeared.

The catalog tells you what exists, not what to use

Open your org's exposed surface and you're looking at hundreds of callable things. Every Flow with the right settings. Every @InvocableMethod. Every @AuraEnabled Apex method, every Apex REST method, every Named Query. All of it available to an agent, none of it labeled with the thing you need to know.

Which ones should an agent call?

That question has four sharp edges, and every team hits all four.

Some Flows assume a human is on the other end. A Screen Flow that collects a shipping exception works beautifully because a rep reads the validation message, understands what went wrong, and tries something different. Hand the same Flow to an agent and it gets a rejection with no path forward. The Flow is technically exposed. It is not usable.

Some logic no longer matches the business. You have an Invocable Apex method called ApplyRenewalDiscount that was written against a pricing policy Finance changed in 2023. It still runs. It still returns a number. Nobody has invoked it from a UI in two years, so nobody noticed. An agent will invoke it happily.

Some capabilities exist in three places. Account escalation is implemented once in a Flow, once in a trigger, and once in a managed package that Support bought separately. All three are exposed. They do slightly different things. Pick wrong and your agent's behavior diverges from what your service team believes is happening.

And some things you need don't exist at all. The clean, idempotent, agent-shaped action that does exactly one job and returns a structured result. Nobody built that, because until this year there was no reason to.

Salesforce's own catalog reads what's documented and structured. Most real enterprise orgs at mid-to-large scale carry a lot of metadata that is neither.

What the architecture work actually involves

Getting from an exposed surface to a working agent means answering four questions per capability, and there's no shortcut around doing it.

What does this actually do right now? Not what the description field says. What the current implementation does, including the branch someone added for one customer in 2021 that has never been removed.

Is it safe to hand an agent as it stands? Does it fail cleanly? Does it return something a model can reason over? Is it idempotent if the agent retries? Does it assume a human will interpret the result?

What does it touch downstream? An agent calling one Invocable Apex method can set off 12 automations, three of which write to the same field. That's how you get Apex CPU time limit exceeded in production with a stack trace nobody can read.

Who is allowed to call it? Agentforce agents run as an Agent User with their own profile and permission sets. Every exposed action needs an answer to what that identity is permitted to do, and the answer should be least privilege rather than whatever gets the demo working.

Four questions, times a few hundred endpoints. That's the architecture phase, and it's the reason "we have MCP servers now" and "we have agents in production" are separated by about two quarters at most companies.

Where Tribal sits in this

Tribal reads the exposed surface against your live metadata and produces the thing the catalog can't: a judgment on each capability.

Agent-ready as it stands. Needs restructuring first, and here's specifically what. Duplicated elsewhere, use this one. Missing, build it.

For the ones that need restructuring, Tribal does the restructuring. A Screen Flow becomes an Invocable action with structured inputs and a fault path an agent can reason over. Overlapping implementations get consolidated behind one entry point. Apex gets refactored, tests generated, impact simulated against the rest of the org before anything deploys.

For the ones that don't exist, Tribal builds them, native to your platform, using your existing objects and fields.

And a permission model gets attached to each one, derived from what the action actually touches. Your data stays where it is. Zero-copy, authoritative, inside your perimeter.

The same applies when your endpoints live in ServiceNow or NetSuite rather than Salesforce. The nouns change and the four questions don't.

"Building our customer health monitor with Tribal proved AI can deliver at enterprise scale. It runs natively in Salesforce, meets every security standard, and never exposes our data outside our trusted environment."

Tal Carmi, CIO, WalkMe

The uncomfortable part

There's a line in the independent analysis of the TDX announcement that stuck with me. Headless 360, MCP tools, Agent Script, native React, hosted servers: it's a pro-code menu. The framing makes it feel accessible. The underlying skill set is software engineering.

That's an honest read, and it puts most enterprise application teams in an awkward position. The people who understand your business logic well enough to say which action an agent should call are usually declarative builders and business analysts. The tooling that just shipped assumes a developer with a terminal.

Closing that gap is the actual work of the next year. Salesforce made the platform callable. Somebody still has to decide what to call, and that somebody should be the person who knows why the escalation rule has an exception for accounts in Quebec.

Start with your own surface. Ask what's exposed, then ask which of it you'd trust an agent to invoke tomorrow morning without a human watching. The distance between those two lists is your roadmap.

Read more

Onwards. With Tribal