External agents: LangGraph, Claude, and the loop you own | Cleon

You go off-platform when the platform isn't where the work is. The job runs against systems Salesforce doesn't reach, or needs a control loop you shape yourself, or spans models and providers no single platform owns, or wants a capability you can only get by calling a model API directly. That is when an external build is the right instrument (principle 7) — not because it is more advanced, but because it fits a job the platform path doesn't. This is the "beyond Salesforce" side of Cleon's work, and it earns its place exactly when the work has left the platform.

The one sentence that defines the external path: you own the loop. Agentforce hands you a managed planner, grounding to the Data 360 profile, the platform security model, governance, and an audit trail for free — you wire up tools and instructions, not the control loop. Off-platform, you build all of that yourself. That is the cost and the freedom in the same breath, and this page is mostly about being honest about both.

The stack: three instruments, composed

An external agent is usually three pieces working together, and Cleon composes them rather than treating any one as the whole answer:

LangGraph — orchestration. When the flow needs explicit structure, you draw it as a graph: nodes (steps), edges (transitions, including conditional ones), and a shared state object every node reads and writes. The graph mechanics are covered in depth in orchestration patterns — this page does not re-teach them. What matters here is who builds the graph: off-platform, you do. There is no managed planner deciding the flow; the graph you draw is the flow.
The Claude API (or another LLM API) — the reasoning core. This is the model you call directly for the reasoning step inside the loop. Direct API access is what gives you model choice, control over how you call it, and a capability path the platform may not expose. Tool use through the Claude API is the same mechanic covered in tools and actions — name, description, typed schema, structured call — so this page references it rather than re-explaining it.
MCP — tool interop. The Model Context Protocol lets a tool be exposed once and reused across hosts, which is how an external agent reaches systems Salesforce doesn't. MCP is covered in tools and actions; the relevant point off-platform is that it is your connective tissue when the tools span systems and you want them callable from more than one place.

None of these competes with the platform path. They are the instruments you reach for when the work is off-platform; the skill is composing them, not defending them against Agentforce.

The control loop you own

This is the heart of the difference. On Agentforce, the Atlas Reasoning Engine is the managed planner — it runs the reason-and-plan step for you, and you supply the tools, instructions, and grounding around it. Off-platform, there is no Atlas. You write the perceive → reason → act → observe loop yourself — the ReAct loop from what is an agent — or you encode it as a LangGraph graph when it needs explicit structure.

Owning the loop means owning everything that bounds it. The step cap, the token budget, the timeout — none of those exist until you write them, and a loop with none of them is the runaway from agent gotchas waiting to happen. You decide the stop conditions: when the agent has an answer, when it has tried enough, when it must hand off to a human. The managed path made those decisions for you inside the platform's guardrails; the external path hands them all back, which is power only if you spend it deliberately.

State and memory you own

A managed agent carries conversation state for you. An external agent carries whatever you decide to carry, and where it lives is your call: in the graph's shared state for the duration of a run, in a store you stand up for memory that outlives the run, or both. Nothing persists between steps or sessions unless you make it persist.

That ownership is also where principle 10 lands hardest — context is a budget, not a bucket. With no platform trimming the window for you, an external loop that appends every step's output to the prompt degrades exactly as it runs longer, the context-overflow gotcha in its purest form. You decide what each step actually needs, what you summarize, what you drop, and what you retrieve on demand. The state is yours to design, which means the context rot is yours to prevent.

When external is the right call

The external path is the right instrument, not the advanced one, in a specific set of cases:

A custom control loop or UX no platform gives you — when the flow, the interaction, or the surface has to be something you shape directly, and a managed planner inside a platform UI is the wrong shape for it.
Multi-model or multi-provider — when the job calls more than one model, or models from different providers, and you need to route between them yourself rather than work within one platform's model set.
A model or capability Salesforce doesn't reach — when the specific model, modality, or capability you need is one direct API access gives you and the platform does not.
No Salesforce dependency in the stack — when the work genuinely lives elsewhere and there is no reason to pull a platform dependency into it.
Portability — when you want the agent and its tools to move between hosts (which MCP buys you) rather than be welded to one platform.

If none of those is true and the work lives in the Salesforce security model on governed customer data, the platform path is very likely the better instrument. External is not the upgrade — it is the right answer to a different question.

The cost of leaving the platform

Here is the part a demo never shows. Everything Agentforce gave you for free is now yours to build:

Grounding. No platform retrievers over a Data 360 profile — you stand up the RAG pipeline, the retrieval, and the "what happens when retrieval comes back empty" path yourself (principle 2). The grounding gotcha is entirely on you off-platform.
The security model. No sharing rules, field-level security, or "runs as this user under their permissions" baked in. Whatever access control the agent needs, you implement and enforce in code.
Governance and audit. No platform recording what ran. The audit trail that makes a consequential action defensible — who or what invoked it, the arguments, the result — is something you build, or you ship an agent whose actions you cannot reconstruct.
Observability. No platform giving you the trace for free. You instrument the inputs, the retrieved context, the tool calls and results, and the output for every run yourself, because principle 11 holds off-platform too: you cannot debug what you cannot replay.

This is principle 4 stated plainly — the model is the easy part; the system is the job. Calling the Claude API is an afternoon. Building the grounding, the security model, the governance, the audit, and the observability around it is the quarter, and off-platform that whole bill is yours. Budget for it before you leave the platform, not after the first incident asks who approved the action and you have no answer.

Composition, not competition

The honest picture is not external or platform — it is often both. A real system runs Agentforce for the in-platform, governed actions where the work lives in the security model, and an external LangGraph graph for a step the platform can't reach, and they hand off to each other across a clean seam. Agentforce owns the part that needs the platform's governance; the external graph owns the part that needs a custom loop or a model Salesforce doesn't reach. Neither is winning; each is doing the job it is the right instrument for.

That is the whole stance of this subcategory restated from the off-platform side. The external path is depth and freedom you reach for when the work has left the platform — and a pile of responsibility you signed up to own the moment you did. Compose it with the platform path (principle 7), respect what you now have to build yourself (principle 4), and the off-platform loop becomes an instrument you control rather than one that controls the bill.

Agentforce agents — the complementary platform path, where Atlas plans and the governance comes baked in
Orchestration patterns — the graph mechanics (nodes, edges, state) this page builds on without re-teaching
Tools and actions — tool calling through the Claude API and MCP, the mechanic behind an external agent's hands
What is an agent — the perceive → reason → act → observe loop you write yourself off-platform
Agent gotchas — the runaway loops, context rot, and grounding gaps you own when you leave the platform
Agent Style Guide — the bar an external agent clears before it ships
AI Engineering principles — compose the toolkit (7), the system is the job (4), context is a budget (10), trace everything (11)

Reference: