Konstantin Semenenko
July 30, 2026
4
minutes read
Most AI agent orchestration assumes the cloud: a hosted control plane, your code leaving your machine, a subscription. Local-first inverts that. The agents, workflows, and state all run on your own device, connecting to whatever provider you choose (Codex, Claude Code, Copilot, Gemini) or to fully local models, with nothing leaving the machine. This matters for privacy, cost, and control, and it is now practical on .NET: our open-source dotPilot runs multiple agents locally on Microsoft Agent Framework, with sequential, parallel, and handoff workflows, SQLite persistence, and OpenTelemetry tracing, no cloud required.
Running AI coding agents usually means sending your work to someone else's infrastructure. The agent runs in a hosted environment, your code and context travel to a cloud control plane, and you pay a subscription for the privilege. Local-first orchestration is the opposite arrangement: the orchestration layer, the agents, the workflows, and the state, runs on your own machine, and it connects out to model providers only for the inference itself, or not at all if you run local models. Your code stays where it is. This is not a niche preference; for anyone working with sensitive code, watching token costs, or wanting control over their tooling, it is the more sensible default, and it has become genuinely practical on .NET in 2026. We built an open-source tool for exactly this, dotPilot, so this explains the pattern using it as the worked example.
Disclosure: dotPilot is our open-source project, so we use it as the concrete example. The pattern generalizes; the tool is one implementation of it.
The phrase is worth pinning down, because "local" can mean several things and the distinction matters. Local-first orchestration means the control plane runs on your machine: the thing that launches agents, coordinates them, holds their state, and runs the workflows is a desktop application, not a hosted service. That is separate from where inference happens. You can still connect a local-first orchestrator to cloud providers (Codex CLI, Claude Code, GitHub Copilot, Gemini, OpenAI, Azure OpenAI) for the model calls, or you can run fully local models (through LLamaSharp or ONNX Runtime) and have nothing leave the machine at all.
So there are two independent axes: where the orchestration lives, and where the inference lives. Local-first fixes the first (orchestration on your device) and leaves the second to you. The practical upshot is that even when you use a cloud model, the orchestration, your agent definitions, your workflows, your history, stays private and under your control, and if you need full isolation, you can close the second axis too by running local models. That flexibility is the point: you decide per use case how much leaves the machine, rather than a hosted platform deciding for you.
The case for local-first rests on three concrete advantages, and each answers a real problem with cloud orchestration:
None of these require giving up capability. You get multi-agent orchestration, workflows, and observability, just running on your machine instead of someone else's.
To make this concrete, here is how our implementation is built, since the architecture shows what local-first orchestration requires. dotPilot is a desktop application (C# and .NET 10 on the Uno Platform, so it runs on macOS, Windows, and Linux) with an orchestration engine built on Microsoft Agent Framework, the current Microsoft stack we cover in building AI agents in .NET. That choice matters: Agent Framework provides the sequential, parallel, and handoff workflow patterns, with streaming and checkpoints, so the local orchestrator gets production-grade coordination rather than a hand-rolled loop.
The rest of the architecture follows from "local-first." State persists in SQLite on the machine, so your agents, workflows, and history live in a local file, not a cloud database. Providers are adapters: Codex CLI, Claude Code, GitHub Copilot, and Gemini through their SDKs, plus LLamaSharp and ONNX Runtime for fully local models, so the same orchestrator drives cloud or local inference interchangeably. Observability is built in through OpenTelemetry, tracing every agent action, tool call, and workflow step, with a fleet board for real-time monitoring, which is what turns "several agents running" into something you can actually see and debug, the discipline in AI agent observability. And agents can be created from natural language: describe what you need, and it generates the agent profile, prompts, and tool configuration. It is open source under MIT, so the architecture is inspectable rather than a black box.
Local-first orchestration is not always the answer, so it is worth being clear about the fit:
The honest summary: local-first orchestration trades the convenience of a managed service for privacy, cost control, and flexibility, and for a large class of developers and teams, especially those handling sensitive code, that trade is clearly worth it.
Local-first AI agent orchestration runs the control plane, the agents, the workflows, and the state, on your own machine, connecting out to model providers for inference or running fully local models so nothing leaves the device at all. It answers the real problems with cloud orchestration: it keeps sensitive code private, removes the orchestration-as-a-service cost layer, and avoids vendor lock-in by making providers pluggable. It is now practical on .NET: our open-source dotPilot runs multiple agents on Microsoft Agent Framework with sequential, parallel, and handoff workflows, SQLite persistence, OpenTelemetry tracing, and adapters for Codex, Claude Code, Copilot, Gemini, and local models, on macOS, Windows, and Linux. It is not a universal replacement for hosted platforms, but for anyone whose code sensitivity, cost, or need for control argues against the cloud, local-first is the better default.
dotPilot is free and open source, part of our open-source work. If you want local-first agent orchestration built into your own .NET systems, that is worth a conversation. Book a 15-minute call.
What is local-first AI agent orchestration? Running the orchestration layer, the part that launches agents, coordinates them, runs workflows, and holds state, on your own machine as a desktop application rather than in a hosted cloud service. It connects out to model providers for inference, or runs fully local models, but the orchestration and your data stay on your device.
Can I run AI coding agents without the cloud? Yes. A local-first orchestrator runs on your machine, and if you use local models (through LLamaSharp or ONNX Runtime) rather than cloud providers, the entire system runs with no network dependency at all. dotPilot, our open-source tool, is built for exactly this and works offline with local models.
Does local-first mean I can't use Claude or GPT? No. Local-first refers to where the orchestration runs, not where inference happens. You can connect a local-first orchestrator to cloud providers like Claude Code, Codex, GitHub Copilot, or Gemini for the model calls while keeping the orchestration and your code on your machine, or switch to local models when you need full isolation.
What is dotPilot? Our free, open-source (MIT) desktop application for running multiple AI agents locally. It is built with C# and .NET 10 on the Uno Platform, orchestrates agents with Microsoft Agent Framework (sequential, parallel, and handoff workflows), persists state in SQLite, traces with OpenTelemetry, and connects to Codex, Claude Code, Copilot, Gemini, and local models, on macOS, Windows, and Linux.
When should I use local orchestration instead of a cloud platform? When your code is sensitive or regulated and should not go to a hosted platform, when you want to cut the orchestration-as-a-service cost layer, when you want to mix or switch providers freely, or when you need offline or air-gapped operation. A hosted platform may fit better if you want zero setup and managed team-wide infrastructure and your code and cost profile do not argue for local.
