Scenario: one shared connector, three agents

A concrete, worked example. Say you have a support-bot agent built in LangGraph, a research agent built in CrewAI, and an internal ops agent built in plain LangChain — and all three need to look things up in Salesforce.

Without a control plane

Each of the three agent processes needs the Salesforce credential in its own environment — so now there are three copies of the same secret to rotate when it expires, and three places it could leak from. The support-bot's author writes a custom HTTP callback for "pause and ask a human before deleting a Salesforce record," because that's the only way their framework supports it. The research agent doesn't have that safeguard at all, because nobody built the equivalent for CrewAI yet. If something goes wrong at 2am, "stop everything" means finding which of three separate processes is misbehaving and killing it by hand. And "what did these agents do to Salesforce last week" is answered by however much each of the three individually happened to log — usually inconsistently, usually incompletely.

With Runkite

One Salesforce connector, configured once. All three agents reference it by name from their own langgraph.json, regardless of which framework they're written in — the plane doesn't care that one is LangGraph and another is CrewAI. Concretely, here's what changes:

• One credential, minted fresh per call — the Salesforce secret lives in one place (Vault, a file, or an env var — see Secrets), and each agent gets a short-lived, run-bound session instead of holding the real credential itself.
• One human-approval rule, applies to all three — a single mandatory-HITL rule on the "delete record" tool covers the support bot, the research agent, and the ops agent identically, with no framework-specific plumbing.
• One kill switch — if the research agent starts misbehaving, stop just that agent (or the whole tenant) from Admin → Kill switches, no SSH required.
• One audit trail — every Salesforce call from any of the three agents lands in the same searchable log, filterable by agent, so "what did we do to Salesforce last Tuesday" has a real, complete answer.

Under the hood: clients create threads and runs by calling the plane's Agent Protocol API; each of the three runners (whichever language/framework they're written in) pulls its work from the plane via a separate Runner Protocol. Neither side needs to know the other exists directly — the plane is the only thing both talk to.

When this scenario doesn't apply to you yet

If you only have the one agent and nothing else shares its connector, you don't need any of the above yet — see Why a control plane for when it's worth adding this layer versus when it's premature.

Product framing: landing scenario · Try path: Try it · Connectors & HITL (the full connector setup this scenario uses)