VeADK

The deciding trait is that the shape of an agent lives in a configuration file rather than in constructor arguments spread across a project. Provider, base URL and credentials sit in one place, so changing where inference happens is an edit somebody can review without reading the application, and handing the project to a colleague takes a minute.

That same file is the ceiling: anything the authors did not anticipate is not expressible there and drops you back into code. Pick it for conventional agents. Pick a library if yours is not.

Defaults concentrate testing. When the happy path points at one provider, that is where the bug reports come from, where the fixes land, and where behaviour is known; everything else is a configuration users are told is supported and few have tried. The gap shows up as quirks nobody has reported yet rather than as a documented limitation.

What it does right is not pretending otherwise. The provider is named in the configuration reference, so the default is visible rather than compiled in.

1. Introspection at runtime is an underrated property. Reading a repository tells you what should be mounted; querying the process tells you what is, and the two diverge as soon as configuration enters the picture. An endpoint that answers this makes drift detectable by a script rather than by an incident. 2. Health checks in the same layer let orchestration act on that information automatically.

2. No evaluation is published. The claims are structural, so the omission is consistent rather than evasive.

A hyperscaler's toolkit lives on a different clock than a startup's. It will not run out of money and it can be discontinued at any time without anyone losing a job, which trades one survival risk for another. The star count is small because the addressable audience is the parent's existing customers, not the open market, and that is the intended shape.

Moat: the cloud underneath it. Likely path: maintained while it supports inference revenue. Position: safe to use if you are already a customer, otherwise you are adopting somebody else's go-to-market.

The integration I have to review is the chat channel. Mapping conversation threads onto agent sessions means business content moves through a third-party messaging platform with its own jurisdiction and retention, and that is a legal review rather than an engineering decision.

Everything else is the usual library position: no seats to buy, no console, no directory integration, and whatever we build becomes a service my team operates and monitors. Approved with conditions: the messaging extension stays uninstalled until data residency is answered in writing.

An arbitrary base URL is the smallest possible escape hatch and it is the one that matters. My weights, my host, my network, and the kit stops caring where the tokens come from. That single field is the difference between a vendor toolkit and something I will actually install.

The licence keeps a fork legal and the extras let me skip the components I do not want. What is missing is MCP at either end, so the servers already running here need adapters, and I would rather have written none.