Claude Agent SDK, OpenAI Agents SDK or Google ADK: four questions to ask the client before you choose

The OpenAI Agents SDK documentation says tracing is on by default. The same documentation also says that organisations using the OpenAI API under a Zero Data Retention policy cannot use tracing. One clause in a client’s contract is enough to remove a default feature.

That detail shows how agent SDKs actually get chosen on real projects. Nobody picks one from a scorecard. The constraints the client states narrow the list step by step. Those constraints often come up in the first working session, and usually before anyone has opened an editor.

For an FDE, this is a skill worth paying for. Pick the wrong framework in week one and by week six you are rewriting the observability layer, the permissions layer and sometimes the model-calling layer as well. What follows are four questions that rule options in or out among Claude Agent SDK, OpenAI Agents SDK and Google ADK, along with the pitfalls of each.

Where will the agent run, and who operates it?

Ask this first, because the answer decides who is on call when the system breaks. According to Anthropic’s documentation, Claude Agent SDK takes the agent loop, toolset and context management that run inside Claude Code and packages them as Python and TypeScript libraries.

The agent is embedded in your application and runs in a process you operate. OpenAI Agents SDK is also a Python library installed with pip that runs in your process. It also offers sandbox agents, which run tasks in an isolated workspace.

If the client doesn’t want to operate anything, Anthropic sells a separate product called Managed Agents. It is a hosted harness that runs the agent loop. Sessions live either in a cloud sandbox managed by Anthropic or in a self-hosted sandbox on the client’s infrastructure.

Keep the two products clearly apart when you talk to the client. Mixing them up is the quickest way to make a false promise about where the data lives.

Google ADK is open source and built to deploy anywhere. You can containerise it and run it on your own infrastructure, or deploy it to Google Cloud with a single command. So all three can run on infrastructure the project team controls. Where they differ is language support.

Picture a bank that allows software to run only in its own data centre and whose in-house team writes Java. ADK ships in Python, TypeScript, Go, Java and Kotlin, so it belongs at the top of the list.

Claude Agent SDK offers only Python and TypeScript libraries. For other languages, Anthropic’s documentation suggests running the Claude Code CLI as a subprocess and reading its JSON output. That works, but the client’s team then has one more integration layer to maintain.

Has the client chosen a model, or do they want the option to switch?

Many clients already have a contract with a model provider. Others want to keep open the option of switching later. These two groups need different advice.

OpenAI Agents SDK supports non-OpenAI models through Any-LLM and LiteLLM, but the documentation labels both integrations as beta, with best-effort support only.

If the client runs a different model, you have to verify that provider yourself on the project’s actual workflows before you commit to anything. ADK, by contrast, describes itself as working with almost any generative model, not just Gemini, through adapters for each provider.

Claude Agent SDK is built around Claude Code’s own agent. It is best treated as the option for clients who have already settled on Claude, not as a layer for swapping models back and forth. The advice is simple. If the client says they “aren’t sure which model yet”, don’t pick an SDK because your team likes it and then hope the adapters hold up.

Who has the power to block a dangerous action?

An agent that can call tools can do real things: write files, call APIs, change data. So the client’s security team will ask what stops it from doing the wrong thing. Anthropic’s documentation answers that very precisely.

According to Anthropic’s permissions documentation, every tool call is evaluated in this exact order: hooks, deny rules, ask rules, permission mode, allow rules, then the canUseTool callback. Hooks run before everything else.

A deny hook still applies even when the agent is in bypassPermissions mode. For headless agents, Anthropic recommends combining allowedTools with permissionMode “dontAsk” to lock down the set of permitted tools.

OpenAI Agents SDK aims to be minimal. It has only a few primitives: agents, handoffs (one agent passing work to another), guardrails and built-in tracing. The trap is in the guardrails. Input guardrails run only on the first agent in a chain, and output guardrails run only on the last.

Picture a three-agent chain for customer service in which the middle agent can issue refunds. If you put your checks in an input guardrail and assume they cover the whole chain, the middle agent is never checked at all.

The fix is to put the check on the refund tool itself. The SDK provides tool guardrails for exactly this. According to the documentation, they run on every call to a function tool that has a guardrail attached, checking input before the tool runs and output after it runs.

Spell this out in the design document you send the client. Their security team will ask exactly that question, and you should have the answer ready before they do.

Who reads the traces, and how is quality measured?

The fourth question is often left until month two, when the client asks why the agent gave a wrong answer last Tuesday. Each SDK answers it differently.

OpenAI Agents SDK has built-in tracing, on by default, which makes debugging easy. But as noted at the start, clients under a Zero Data Retention policy don’t get this feature. For them, you have to build your own observability layer from day one.

According to Google Cloud’s documentation, ADK has built-in evaluation tools, plus partner tools, for checking an agent’s execution trajectory. That means checking which steps the agent took, not only whether the final answer was right.

For clients who must prove the agent followed the correct process, such as an application-approval workflow, that is a real advantage.

Claude Agent SDK has hooks for running code at key points in the agent lifecycle, along with sessions, subagents and MCP. Hooks are the natural place to attach observability.

One approach with Claude Agent SDK is to use a hook that logs every tool call into the client’s logging system, then build a test suite on that data. It takes effort to set up, but the data stays entirely in the client’s hands.

Four questions, three answers

Each vendor’s documentation covers only its own product. Only when you put their answers side by side under the same questions do you see where each is strong and where you need to ask more.

Question for the client	Claude Agent SDK	OpenAI Agents SDK	Google ADK
Where does the agent run, who operates it?	Python/TypeScript library in a process the project team operates; use Managed Agents if hosting is wanted	Python library running in the project team’s process, plus sandbox agents	Open source, with Go and Java versions; containerised on own infrastructure or Google Cloud
Which model, can it be switched?	Built around Claude Code’s agent	Non-OpenAI models via beta adapters, best-effort	Works with almost any generative model
Who blocks dangerous actions?	Hooks run before every step; deny hooks apply even in bypassPermissions	Input guardrails only on the first agent, output only on the last; tool guardrails run on every call to a tool they are attached to	The overview documentation does not describe a tool-blocking mechanism; test it on the client’s own workflows before committing
Who reads traces, how is quality measured?	Hooks run code at key points and can log every tool call	Tracing on by default, but unavailable under Zero Data Retention	Built-in eval tools for execution trajectories

The table does not name a winner. It shows which question rules out which SDK. If a client is under Zero Data Retention and still needs observability, OpenAI Agents SDK needs a second look.

If the client needs Go or Java, ADK has a clear edge, while Claude Agent SDK can only be used indirectly by calling the CLI. If the client has already chosen Claude and has a demanding security team, Anthropic’s ordered permission model is the thing to present.

What to practise next

According to one tutorial, building a demo and stopping there is the least useful way to learn agents for FDE work.

The most effective practice is to build the same agent on two SDKs and then deliberately break it: let a dangerous tool slip past a guardrail, turn off tracing, switch to a different model.

When you read job descriptions, watch for phrases like “on-prem”, “data residency”, “Zero Data Retention”, “GCP” or “Java”. Those are the constraints that will decide which SDK gets picked.

On your CV, instead of writing “experience with LangChain and agent frameworks”, write a line such as: “selected the SDK for a document-processing agent based on data-retention requirements and control over tool-call permissions”.

That line shows you have sat down with a real client.

The frameworks will keep changing with every release. The four questions will change far less, and the FDEs who ask them before writing code tend to be the ones who rewrite the least.