Kimi Agent SDK

The deciding trait is that it reimplements nothing. The CLI stays the execution engine and these are thin clients on top, which means the behaviour you script is the behaviour you already tested by hand, and there is no second implementation drifting away from the first. That sounds dull and it is the reason to trust it.

It also means the CLI has to be there, so this is not a way into the ecosystem, it is a way to automate one you are already in. Pick it if that describes you. Pick a general framework if you are still deciding which agent your product should be built on.

The dependency is the whole design and it is not hidden. The runtime is one vendor's CLI, the model is that vendor's model, and there is no substitution recorded anywhere in the row. Code written against these SDKs is not portable in any sense that matters: not the tools, not the sessions, not the permission model.

That is a fair trade for a first-party SDK and an unfair surprise for anyone who reads framework and thinks abstraction. What it does right is refusing to pretend: nothing here is presented as vendor-neutral, and the row says so in three separate fields.

1. Moving approval from a terminal prompt into a callback is the change that makes an interactive agent programmable, because a decision a human makes by looking becomes a decision a program makes by policy. 2. Surfacing tool calls and approvals in the stream, rather than in a summary afterwards, means the policy sees them in time to act.

2. The design shifts the burden rather than removing it: an approval policy expressed in code is only as good as the code, and nothing offers a default worth inheriting. No evaluation accompanies any of this, and none is claimed, which for an interface specification is the correct pairing.

Read the publisher, not the repository. A model company shipping open clients is buying integration depth, because every custom tool somebody registers is switching cost they did not have to build. There is no free tier, which is the tell: the SDK is free and the inference is not.

Moat: the model, which is the only durable one in this category, and the SDK exists to deepen it. Likely path: continued investment while the model is competitive, and quiet neglect the moment it is not. Position: build on it if you have chosen that model on its merits, and never because the SDK was pleasant.

Three languages is the detail that decides adoption here, because the team that has to integrate this does not have to learn a fourth. It runs unattended, so it becomes a step in a pipeline rather than a habit on sixty desks, and a step in a pipeline is something I can measure and turn off.

What is absent is everything around it: no console, no single sign-on, no directory sync and no audit export, so whatever governance exists is governance we write. Approved with conditions: it lives inside a service the platform team owns, with a named owner for the service.

Reusing the runtime's existing configuration is the correct decision and almost nobody makes it. My MCP servers, my skills and my tool setup are already in that CLI, and the SDK addresses the same ones rather than asking me to declare everything again in a second dialect.

Apache-2.0 on the client is real and worth little on its own, because the engine it drives is the part I cannot replace. Registering my own tools is the one place I get to extend it, and that at least is code I own. Grudging respect for the client, and none available for the arrangement.