DotCraft: An Embeddable .NET Agent Runtime With a Plugin Model It Can Write Itself
The agent harness for .NET: embeddable, extensible, and ready to use out of the box
At a glance
- What is it?
- DotCraft ships a desktop app, a NuGet harness package and a TypeScript SDK around one agent runtime. The interesting claim is that the agent can author .NET plugins in the workspace using the same extension model as the built-in features, and that those plugins can be swapped while the host keeps running.
- Who is it for?
- Adopt DotCraft if you are a .NET team that wants an agent runtime inside an existing service or tool rather than a separate product to integrate over HTTP, and if you accept that the harness surface is still moving at a v0.6.x release cadence. Do not adopt it if you need a stable plugin ABI across versions or you work outside the .NET and TypeScript ecosystems.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem DotCraft Targets: Agent Infrastructure You Have to Assemble Yourself
Most teams building an agent into a .NET product end up writing the same scaffolding: a planner loop, a tool registry, a conversation store, a way to attach skills, and some mechanism for the model to call back into application code. DotCraft's README frames that as the problem it removes, listing Plan, Agent Builder, Agent Profiles, Subagents, Automations, Goals, Dreams and Dynamic Workflows as built-in capabilities so that, in its words, "you do not have to assemble agent infrastructure from scratch."
The audience is narrower than the feature list suggests. The README offers three entry points: DotCraft Desktop, DotCraft.Harness for embedding in .NET applications, and a TypeScript/React plugin path for extending the desktop UI. The npm badge points at the @dotcraft/sdk scope. So the realistic adopter is a C# developer who already has a service or internal tool and wants an agent inside it, or a team that wants a self-hosted desktop agent with a workspace-local plugin story. Someone who only wants a chat interface gains little from the harness package.
The workspace-as-container idea is the part worth noting. Conversations, memory, agents, skills and plugins live with the project folder, so the README claims you can move between Desktop, the CLI, editors and bots and resume where you left off. That is a design choice about state location, not a feature bullet, and it shapes backup, version control and multi-user behaviour later on.
How the Runtime Is Layered: One Core, Three Surfaces
The README describes a single runtime with several ways in. DotCraft Desktop is presented as the reference client. DotCraft.Harness is the NuGet package that puts the same runtime inside a .NET application. AppServer plus SDKs plus App Binding is the path for products that are not written in .NET and want to talk to the runtime rather than link against it. Oratorio adds a task board that moves work from assignment to review, and Satellite lets agents operate in an approved shared folder on another machine.
That layering is the architectural claim: the desktop app is a client of the runtime, not the runtime itself. If it holds, an embedded harness and the desktop app should behave the same way for the same workspace, which is a testable proposition rather than a marketing line.
The plugin model is where the design gets specific. .NET plugins, authored in the workspace, use the same extension model as built-in features and can contribute tools, prompts, commands and lifecycle logic. The README states they "can be replaced while the host keeps running." TypeScript and React plugins are a separate track: they extend the Desktop interface using native UI components, so they are not the same artefact as a .NET plugin and do not share its lifecycle.
One cost-control detail is stated concretely enough to be worth repeating: DotCraft keeps reusable prompt prefixes byte-stable to improve provider cache reuse. That is a real constraint on how you compose prompts, because any byte that changes at the front of a prefix invalidates the cached portion.
Installing DotCraft: Desktop Download, Shell Installer, or NuGet Package
The desktop route is manual. Download the latest build from GitHub Releases, open a real project folder as the workspace, then configure model providers and preferences. There is no package manager step described.
The CLI route is a shell installer. On macOS and Linux the README gives:
curl -fsSL https://www.dotcraft.net/install.sh | bash
On Windows PowerShell:
irm https://www.dotcraft.net/install.ps1 | iex
Both pipe a remote script into a shell, which means you are trusting whatever the server returns at the moment you run it. If that matters in your environment, fetch the script first and read it before executing. The README points to the Getting Started page for the complete guide rather than documenting flags inline.
The embedding route is the NuGet package DotCraft.Harness, and the README does not show a registration snippet, a builder extension or a configuration example for it. That is a gap. Before you plan an integration you need to read the harness documentation page to learn the actual entry point, because nothing in the README tells you whether the harness is configured through dependency injection, a builder call, or a settings file. The same applies to the SDK: the npm badge confirms a @dotcraft/sdk package exists, but the README gives no installation command or usage example for it.
Model providers are OpenAI and Anthropic protocols, or a ChatGPT subscription sign-in. The README does not describe how credentials are stored or whether a local model server speaking the OpenAI protocol is supported.
The Plugin Hot-Swap Claim Is the Most Interesting and Least Documented Part
The README says the agent can be asked to create and build a .NET plugin in the workspace, that this uses the same extension model as built-in features, and that plugins "can be replaced while the host keeps running." Read together, those three statements describe something more than a plugin folder: a build-and-reload cycle where the agent writes C#, compiles it, and the running host picks up the new assembly.
That is a strong claim and the README does not support it with detail. It does not say what happens to in-flight work when a plugin is replaced, whether the old assembly is unloaded from the default load context, or whether replacement requires an explicit unload call. .NET assembly unloading is not automatic for types loaded into the default context, so the mechanism matters. Without a collectible AssemblyLoadContext or a separate process, repeated plugin swaps accumulate loaded assemblies, and file locks on Windows can block overwriting the plugin DLL at all.
None of that is confirmed either way by the material available. Treat it as the first thing to verify against the documentation, not as a settled property. If hot-swap turns out to require a host restart in practice, the extension model is still useful, but the agent-writes-its-own-tools loop becomes a development-time workflow rather than a runtime one.
Where DotCraft Is the Wrong Choice
The release history is the clearest constraint. v0.6.2, v0.6.3 and v0.6.4 landed within four days of each other in September 2026. That is a project moving quickly, and quick movement in a runtime that loads third-party code means the plugin contract can shift between patch releases. If your integration depends on a stable extension interface, you are betting on a surface that the version numbers do not promise to hold still.
There is also an ecosystem boundary. The plugin story is .NET and TypeScript. A Python or Go team gets the AppServer and SDK path, which is a different relationship: you talk to the runtime over a boundary instead of hosting it in-process, and you inherit the operational work of running a separate service.
Finally, the README is a product page more than an engineering document. It names capabilities without stating their contracts. There is no mention of a sandbox for plugin code, no statement about what a plugin can reach on the host, and no discussion of what happens when an agent-authored plugin fails to compile or throws at load. For a system whose selling point is that the agent extends its own runtime, the absence of any safety discussion in the README is a real gap, not a formatting oversight.
How DotCraft Differs From a Framework Like Microsoft Agent Framework
DotCraft's own credits list microsoft/agent-framework among its inspirations, which makes the comparison fair rather than adversarial. The difference is in what ships in the box. A framework gives you abstractions and expects you to compose an application: you wire the model client, define tools, decide where conversation state lives, and build the surface your users touch. DotCraft starts from a finished runtime with a desktop client, a task board, a remote-folder mode and a workspace layout already decided.
That inverts the trade. With a framework you control the shape and pay in assembly time. With DotCraft you get the shape and pay in fit: if your product needs a different conversation model, a different permission boundary, or a different UI, you are working around decisions rather than making them. The plugin model softens this for tools, prompts, commands and lifecycle logic, and the TypeScript plugin path softens it for the desktop interface. It does not soften it for the core loop.
The prompt-prefix stability point is a concrete example of a decision you inherit. If you build your own prompt assembly on top of a framework, cache reuse is your problem to solve. DotCraft states it handles prefix stability for you, which is useful, but it also means your prompt construction has to respect that constraint rather than being free-form.
Licence, Maintenance and Upgrade Cost
DotCraft is Apache-2.0. That is a permissive licence with an explicit patent grant and a requirement to preserve notices and state changes. It does not impose copyleft on your application, so embedding DotCraft.Harness in a closed-source product is not blocked by the licence itself. This is a description of the licence text, not legal advice; if you are redistributing modified sources or bundling the runtime, have counsel read the NOTICE and modification clauses rather than relying on a summary.
The maintenance picture is a project that publishes frequently. Three releases in the four days before this writing, with the most recent push to main on 2026-09-10. Frequent releases are good for fixes and bad for pinning. If you embed the harness, pin an exact package version in your project file rather than floating a range, and read the release notes for each bump before taking it, because the plugin contract is the part most likely to move.
Upgrade cost depends on which surface you use. A desktop install is a download. A CLI install is re-running the installer script, which fetches whatever is current. An embedded harness is a normal NuGet version bump plus whatever migration the plugin API requires. The README does not describe a deprecation policy or a compatibility guarantee, so plan on reading release notes rather than assuming patch releases are inert.
Editorial conclusion
Adopt DotCraft if you are a .NET team that wants an agent runtime inside an existing service or tool rather than a separate product to integrate over HTTP, and if you accept that the harness surface is still moving at a v0.6.x release cadence. Do not adopt it if you need a stable plugin ABI across versions or you work outside the .NET and TypeScript ecosystems. Before committing, check the NuGet page for DotCraft.Harness to see which target frameworks the current package actually lists, and confirm on the documentation site whether a plugin hot-swap requires an explicit unload call or happens on its own.
Community notes