Featured image of post The Composable Provider Model

The Composable Provider Model

Agent specialization through filesystem composition beneath a fixed LLM harness. Why the CLI is a composable SDK and the agent is a recipe, not code.

Every interaction with a hosted LLM passes through the same structural layers: a use case, a harness that mediates between the user and the model, and the API itself. The harness assembles prompts, dispatches tool calls, manages context, and enforces behavioral constraints. Claude Code CLI, the Claude Desktop sandbox, the Anthropic SDK, and raw API access are all harnesses, each with different tradeoffs.

The conventional framing treats the harness as the thing you configure. The composable provider model inverts this: instead of configuring the harness (which has limited knobs), you compose the world the harness sees. The harness reads ~/.claude/, resolves .mcp.json, walks the filesystem, shells out to whatever is on PATH. Every one of those is a provider-level seam. You do not touch the binary. You shape what it lands on.

This has a structural consequence. Since the harness only needs its resource contract satisfied, the provider is substitutable. A host OS, a container, a gVisor sandbox, a nix shell can all fill the role. Reverse engineering of the Claude Desktop application confirms that Anthropic themselves build synthetic resource providers: the Desktop sandbox uses gVisor with 9P filesystem passthrough, constructing a virtual filesystem from host paths, mounted volumes, and sandboxed scratch space1.

The credential (OAuth token or API key) is the one resource that cannot be synthesized or composed. It is the provider layer’s single invariant, the root of trust that Anthropic holds the other end of. Everything else is a projection you control.

With this model, the agent is not the harness. The agent is the recipe: a manifest specifying which CLAUDE.md (behavioral instructions), which .mcp.json (tool surface), which project files are visible, which binaries are on PATH, and which environment variables are set. Assemble that into a directory and launch claude into it. The harness boots, reads its environment, and becomes that agent.

The full analysis, including the attestation gap in Anthropic’s credential model, the legal boundaries of filesystem composition under the ToS, the distinction between recipe-level and orchestration-level composition, and why the CLI under API key billing becomes a composable SDK, is available as a standalone document:

Read the full document: The Composable Provider Model


References

  1. Kotrotsos, Marco. “Two Versions of Claude Desktop”, Medium, March 14, 2026. Decompilation and comparative analysis documenting the yukonSilver VM sandbox architecture.
  2. Claude Code: Legal and Compliance. Anthropic. Authentication and credential use restrictions.
  3. Claude Agent SDK Overview. Anthropic. The SDK as the CLI’s internals extracted as a library.

  1. Kotrotsos’s decompilation of Claude Desktop v1.1.4088 and v1.1.6452 revealed gVisor with 9P filesystem passthrough, minimal Linux boot images, and on-demand Ubuntu bundles. The harness cannot distinguish whether files came from a real partition or a 9P passthrough. ↩︎