Clarion Street

One Deployment, Many Agents: The Rise of Per-Run Configuration

·7 min read

For the past two years the running question on this site about agent infrastructure was which layer wins, the harness, the control plane, or the sandbox. In about a month, three vendors shipped a feature that changes the question. OpenAI introduced the Agents API on September 10. LangChain shipped Managed Deep Agents v0.9 in early October. Google’s Flutter team announced Genkit Dart 1.0 on October 8. All three, from different positions in the stack, let one deployment become a different agent on each run.

That is the pattern worth watching, and it is narrower than the harness-is-the-product thesis this site has already covered more than once. Per-run configuration means the model, the tools, the skills, and in some cases the sandbox are selected at invocation time, not baked into a release. The deployment stops being an agent. It becomes a template, and a different agent comes out of it on each run. Which one it is, right now, is something you can only answer for this run.

Three vendors, same idea

OpenAI’s Agents API is the most complete version of the three. It exposes the Codex harness and its infrastructure as a managed API. A developer creates an agent in a single call by naming the task, the model, the tools, and the environment. OpenAI runs the harness; the developer picks the compute environment, an OpenAI-hosted sandbox, their own infrastructure, or one of nine partners, Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, and Vercel. There is no added fee for the API itself. You pay for the tokens and the tools your agents call. The hosted sandbox runs the same isolation that powers Codex and ChatGPT, and it is configured per run with files, packages, skills, and plugins.

LangChain’s version is a function. In Managed Deep Agents v0.9 the agent is a callable that receives the runtime at the start of each run and returns a define_deep_agent definition choosing the model, instructions, skills, MCP servers, and, per the announcement, the sandbox. Because the config is set before the model runs, the model never sees skills or tools outside that config. LangChain states it plainly: per-run config “keeps its context small, doubles as access control, and lets you pick the model itself, which the model can’t do.” The announcement’s example is a single coding agent that loads a gpt-5 model and Python skills for a payments-service repo, and a gpt-5-mini model and TypeScript skills for a storefront, picked by the run’s context.

Genkit Dart 1.0 is the version you assemble yourself. It is a stable open-source framework with a unified API across Gemini, Claude, OpenAI, and OpenAI-compatible models, and its middleware can attach per-call behavior, retries, dynamic SKILL.md loading, and tool-approval rules to a single generate call. There is no managed harness and no sandbox marketplace behind it. The same per-invocation configurability, expressed as code you own.

The mechanisms differ. OpenAI takes a per-call environment spec, LangChain takes a function that returns a definition, and Genkit takes middleware. The pattern underneath is the same: what an agent is has become a property of the run rather than the deployment.

The security boundary moves

I think the change here is bigger than it first looks. For a static agent you answer “what is this agent, and what may it do” once, at review time. Per-run config breaks that. The thing you are securing is no longer a service with a fixed permission set. It is a configuration that changes every invocation, and that configuration is now the thing that has to be reviewed and logged.

LangChain is explicit that the config doubles as access control because the model never sees tools outside its per-run definition. That is a real property and a useful one, but it cuts both ways. If the definition is decided by code at the start of each run, then the access-control boundary is also decided by code at the start of each run. You can no longer read the deployment and know what it can touch. You have to read the run.

This lands on a story the site has tracked for a while. When I wrote about kernel-level sandboxing, the assumption was a sandbox you pick once and wrap around a deployment. The April 15 update to OpenAI’s Agents SDK had already split the runtime in two, with the control harness staying with OpenAI and the compute plane becoming a separate vendor contract. The Agents API turns that split into a per-run choice. The managed-versus-self-hosted question I covered with AX and the agent substrate and NVIDIA and Red Hat’s secure runtimes now gets asked per invocation, not once per architecture. OpenAI’s own self-hosted docs warn that agents sharing an environment “can access the same files, credentials, and other resources,” which is the vendor telling you directly that isolation has to be a provisioning decision you make per run, not a property you inherit from the deployment.

Observability has to chase the run

The observability consequence follows from the same fact. If one deployment is N agents, you cannot reconstruct what happened from the deployment name. The name tells you the template. You need the run’s config and the run itself, captured together, and the vendors are already building that telemetry. The Agents API streams session events and publishes outputs as immutable artifacts. Genkit exports OpenTelemetry GenAI traces. It is more than you usually get: the observability for the per-run world is shipping at the same time as the per-run feature.

The sharp edges

None of this is settled. All three announcements are vendor-authored, and two of the products are in public beta. The Agents API’s hosted sandbox expires after roughly an hour of idle time and that timeout is not configurable, which a buyer will hit the first time a long-running agent goes quiet. Hosted stdio MCP servers currently require fully enabled network access, another edge that reads fine in a release note and less fine in an enterprise security review.

There is also an inconsistency in LangChain’s own material. The v0.9 announcement lists the sandbox among what the per-run definition returns. The reference docs describe the sandbox, along with skills, memory, and identity, as configured through project files rather than the agent definition. I could not resolve which is authoritative, so I would not yet claim that sandbox selection is fully per-run in LangChain the way it is in the Agents API. Model and tool selection are unambiguous. The sandbox is murkier.

Genkit is a different animal too. It is a framework, not a managed sandbox or a managed harness. It proves the idea has legs at the do-it-yourself layer, but it does not hand you the procurement questions the other two do. Treating the three as the same thing overstates the case.

The standing caveat from the harness thesis applies here as well. Per-run config matters most for genuinely agentic deployments, where the model is choosing tools and how much model you need. A workflow-style bot with a fixed path does not need per-run model and sandbox selection, and the overhead may not be worth it. I do not think this is the next thing everyone adopts. I think it is the next thing the agent-heavy end of the market adopts, and everyone else watches.

What would convince me this is real rather than three vendors converging on the same release note: a production deployment running a dozen distinct per-run configs behind one endpoint, with the per-run config captured as part of the audit trail and a security reviewer accepting that capture. That is the test the pattern has to pass, and none of the three announcements gets there on its own.

Sources

  1. Introducing the Agents API — OpenAI, September 10, 2026
  2. Managed Deep Agents v0.9: schedules, per-run configuration, and Slack reactions — LangChain
  3. Announcing Genkit Dart 1.0 — Flutter/Dart, October 8, 2026
  4. Agents API: OpenAI-hosted sandboxes — OpenAI
  5. Agents API: Self-hosted sandboxes — OpenAI
  6. Define a Managed Deep Agent — LangChain
  7. OpenAI’s BYO-Sandbox Launch Splits Agent Runtime Into a Two-Vendor Procurement Problem — AgentMarketCap, April 16, 2026