DotCraft

The deciding trait is the language. If your services, your tooling and your hiring are all .NET, an agent runtime written in the same language changes what is possible for you in a way no feature list conveys. You get types, your own build, and code review by people who already know the codebase.

If you are not a .NET shop, none of that applies and you are choosing a smaller ecosystem for no reason. Pick it when C# is the language your team defends in meetings. Pick a Python framework when the examples you will copy from are all written in Python anyway.

Reuse across sessions is the risky word. A cache hit is only free when the reused prefix is still correct, and a session boundary is exactly where correctness tends to change. Nothing in the row describes invalidation, so the mechanism optimises for hits rather than for freshness.

The symptom is not an error. It is an answer that is confidently about the shape the project had last week, delivered faster and cheaper than a correct one. What it does right is naming the mechanism instead of calling it memory, so a user who reads carefully can at least know what to distrust.

1. Binding state to the project rather than to the client is the correct choice, and it has a testable consequence: a session started in one entry point is legible from another, which makes the runtime a shared substrate instead of three products with a family resemblance.

2. The unit of backup becomes obvious as a side effect.

3. What is not specified is the format or the concurrency model: two entry points addressing one project's state at once is the obvious question, and the documentation does not raise it. No evaluation accompanies the design, and none is claimed.

The market is the interesting part. Enterprise .NET is a real budget and it is also the home turf of the company that ships the language, the editor and the cloud, which means any independent runtime here is building on a field the landlord can plant on. There is no revenue line, no hosted tier and no funding visible.

Moat: none against that landlord, and some against everyone else, because nobody else wants this audience. Likely path: a support-and-hosting business, or absorption once the platform vendor ships an equivalent. Position: use it, and read the release notes of the company that owns the ground it stands on.

Read the deployment before the features. An AppServer we host is an internal service: a machine, a patch cycle, a backup policy and someone on call. In exchange sixty engineers pay no licence fee, and the model spend lands on keys we already reconcile.

For a shared service the access question is not optional, and there is no single sign-on, no directory sync and no audit export in the row. Nothing runs unattended either, so it reports no number into anything I read. Approved with conditions: one instance behind our identity proxy, owned by the platform team, with a named service owner.

Building on the official protocol SDK rather than a hand-rolled client is the detail that tells me somebody intends to keep up. Any endpoint speaking either major protocol works, which covers a local server without the project having to bless a particular runtime by name.

Apache-2.0 keeps the fork honest, and signing in with a ChatGPT subscription instead of a key is a nice option to have. My grumble is that a runtime this configurable exposes nothing back over the protocol, so other agents cannot reach into it. Grudging respect, one interface short.