An Agent SDK Is a Harness You Didn't Build
What a framework makes easy, and what it hides.
An Agent SDK is a packaged harness: the run loop, tool interface, memory, model abstraction, and tracing, ready to wire together. The value is what it makes easy. The risk is what it hides.
To build a car you do not forge your own engine, chassis, wheels, and wiring from scratch. You start from a platform that provides the frame and the plumbing, and you add the parts that make the car yours. An Agent SDK is that platform for building an agent: it hands you the loop, the tool wiring, the memory, and the retries, so you bring the model and your logic and skip rebuilding the frame every time.
Every agent needs the same plumbing: a loop that calls the model and runs tools, a way to register and validate those tools, somewhere to keep state, a way to swap models, and enough tracing to debug what happened. You can hand-roll all of it, and doing so once is a good way to learn where the hard parts are. Or you can reach for an Agent SDK, which is really just that plumbing, packaged.
An Agent SDK is a harness you did not have to build. It gives you the primitives so you wire them together instead of writing each one from scratch.
The value is real. You are not reinventing the run loop, retry handling, tool schema validation, or tracing for the hundredth time, and the primitives have usually been hardened by more use than your first attempt will get. For most teams, starting from an SDK is the right call.
Here is the split, part by part, between what the SDK hands you and what stays yours:
Calls the model, runs the tool it asked for, feeds the result back, and decides when to stop.
The risk is equally real, and it is a single idea: what the SDK makes easy is obvious, but what it hides is what hurts you later. If the framework hides the loop, you cannot control termination or budgets when a run goes sideways, which is exactly the moment you need that control. If it assumes one way to assemble context, you are stuck with it. And if it hard-wires a single model provider, you have quietly taken on lock-in to the one component you most want to keep replaceable.
That last one is worth its own picture, because the model is a dependency and a good SDK treats it like one.
So the way I judge an Agent SDK is not by its feature list but by what it lets me keep control of:
- Is the model swappable? The model should sit behind an adapter, so I can adopt a better one without rewriting the agent.
- Can I see and control the loop? Termination, budgets, and retries should be configurable, not buried.
- Is policy at the tool boundary? What the agent may do should be enforceable where the action happens, not left to the prompt.
- Can I drop to the primitives? The easy path should be easy and the hard path should still be possible. A framework that only supports the demo is a trap.
Two more things do not come from the SDK, no matter how good it is. It does not make your guardrails, your verification, or your budgets for you; those are decisions you still own. And it does not free you from understanding the harness. The parts of my own work that plug into any SDK make this concrete: openapi-mcp derives an agent's tool surface from an approved API specification, so the tools stay tied to a real contract, and ToolContractGate governs tool calls at runtime regardless of which framework issued them. An SDK can host both. It cannot decide that you need them.
An Agent SDK is scaffolding for your harness, not a substitute for thinking about it. Pick one that keeps the model replaceable and the control visible, use it to skip the boilerplate, and keep owning the decisions that make the agent trustworthy.
