agentsdk-go

The deciding trait is that this is a dependency, not a tool. The shipped examples tell you the shape of the thing: a minimal request, an interactive shell, and a server speaking REST and SSE. That last one is the giveaway. Somebody built this because they needed an agent inside a backend they already operate, and Go is where their backend lives.

What you give up is everything a product gives you: no interface anyone designed, no defaults chosen for a stranger. Pick it when the agent belongs in your binary. Pick opencode when you want to type at one.

The structural problem is parity. The stated goal is to reproduce another product's runtime behaviour in Go, so the specification lives somewhere else and changes without notice. Every upstream revision becomes either a gap or a maintenance task, and nothing in the row records a compatibility statement, a version target, or a policy for what happens when the two diverge.

What it gets right is honesty about the mechanism. The interception points are declared as four named positions rather than an open plugin surface, so a reader can tell where their code will run.

1. Automatic compaction at a threshold is the single most consequential design decision here, because it determines what the model can still see after a long session, and it is described without a stated rule for selection or retention. 2. Binding a model per subagent through a factory interface is principled: capability and cost become properties of a role rather than of the whole process.

2. No evaluation is published, and none is claimed, so nothing is overstated. The compaction policy is the part a careful reader should measure before trusting a long-running session.

There is no company story here, only a library. A hundred and fifty stars measures curiosity, not adoption, and a permissive SDK with no service attached has no price to raise and no customer to lose. Ownership sits with one small vendor whose incentive to keep publishing is not visible from the outside.

Moat: none, and the design forecloses one, since the value proposition is compatibility with somebody else. Likely acquirer: nobody buys this; a Go shop hires the author. Position: adopt the code, do not adopt the vendor.

Tracing is the reason I am still reading. Spans go to the collector we already run and each request carries an identifier, so an incident becomes searchable instead of anecdotal. It runs headless, which means it can sit in a pipeline stage and be measured like every other stage.

What is missing is identity. No single sign-on, no directory sync, no console, so access control is whatever the service embedding it enforces. Across sixty engineers there is no licence to buy and no seat to count, only the model bill. Approved with conditions: it ships inside a service my team owns.

The rules directory is the detail that won me over. Drop a file in, it reloads, the agent behaves differently, and nothing had to be rebuilt or redeployed. That turns steering from a code change into an edit, which is how it should have worked everywhere. The licence is permissive, so the fork question answers itself, and I can point it at servers I already run.

The gap is local weights, which the row says are absent. Everything else I can bend. That one I cannot, and it is the one I care about most.