Claude Agent SDK vs Google ADK

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Claude Agent SDK
   Claude Agent SDK✓fullprobed9/10

   Probes confirm the product ships an official llms.txt at code.claude.com/llms.txt (HTTP 200) and markdown-formatted agent-oriented docs (e.g., overview.md) with an explicit documentation index pointer for agents to fetch, directly enabling an AI-native user to point an agent at these resources. Missing for 10: independent third-party confirmation that agents successfully consume this llms.txt in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://code.claude.com/llms.txt # Claude Code Docs > Official documentation for Claude Code, Anthropic's agent…”
   • [probe] “PROBE docs-md: HTTP 200 at https://code.claude.com/docs/en/agent-sdk/overview.md > ## Documentation Index > Fetch the complete documentation…”
   • [probe] “official CLI documented at https://code.claude.com/docs/en/cli-reference”

   proof ↗⚑ flag

   Google ADK!disputedcontradicted3/10

   Docs claim 'AI-aware developer resources' and coding-assistant integration (google-adk-docs-9), suggesting agent-oriented documentation exists, but direct probes for llms.txt and markdown-rendered docs both return 404 (google-adk-probe-1, google-adk-probe-2), and no OpenAPI/machine-readable spec is discoverable (google-adk-probe-3), contradicting the claim that an agent can straightforwardly consume these docs. Missing for 10: a working llms.txt or agent-readable doc endpoint, confirmation that the 'AI-aware resources' are actually machine-fetchable rather than just a marketing phrase.

   • [claimed-docs] “ADK is designed to be written by both humans and AI. Connect your favorite coding assistant to our ADK developer Skills and AI-aware develop…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://google.github.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://google.github.io/adk-docs/get-started/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://google.github.io/openapi.json, https://google.github.io/swagger.json, https://google.github.…”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round drawn
   Claude Agent SDK✓fullcommunity8/10

   Docs describe headless/non-interactive automation (subprocess-based CLI, `claude -p`, hosting guide covering Docker/Kubernetes/production deployment, quickstart for autonomous bug-fixing 'without manual intervention'), and a community report confirms a user built 'an entire headless automated workflow around claude -p', corroborating real-world CI-style use. Missing for 10: dedicated CI/CD pipeline examples (e.g. GitHub Actions template) and independent benchmarking of reliability/observability in automated pipelines, and some community friction over harness DX/observability in headless mode tempers the score.

   • [claimed-docs] “Deploy the Agent SDK in production: subprocess architecture, session persistence, scaling, observability, and multi-tenant isolation for Doc…”
   • [claimed-docs] “The Agent SDK spawns and supervises a claude CLI subprocess that owns a shell, a working directory, and session files on disk.”
   • [claimed-docs] “Use the Agent SDK to build an AI agent that reads your code, finds bugs, and fixes them, all without manual intervention.”
   • [github] “The Claude Code CLI is automatically bundled with the package - no separate installation required! The SDK will use the bundled CLI by defau…”
   • [community] “Damn. I just built an entire headless automated workflow around `claude -p`”

   proof ↗⚑ flag

   Google ADK✓fullclaimed8/10

   ADK provides a CLI (`adk run`, `adk web`, `adk eval`, `adk deploy docker`) that supports headless invocation and scripted evaluation, plus containerized deployment for CI/production pipelines. missing for 10: explicit CI pipeline examples (e.g. GitHub Actions), independent third-party confirmation of headless CI usage.

   • [github] “adk run path/to/my_agent”
   • [github] “adk run path/to/my_agent # Web UI (supports multi-agent directories or pointing directly to a single agent folder) adk web path/to/agents_d…”
   • [github] “adk eval \ samples_for_testing/hello_world \ samples_for_testing/hello_world/hello_world_eval_set_001.evalset.json”
   • [github] “adk deploy docker --with_ui <agent-folder>”
   • [claimed-docs] “You can manually package your Agent into a container image and then run it in any environment that supports container images.”
   • [claimed-docs] “This approach involves creating individual test files, each representing a single, simple agent-model interaction (a session).”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round drawn
   Claude Agent SDK✓fullclaimed8/10

   Dedicated first-party MCP docs describe connecting the agent to external MCP servers to query databases, integrate with Slack/GitHub, and use other services without custom tool code, and this integrates with the SDK's permission/tool-use system. Missing for 10: independent/hands-on corroboration of MCP server plugging (community evidence covers licensing/UX complaints, not MCP integration specifically) and configuration-level detail beyond the overview.

   • [claimed-docs] “With MCP, your agent can query databases, integrate with APIs like Slack and GitHub, and connect to other services without writing custom to…”
   • [claimed-docs] “The Claude Agent SDK provides permission controls to manage how Claude uses tools. Use permission modes and rules to define what's allowed a…”
   • [claimed-docs] “Custom tools extend the Agent SDK by letting you define your own functions that Claude can call during a conversation.”

   proof ↗⚑ flag

   Google ADK✓fullclaimed8/10

   Docs explicitly state an ADK agent can act as an MCP client and use tools provided by external MCP servers, directly matching the story. missing for 10: independent/hands-on corroboration beyond first-party docs, and more detail on multi-server configuration or auth handling.

   • [claimed-docs] “An ADK agent can act as an MCP client and use tools provided by external MCP servers.”
   • [claimed-docs] “Exposing ADK Tools via an MCP Server: How to build an MCP server that wraps ADK tools, making them accessible to any MCP client.”
   • [claimed-docs] “How to build an MCP server that wraps ADK tools, making them accessible to any MCP client.”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Google ADK
   Claude Agent SDK✓fullprobed7/10

   The SDK bundles and documents an official `claude` CLI (auto-installed subprocess, dedicated CLI reference page), and community members confirm building real headless automation with `claude -p`. However, hands-on reports cite real friction (poor observability, scroll/render bugs, and new usage-policy restrictions on CLI-based SDK apps), so it works but with notable rough edges. Missing for 10: independent quality benchmarks of the CLI experience, resolution of the harness UX complaints (flashing, scroll issues, lack of observability), and clarity on usage-policy restrictions affecting CLI workflows.

   • [github] “The Claude Code CLI is automatically bundled with the package - no separate installation required! The SDK will use the bundled CLI by defau…”
   • [claimed-docs] “The Agent SDK spawns and supervises a claude CLI subprocess that owns a shell, a working directory, and session files on disk.”
   • [probe] “official CLI documented at https://code.claude.com/docs/en/cli-reference”
   • [community] “Damn. I just built an entire headless automated workflow around `claude -p`”
   • [community] “There is no difference between claude -p and typing into their 'harness' in tmux. They want to make you pay for API which is subsidizing the…”
   • [community] “I've been using claude -p with a harness called codelayer. Their [default] harness is completely garbage when it comes at displaying full de…”

   proof ↗⚑ flag

   Google ADK✓fullclaimed8/10

   ADK ships an official CLI (`adk run`, `adk web`, `adk eval`, `adk deploy docker`) documented in the GitHub repo with concrete command examples, plus docs reference an "Agents CLI" for scaffolding/build/test/deploy workflows tailored to AI-native/agentic use. Missing for 10: independent third-party hands-on review of the CLI's AI-native ergonomics beyond first-party docs/repo.

   • [github] “adk run path/to/my_agent”
   • [github] “adk run path/to/my_agent # Web UI (supports multi-agent directories or pointing directly to a single agent folder) adk web path/to/agents_d…”
   • [github] “adk eval \ samples_for_testing/hello_world \ samples_for_testing/hello_world/hello_world_eval_set_001.evalset.json”
   • [github] “adk deploy docker --with_ui <agent-folder>”
   • [claimed-docs] “Go from idea to coded ADK agent in minutes. Use your favorite AI-enabled developer environment to scaffold, build, test, evaluate, and deplo…”
   • [claimed-docs] “Migrate existing agents and workflows to ADK with Agents CLI.”

   proof ↗⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round to Claude Agent SDK
   Claude Agent SDK✓fullcommunity9/10

   The Agent SDK is extensively documented as a public, programmable API (Python/TypeScript) covering tools, hooks, subagents, MCP, permissions, sessions, streaming, structured outputs, and hosting, with a bundled CLI and migration guides from other agent SDKs. Community evidence corroborates real hands-on use of the API (headless workflows via `claude -p`) even amid unrelated billing-policy friction. Missing for 10: independent third-party technical review confirming API stability/versioning guarantees beyond first-party docs.

   • [claimed-docs] “The Agent SDK gives you the same tools, agent loop, and context management that power Claude Code, programmable in Python and TypeScript.”
   • [claimed-docs] “Hooks are callback functions that run your code in response to agent events, like a tool being called, a session starting, or execution stop…”
   • [claimed-docs] “Subagents are separate agent instances that your main agent can spawn to handle focused subtasks. Use them to isolate context, run multiple …”
   • [claimed-docs] “With MCP, your agent can query databases, integrate with APIs like Slack and GitHub, and connect to other services without writing custom to…”
   • [claimed-docs] “Custom tools extend the Agent SDK by letting you define your own functions that Claude can call during a conversation.”
   • [claimed-docs] “Deploy the Agent SDK in production: subprocess architecture, session persistence, scaling, observability, and multi-tenant isolation for Doc…”
   • [claimed-docs] “Use ClaudeSDKClient for interactive applications such as chat interfaces, or when the next action depends on Claude's response.”
   • [claimed-docs] “Migrating from the OpenAI Agents SDK instead? The OpenAI Agents SDK migration recipe maps each primitive onto the Claude Agent SDK through a…”
   • [github] “The Claude Code CLI is automatically bundled with the package - no separate installation required! The SDK will use the bundled CLI by defau…”
   • [community] “Damn. I just built an entire headless automated workflow around `claude -p`”

   proof ↗⚑ flag

   Google ADK~partialprobed6/10

   ADK is a Python framework/CLI (adk run, adk web, adk eval, adk deploy) with documented programmatic APIs for building and driving agents, plus MCP client/server support, but there is no evidence of a formal public REST/OpenAPI-style API surface — probes for openapi/swagger specs and llms.txt all 404. missing for 10: a documented public HTTP/OpenAPI API spec, independent third-party confirmation of programmatic drivability beyond first-party docs.

   • [claimed-docs] “Create your first Python ADK agent in minutes.”
   • [github] “adk run path/to/my_agent”
   • [github] “adk run path/to/my_agent # Web UI (supports multi-agent directories or pointing directly to a single agent folder) adk web path/to/agents_d…”
   • [github] “adk eval \ samples_for_testing/hello_world \ samples_for_testing/hello_world/hello_world_eval_set_001.evalset.json”
   • [github] “adk deploy docker --with_ui <agent-folder>”
   • [probe] “PROBE openapi: all candidate paths 404 (https://google.github.io/openapi.json, https://google.github.io/swagger.json, https://google.github.…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://google.github.io/llms.txt”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Claude Agent SDK
   Claude Agent SDK~partialclaimed4/10

   The SDK documents permission controls (permission modes, rules, and a canUseTool callback) that let developers restrict which tools/actions an agent can perform, which is a form of least-privilege control over agent behavior, but there is no evidence of a mechanism for issuing scoped/least-privilege API credentials or keys (e.g., limited-scope tokens for external API access) as distinct from tool-use permissioning. Missing for 10: explicit scoped-API-key/credential issuance feature, credential rotation/expiry controls, and any documentation tying permission modes to external API credential scoping.

   • [claimed-docs] “The Claude Agent SDK provides permission controls to manage how Claude uses tools. Use permission modes and rules to define what's allowed a…”
   • [claimed-docs] “Pass a canUseTool callback in your query options. The callback fires whenever Claude needs user input, receiving the tool name and input as …”
   • [claimed-docs] “The Claude Agent SDK provides permission controls to manage how Claude uses tools.”

   proof ↗⚑ flag

   Google ADK—none0/10

   No evidence in the pack describes issuing scoped or least-privilege API credentials/tokens for agents; the docs cover tools, MCP, workflows, deployment, and evaluation but nothing about credential scoping or permission management for agent identities.

   ⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Google ADK
   Claude Agent SDK✓fullcommunity8/10

   Claude Agent SDK is itself the official first-party SDK (Python and TypeScript), with extensive documented APIs for tools, hooks, subagents, MCP, permissions, sessions, streaming, structured outputs, and production hosting, plus a GitHub package that bundles the CLI. This directly satisfies 'build against official SDKs' for an AI-native developer persona. Missing for 10: independent/hands-on corroboration of SDK ergonomics beyond vendor docs, and some community reports note DX friction/observability gaps with the default harness (not outright contradicting the capability but tempering the polish).

   • [claimed-docs] “The Agent SDK gives you the same tools, agent loop, and context management that power Claude Code, programmable in Python and TypeScript.”
   • [claimed-docs] “Built-in tools | Read, write, edit files, run commands, and search the web”
   • [claimed-docs] “Custom tools extend the Agent SDK by letting you define your own functions that Claude can call during a conversation.”
   • [claimed-docs] “Use ClaudeSDKClient for interactive applications such as chat interfaces, or when the next action depends on Claude's response.”
   • [github] “The Claude Code CLI is automatically bundled with the package - no separate installation required! The SDK will use the bundled CLI by defau…”
   • [claimed-docs] “Migrating from the OpenAI Agents SDK instead? The OpenAI Agents SDK migration recipe maps each primitive onto the Claude Agent SDK through a…”
   • [community] “I've been using claude -p with a harness called codelayer. Their [default] harness is completely garbage when it comes at displaying full de…”

   proof ↗⚑ flag

   Google ADK✓fullclaimed9/10

   Google ADK is itself an official Python SDK/framework with extensive first-party documentation, code examples, CLI tooling (adk run/web/eval/deploy), and a public GitHub repo, giving AI-native developers a fully documented, official SDK to build against. Minor gap — missing for 10: independent third-party corroboration beyond vendor docs/repo, and llms.txt/OpenAPI probes returned 404s suggesting some machine-readable doc surfaces are incomplete.

   • [claimed-docs] “Create your first Python ADK agent in minutes.”
   • [claimed-docs] “Building an agent with just a model, instructions, and tools is a great place to start for most developers.”
   • [claimed-docs] “agent = Agent( name="researcher", model="gemini-flash-latest", instruction="You help users research topics thoroughly.", too…”
   • [github] “Agent Config: Build agents without code.”
   • [github] “adk run path/to/my_agent”
   • [github] “adk run path/to/my_agent # Web UI (supports multi-agent directories or pointing directly to a single agent folder) adk web path/to/agents_d…”
   • [claimed-docs] “ADK is designed to be written by both humans and AI. Connect your favorite coding assistant to our ADK developer Skills and AI-aware develop…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Claude Agent SDK—none0/10

   The evidence pack describes hooks, streaming input/output, sessions, and callbacks (canUseTool) but nowhere mentions webhook subscriptions or an outbound HTTP event notification mechanism for external systems to subscribe to agent events.

   ⚑ flag

   Google ADK—none0/10

   ADK's evidence shows only in-process callbacks/hooks for agent execution lifecycle, not an external webhook subscription mechanism; no docs mention registering webhook URLs or event push notifications. Missing for 10: any webhook registration API, outbound event delivery docs, or third-party confirmation of webhook support.

   • [claimed-docs] “Callbacks: Hook into specific events during an agent's execution lifecycle to add logging, monitoring, or custom side-effects without alteri…”

   proof ↗⚑ flag

Agentic features

1. ai-native userSet up automations that run autonomously in the background

   weight 2 · round drawn
   Claude Agent SDK~partialcommunity6/10

   The SDK supports headless/programmatic operation (streaming input, subprocess architecture, session persistence, hooks, custom tools) that enable building autonomous background automations, and community evidence confirms real users built 'headless automated workflows' with it. However, there's no dedicated scheduling/trigger mechanism for background automation, and community feedback raises concerns about restricted usage, observability gaps, and policy uncertainty for such non-interactive uses. Missing for 10: built-in scheduling/cron or trigger-based automation features, clear documentation of long-running unattended background execution, and resolution of the community-reported usage restrictions/observability complaints for headless workflows.

   • [claimed-docs] “Deploy the Agent SDK in production: subprocess architecture, session persistence, scaling, observability, and multi-tenant isolation for Doc…”
   • [claimed-docs] “The Agent SDK spawns and supervises a claude CLI subprocess that owns a shell, a working directory, and session files on disk.”
   • [claimed-docs] “Streaming input mode is the preferred way to use the Claude Agent SDK. It provides full access to the agent's capabilities and enables rich,…”
   • [claimed-docs] “A session is the conversation history the SDK accumulates while your agent works. ... The SDK writes it to disk automatically so you can ret…”
   • [community] “Damn. I just built an entire headless automated workflow around `claude -p`”
   • [community] “There is no difference between claude -p and typing into their 'harness' in tmux. They want to make you pay for API which is subsidizing the…”
   • [community] “My frustration with Anthropic has been around the uncertainty of all of this. What constitutes fair usage, what can I play with and not risk…”

   proof ↗⚑ flag

   Google ADK~partialclaimed6/10

   ADK supports deployable, auto-scaling agent runtimes (Cloud Run, GKE, Agent Runtime) and workflow orchestration with retries, state, and scheduling-like execution (fan-out/fan-in, loops), enabling agents to run unattended once deployed. However, evidence does not show explicit scheduling/triggers (e.g., cron-like autonomous kick-off) or a dedicated 'background automation' mode distinct from deployment. missing for 10: explicit trigger/schedule mechanism for autonomous background runs, independent evidence of long-running unattended operation, and confirmation of persistent background execution outside a deploy/response cycle.

   • [claimed-docs] “Agent Runtime is a fully managed auto-scaling service on Google Cloud specifically designed for deploying, managing, and scaling AI agents b…”
   • [claimed-docs] “Cloud Run is a managed auto-scaling compute platform on Google Cloud that enables you to run your agent as a container-based application.”
   • [claimed-docs] “GKE is a good option if you need more control over the deployment as well as for running Open Models.”
   • [github] “Workflow Runtime: A graph-based execution engine for composing deterministic execution flows for agentic apps, with support for routing, fan…”
   • [github] “A graph-based execution engine for composing deterministic execution flows for agentic apps, with support for routing, fan-out/fan-in, loops…”
   • [claimed-docs] “In ADK, any agent application that has more than one agent or executable Node is considered a workflow.”

   proof ↗⚑ flag

2. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to Claude Agent SDK
   Claude Agent SDK✓fullclaimed8/10

   The SDK is explicitly designed so a user/developer can delegate tasks—file edits, running commands, web search, subagent spawning—to an embedded Claude agent loop, with quickstart examples showing autonomous bug-fixing 'without manual intervention.' Some community friction exists around usage-policy and default harness UX, but no evidence contradicts the core delegation capability. missing for 10: independent hands-on validation of complex multi-step delegation scenarios beyond docs and quickstart examples.

   • [claimed-docs] “The Agent SDK gives you the same tools, agent loop, and context management that power Claude Code, programmable in Python and TypeScript.”
   • [claimed-docs] “Built-in tools | Read, write, edit files, run commands, and search the web”
   • [claimed-docs] “Subagents are separate agent instances that your main agent can spawn to handle focused subtasks. Use them to isolate context, run multiple …”
   • [claimed-docs] “Use the Agent SDK to build an AI agent that reads your code, finds bugs, and fixes them, all without manual intervention.”
   • [claimed-docs] “Finance agents: Build agents that can understand your portfolio and goals, as well as help you evaluate investments by accessing external AP…”

   proof ↗⚑ flag

   Google ADK—none0/10

   ADK is a framework for building agents that developers run themselves; the docs explicitly describe connecting *external* coding assistants (e.g., 'Connect your favorite coding assistant to our ADK developer Skills') rather than shipping a built-in AI assistant that end-users delegate tasks to inside the product itself. No evidence shows ADK embedding its own persistent assistant persona for task delegation.

   • [claimed-docs] “ADK is designed to be written by both humans and AI. Connect your favorite coding assistant to our ADK developer Skills and AI-aware develop…”
   • [claimed-docs] “Go from idea to coded ADK agent in minutes. Use your favorite AI-enabled developer environment to scaffold, build, test, evaluate, and deplo…”

   proof ↗⚑ flag

3. ai-native userOperate the product with natural-language commands

   weight 2 · round to Claude Agent SDK
   Claude Agent SDK✓fullclaimed8/10

   The SDK is fundamentally natural-language driven: it's built on Claude Code's agent loop where users issue natural-language prompts/queries and the agent autonomously invokes tools, subagents, and permission flows in response (docs-1, docs-8, docs-9, docs-13, docs-26). Streaming interactive mode and the bundled CLI (claude -p) further confirm operation via conversational natural-language input rather than rigid commands. missing for 10: no independent hands-on demonstration of a non-technical user driving it purely via natural language without code/config, and community evidence focuses on licensing/harness complaints rather than confirming NL usability quality.

   • [claimed-docs] “The Agent SDK gives you the same tools, agent loop, and context management that power Claude Code, programmable in Python and TypeScript.”
   • [claimed-docs] “Custom tools extend the Agent SDK by letting you define your own functions that Claude can call during a conversation.”
   • [claimed-docs] “Pass a canUseTool callback in your query options. The callback fires whenever Claude needs user input, receiving the tool name and input as …”
   • [claimed-docs] “Use ClaudeSDKClient for interactive applications such as chat interfaces, or when the next action depends on Claude's response.”
   • [claimed-docs] “It allows the agent to operate as a long lived process that takes in user input, handles interruptions, surfaces permission requests, and ha…”
   • [github] “The Claude Code CLI is automatically bundled with the package - no separate installation required! The SDK will use the bundled CLI by defau…”

   proof ↗⚑ flag

   Google ADK~partialclaimed5/10

   ADK docs claim it is designed to be built and operated via AI coding assistants (Agent Config for no-code agent building, 'Agents CLI' for AI-enabled dev environments to scaffold/build/test/deploy) which supports some natural-language-driven operation, but the primary operating surface is a traditional CLI (adk run/web/eval/deploy) and Python code, not direct NL commands to the tool itself. Missing for 10: concrete example of natural-language command controlling ADK end-to-end, independent/hands-on confirmation that Agent Config or coding-assistant integration works as a full NL interface.

   • [claimed-docs] “ADK is designed to be written by both humans and AI. Connect your favorite coding assistant to our ADK developer Skills and AI-aware develop…”
   • [claimed-docs] “Go from idea to coded ADK agent in minutes. Use your favorite AI-enabled developer environment to scaffold, build, test, evaluate, and deplo…”
   • [github] “Agent Config: Build agents without code.”
   • [github] “Agent Config: Build agents without code. Check out the Agent Config feature.”
   • [github] “Build agents without code. Check out the Agent Config feature.”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   Claude Agent SDK—none0/10

   The evidence pack shows extensive markdown-based documentation (overview, hooks, subagents, permissions, sessions, etc.) and llms.txt-style text docs, but nothing indicates an interactive API reference with runnable/embedded code examples (e.g., a browser-based sandbox or live code runner) — docs appear to be static reference pages only.

   ⚑ flag

   Google ADK—none0/10

   The evidence pack shows standard docs, code snippets, and CLI examples, but no interactive/runnable API reference (e.g., a Swagger/OpenAPI explorer or live code sandbox); probes for openapi.json and similar endpoints explicitly returned 404s.

   • [probe] “PROBE openapi: all candidate paths 404 (https://google.github.io/openapi.json, https://google.github.io/swagger.json, https://google.github.…”
   • [probe] “PROBE docs-md: HTTP 404 at https://google.github.io/adk-docs/get-started/.md”
   • [claimed-docs] “agent = Agent( name="researcher", model="gemini-flash-latest", instruction="You help users research topics thoroughly.", too…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Claude Agent SDK—none0/10

   No evidence of an OpenAPI or other machine-readable API spec being published for the Agent SDK; docs mention llms.txt indexes and Markdown docs but not a formal machine-readable API spec download.

   ⚑ flag

   Google ADK—none0/10

   No evidence of a downloadable OpenAPI/machine-readable spec for ADK; explicit probes for openapi.json/swagger.json and llms.txt all return 404, indicating no such spec is published.

   • [probe] “PROBE llms.txt: HTTP 404 at https://google.github.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://google.github.io/adk-docs/get-started/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://google.github.io/openapi.json, https://google.github.io/swagger.json, https://google.github.…”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Google ADK
   Claude Agent SDK~partialclaimed3/10

   Docs mention deploying the SDK in production with 'sandbox providers' and multi-tenant isolation (Docker/Kubernetes), plus permission/hook controls to block dangerous operations, which could support building a sandboxed test setup, but there is no explicit feature or guidance for testing against a sandbox without touching production data. Missing for 10: dedicated sandbox/test-mode documentation, explicit production-data isolation guarantees, and hands-on evidence of safe test usage.

   • [claimed-docs] “Deploy the Agent SDK in production: subprocess architecture, session persistence, scaling, observability, and multi-tenant isolation for Doc…”
   • [claimed-docs] “With hooks, you can: Block dangerous operations before they execute, like destructive shell commands or unauthorized file access”
   • [claimed-docs] “The Claude Agent SDK provides permission controls to manage how Claude uses tools. Use permission modes and rules to define what's allowed a…”

   proof ↗⚑ flag

   Google ADK~partialclaimed5/10

   ADK supports local dev/test workflows (adk run, adk web, adk eval, local evaluation with test files and eval sets) that inherently run against a local/dev environment rather than production, and offline/disconnected deployment is mentioned. However, there's no explicit documentation of a dedicated 'sandbox' environment or data isolation guarantee distinct from production. missing for 10: explicit sandbox/staging environment docs, explicit statement that test runs are isolated from production data/state, independent confirmation of this isolation.

   • [claimed-docs] “This approach involves creating individual test files, each representing a single, simple agent-model interaction (a session).”
   • [claimed-docs] “This approach involves creating individual test files, each representing a single, simple agent-model interaction (a session). It's most eff…”
   • [claimed-docs] “Expected Intermediate Tool Use Trajectory: The tool calls we expect the agent to make in order to respond correctly to the user query.”
   • [github] “adk run path/to/my_agent # Web UI (supports multi-agent directories or pointing directly to a single agent folder) adk web path/to/agents_d…”
   • [github] “adk eval \ samples_for_testing/hello_world \ samples_for_testing/hello_world/hello_world_eval_set_001.evalset.json”
   • [claimed-docs] “This is a good option if you prefer to run offline or disconnected, or otherwise in a system that has no connection to Google Cloud.”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Claude Agent SDK—none0/10

   The evidence pack documents SDK features (tools, hooks, sessions, permissions) and a migration guide from a competing SDK, but contains no mention of API versioning, version numbers, a changelog, or a documented deprecation policy for the Agent SDK itself. Community threads discuss usage/billing policy shifts, which are off-topic to API versioning and deprecation guarantees.

   ⚑ flag

   Google ADK—none0/10

   No evidence in the pack mentions API versioning schemes or a documented deprecation policy for ADK; probes for OpenAPI specs and related docs all returned 404s. missing for 10: versioning scheme documentation, deprecation policy, changelog/migration guides, semantic versioning commitments.

   • [probe] “PROBE llms.txt: HTTP 404 at https://google.github.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://google.github.io/adk-docs/get-started/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://google.github.io/openapi.json, https://google.github.io/swagger.json, https://google.github.…”

   proof ↗⚑ flag

Agent authoring

1. developerDefine an agent with typed custom tools in a few lines of code

   weight 3 · round to Claude Agent SDK
   Claude Agent SDK✓fullclaimed7/10

   Docs explicitly describe custom-tools support letting developers define their own functions Claude can call, with permission controls and callback hooks around tool use, indicating a lightweight typed-tool definition workflow. missing for 10: no concrete code snippet showing the 'few lines of code' typed tool definition, no independent/hands-on confirmation of ergonomics or type-safety guarantees.

   • [claimed-docs] “Custom tools extend the Agent SDK by letting you define your own functions that Claude can call during a conversation.”
   • [claimed-docs] “Pass a canUseTool callback in your query options. The callback fires whenever Claude needs user input, receiving the tool name and input as …”
   • [claimed-docs] “The Claude Agent SDK provides permission controls to manage how Claude uses tools. Use permission modes and rules to define what's allowed a…”
   • [claimed-docs] “The Claude Agent SDK provides permission controls to manage how Claude uses tools.”

   proof ↗⚑ flag

   Google ADK~partialclaimed6/10

   The docs show a concrete few-line example of defining an Agent with a model, instructions, and a tools list (google-adk-docs-22), and other docs confirm tools are a core, optional component of agent definition (google-adk-docs-2, google-adk-docs-13). However, the evidence never shows a custom Python tool function with type hints/typed parameters being defined and passed in — only a prebuilt tool (google_search) is used in the example. Missing for 10: an explicit example of writing a custom typed tool function, and documentation of automatic schema/type inference from function signatures.

   • [claimed-docs] “agent = Agent( name="researcher", model="gemini-flash-latest", instruction="You help users research topics thoroughly.", too…”
   • [claimed-docs] “Building an agent with just a model, instructions, and tools is a great place to start for most developers.”
   • [claimed-docs] “The basic components of an Agent are an artificial intelligence (AI) model, task instructions, and optionally, a set of tools to be used by …”

   proof ↗⚑ flag

Ai buildability

1. ai-native userHave a coding agent scaffold a new agent project from an official CLI or template in one command

   weight 2 · round to Google ADK
   Claude Agent SDK—none0/10

   The evidence describes SDK features (tools, hooks, sessions, subagents) and a quickstart guide for building an agent, plus a bundled CLI, but nothing documents a single-command scaffold/template generator (e.g., an 'init' or 'create-agent' command) for starting a new agent project.

   ⚑ flag

   Google ADK✓fullclaimed8/10

   ADK docs explicitly advertise an official 'Agents CLI' to scaffold, build, test, evaluate, and deploy agents in minutes, and the GitHub README shows concrete one-line commands (adk run, adk web, adk deploy) plus a no-code 'Agent Config' template feature for scaffolding agents. This directly matches the ai-native scaffolding story via an official CLI/template workflow. Missing for 10: independent/hands-on confirmation of the one-command scaffold experience beyond first-party docs.

   • [claimed-docs] “Go from idea to coded ADK agent in minutes. Use your favorite AI-enabled developer environment to scaffold, build, test, evaluate, and deplo…”
   • [claimed-docs] “Migrate existing agents and workflows to ADK with Agents CLI.”
   • [github] “adk run path/to/my_agent”
   • [github] “adk run path/to/my_agent # Web UI (supports multi-agent directories or pointing directly to a single agent folder) adk web path/to/agents_d…”
   • [github] “Agent Config: Build agents without code. Check out the Agent Config feature.”
   • [github] “Build agents without code. Check out the Agent Config feature.”

   proof ↗⚑ flag

2. ai-native userRun the framework's example agents headlessly from a terminal so an agent can verify what it just built

   weight 2 · round to Google ADK
   Claude Agent SDK~partialcommunity5/10

   The SDK bundles the claude CLI and supports headless/non-interactive use (claude -p, subprocess architecture, streaming vs single-shot modes) confirmed by both docs and community usage of `claude -p` in automated workflows, which supports the general capability of running agents headlessly from a terminal. However, there is no evidence of packaged 'example agents' shipped with the framework meant specifically for self-verification of what an agent just built, and community reports describe the harness as hacky with poor observability. missing for 10: documented example-agent repo/templates runnable headlessly, an explicit self-verification workflow, and hands-on confirmation the examples work smoothly out of the box.

   • [claimed-docs] “The Agent SDK spawns and supervises a claude CLI subprocess that owns a shell, a working directory, and session files on disk.”
   • [claimed-docs] “Streaming input mode is the preferred way to use the Claude Agent SDK. It provides full access to the agent's capabilities and enables rich,…”
   • [github] “The Claude Code CLI is automatically bundled with the package - no separate installation required! The SDK will use the bundled CLI by defau…”
   • [community] “Damn. I just built an entire headless automated workflow around `claude -p`”
   • [community] “I've been using claude -p with a harness called codelayer. Their [default] harness is completely garbage when it comes at displaying full de…”
   • [claimed-docs] “Use the Agent SDK to build an AI agent that reads your code, finds bugs, and fixes them, all without manual intervention.”

   proof ↗⚑ flag

   Google ADK✓fullclaimed7/10

   ADK provides a documented CLI (`adk run path/to/my_agent`) to run agents headlessly from a terminal, plus `adk eval` for automated verification of agent behavior against eval sets, matching the 'verify what it just built' use case for an ai-native/agentic workflow. Missing for 10: explicit confirmation that shipped 'example agents' (vs. user-authored ones) work with this flow, and independent/hands-on corroboration beyond the official repo docs.

   • [github] “adk run path/to/my_agent”
   • [github] “adk run path/to/my_agent # Web UI (supports multi-agent directories or pointing directly to a single agent folder) adk web path/to/agents_d…”
   • [github] “adk eval \ samples_for_testing/hello_world \ samples_for_testing/hello_world/hello_world_eval_set_001.evalset.json”
   • [claimed-docs] “This approach involves creating individual test files, each representing a single, simple agent-model interaction (a session).”

   proof ↗⚑ flag

3. ai-native userRely on strict typing and schema validation so a coding agent catches its own mistakes at build time

   weight 2 · round to Claude Agent SDK
   Claude Agent SDK~partialclaimed4/10

   The SDK offers 'structured outputs' where you define a schema and get back validated JSON matching it, which is the closest evidence to schema validation, but this is runtime validation of agent output, not compile/build-time type checking of the agent's own reasoning or code as the story implies. There's no evidence of static type-checking integration, IDE-time error catching, or build-time validation gates for agent actions. missing for 10: explicit build-time/compile-time type-checking tooling, evidence of the agent catching its own mistakes before execution (not just output shape), IDE/linter integration for agent-authored code.

   • [claimed-docs] “Structured outputs let you define the exact shape of data you want back from an agent. ... you still get validated JSON matching your schema…”
   • [claimed-docs] “Structured outputs let you define the exact shape of data you want back from an agent... you still get validated JSON matching your schema a…”
   • [claimed-docs] “Structured outputs let you define the exact shape of data you want back from an agent.”

   proof ↗⚑ flag

   Google ADK—none0/10

   The evidence pack covers ADK's agent orchestration, deployment, and evaluation features, but contains no mention of strict typing, schema validation, or build-time error detection for tool/agent definitions — the evaluation features described (docs-20, docs-21, docs-25) are runtime test-set based, not compile/build-time type checks.

   ⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Claude Agent SDK
   Claude Agent SDK~partialcommunity5/10

   The SDK supports programmatic automation (custom tools, subagents for parallel focused subtasks, headless/scriptable operation via claude -p, structured outputs) which can be composed to perform bulk operations across many items, but there is no explicit documentation of a bulk-operation primitive (e.g., batch processing many files/records with progress tracking, rate limiting, or a dedicated batch API). missing for 10: explicit bulk/batch operation APIs or examples, evidence of handling large item counts reliably, and independent confirmation of bulk-scale performance.

   • [claimed-docs] “Subagents are separate agent instances that your main agent can spawn to handle focused subtasks. Use them to isolate context, run multiple …”
   • [claimed-docs] “Custom tools extend the Agent SDK by letting you define your own functions that Claude can call during a conversation.”
   • [claimed-docs] “Subagents are separate agent instances that your main agent can spawn to handle focused subtasks.”
   • [community] “Damn. I just built an entire headless automated workflow around `claude -p`”

   proof ↗⚑ flag

   Google ADK~partialclaimed3/10

   ADK's Workflow Runtime offers fan-out/fan-in and loop constructs that could be used by developers to build bulk-item processing pipelines, but there is no documented built-in 'bulk operations' feature or example for end users acting across many items at once. Missing for 10: explicit bulk-operation tooling/UI, documented examples of processing many items in one call, and evidence of end-user (not just developer-framework) bulk workflows.

   • [github] “Workflow Runtime: A graph-based execution engine for composing deterministic execution flows for agentic apps, with support for routing, fan…”
   • [claimed-docs] “you can use the ADK development framework to expand them into workflows, which allow you to combine and orchestrate multiple agents and code…”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round drawn
   Claude Agent SDK✓fullclaimed7/10

   Hooks are explicitly documented as callback functions that run custom code in response to agent events (tool calls, session start, execution stop), enabling automatic actions like blocking dangerous operations before execution. Permission modes/rules further let users define what's allowed automatically. Missing for 10: independent/hands-on corroboration of hooks in real automation workflows, and more detail on the full range of triggerable event types/rule complexity.

   • [claimed-docs] “Hooks are callback functions that run your code in response to agent events, like a tool being called, a session starting, or execution stop…”
   • [claimed-docs] “With hooks, you can: Block dangerous operations before they execute, like destructive shell commands or unauthorized file access”
   • [claimed-docs] “The Claude Agent SDK provides permission controls to manage how Claude uses tools. Use permission modes and rules to define what's allowed a…”

   proof ↗⚑ flag

   Google ADK✓fullclaimed7/10

   ADK explicitly supports event-driven automation via Callbacks ("Hook into specific events during an agent's execution lifecycle... without altering core agent logic") and a Workflow Runtime graph engine with routing, retry, fan-out/fan-in and dynamic nodes for triggering actions on execution events, matching the story of defining rules that fire on events. missing for 10: independent/hands-on evidence of callback-triggered rules in production use, and more detail on condition-based rule syntax beyond docs summaries.

   • [claimed-docs] “Callbacks: Hook into specific events during an agent's execution lifecycle to add logging, monitoring, or custom side-effects without alteri…”
   • [github] “Workflow Runtime: A graph-based execution engine for composing deterministic execution flows for agentic apps, with support for routing, fan…”
   • [github] “A graph-based execution engine for composing deterministic execution flows for agentic apps, with support for routing, fan-out/fan-in, loops…”
   • [claimed-docs] “In ADK, any agent application that has more than one agent or executable Node is considered a workflow.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   Claude Agent SDK—none0/10

   The evidence covers sessions, subagents, hooks, MCP, permissions, and hosting, but nowhere mentions a scheduler, cron-like trigger, or built-in mechanism for recurring/automated job execution—developers would need to build their own external scheduling infrastructure around the SDK. missing for 10: any built-in scheduling/cron primitive, recurring-trigger API, or workflow-automation feature for periodic execution.

   • [claimed-docs] “A session is the conversation history the SDK accumulates while your agent works. ... The SDK writes it to disk automatically so you can ret…”
   • [claimed-docs] “Deploy the Agent SDK in production: subprocess architecture, session persistence, scaling, observability, and multi-tenant isolation for Doc…”
   • [claimed-docs] “It allows the agent to operate as a long lived process that takes in user input, handles interruptions, surfaces permission requests, and ha…”

   proof ↗⚑ flag

   Google ADK—none0/10

   The evidence covers agent/workflow orchestration, deployment targets (Cloud Run, GKE, Agent Runtime), and evaluation, but nothing describes scheduling, cron-like triggers, or recurring execution of jobs/workflows. Absence of evidence for this applicable automation-depth capability yields 'none'.

   ⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round drawn
   Claude Agent SDK—none0/10

   The SDK documents session persistence, forking, and resuming conversation history (docs-7, docs-21, docs-24), but this is conversation/session state, not version control, review, or rollback of the automations/agent definitions themselves. There is no evidence of a versioning system, change review/approval workflow, or rollback mechanism for the automations a user builds with the SDK.

   ⚑ flag

   Google ADK—none0/10

   ADK is a framework for building agents (code, workflows, tools, deployment) but the evidence pack shows no version control, review, or rollback mechanism for automations themselves — no changelog/versioning UI, no approval/review workflow for agent definitions, no rollback feature. Agent code could theoretically be tracked via external git, but ADK itself provides no such capability in the evidence. Missing for 10: any versioning system, review/approval workflow, or rollback capability for automations.

   ⚑ flag

Deployment

1. engineering-leadDeploy an agent to a managed runtime and call it as an API endpoint

   weight 2 · round to Google ADK
   Claude Agent SDK~partialclaimed6/10

   Docs explicitly cover production deployment concerns—subprocess architecture, session persistence, scaling, observability, and multi-tenant isolation across Docker, Kubernetes, and sandbox providers—giving an engineering lead a path to run the SDK as a backend service. However, this is self-hosting guidance, not a first-party managed runtime; the SDK still spawns a local CLI subprocess and there's no evidence of Anthropic providing a hosted 'deploy as endpoint' service, and the developer must build the API wrapper themselves. Missing for 10: a true managed-runtime/PaaS offering, first-party API-endpoint scaffolding, and independent confirmation of production deployments at scale.

   • [claimed-docs] “Deploy the Agent SDK in production: subprocess architecture, session persistence, scaling, observability, and multi-tenant isolation for Doc…”
   • [claimed-docs] “The Agent SDK spawns and supervises a claude CLI subprocess that owns a shell, a working directory, and session files on disk.”
   • [claimed-docs] “A `SessionStore` adapter lets you mirror those transcripts to your own backend, such as an object store, a key-value store, or a database, s…”

   proof ↗⚑ flag

   Google ADK✓fullclaimed8/10

   ADK docs explicitly describe deploying agents to a fully managed, auto-scaling Agent Engine/Agent Runtime on Google Cloud, plus alternative managed options like Cloud Run and GKE, with the stated purpose being to make the agent 'accessed, queried, and used in production' as an API endpoint. Missing for 10: no explicit hands-on/independent confirmation of the API contract (e.g., request/response schema) or third-party verification of endpoint behavior beyond first-party docs.

   • [claimed-docs] “Agent Runtime is a fully managed auto-scaling service on Google Cloud specifically designed for deploying, managing, and scaling AI agents b…”
   • [claimed-docs] “Cloud Run is a managed auto-scaling compute platform on Google Cloud that enables you to run your agent as a container-based application.”
   • [claimed-docs] “GKE is a good option if you need more control over the deployment as well as for running Open Models.”
   • [claimed-docs] “Once you've built and tested your agent using ADK, the next step is to deploy it so it can be accessed, queried, and used in production”
   • [claimed-docs] “You can manually package your Agent into a container image and then run it in any environment that supports container images.”

   proof ↗⚑ flag

2. engineering-leadRun my agents entirely on my own infrastructure with no dependence on the vendor's platform

   weight 2 · round to Google ADK
   Claude Agent SDK!disputedcontradicted4/10

   Docs claim you can self-host the SDK's orchestration layer (Docker/Kubernetes/subprocess architecture, session persistence, multi-tenant isolation) [claude-agent-sdk-docs-11, claude-agent-sdk-docs-20], but the SDK still requires the bundled Claude CLI and Anthropic's model API to function, and community evidence documents Anthropic tightening platform-level control over how the SDK can be used—restricting subscription usage, changing what's 'allowed' month to month, and creating uncertainty about bans/quotas [claude-agent-sdk-comm-1, claude-agent-sdk-comm-4, claude-agent-sdk-comm-9, claude-agent-sdk-comm-11]. This shows that despite infra-level self-hosting options, engineering leads remain functionally dependent on Anthropic's policies and API access, directly undercutting the 'no dependence on vendor's platform' claim. Missing for 10: evidence of a fully vendor-independent model backend or offline/self-hosted inference option, and confirmation that policy changes don't affect self-hosted deployments.

   • [claimed-docs] “Deploy the Agent SDK in production: subprocess architecture, session persistence, scaling, observability, and multi-tenant isolation for Doc…”
   • [claimed-docs] “The Agent SDK spawns and supervises a claude CLI subprocess that owns a shell, a working directory, and session files on disk.”
   • [community] “You can no longer use your Claude subscription with apps that use the Claude Agent SDK, e.g. claude -p, Conductor, T3code, etc.”
   • [community] “Currently the credit doesn't apply to interactive Claude Code, web/desktop/mobile apps, Claude Cowork, etc. Next month, interactive claude c…”
   • [community] “My frustration with Anthropic has been around the uncertainty of all of this. What constitutes fair usage, what can I play with and not risk…”
   • [community] “This is big, but until we have policy clarity we can't trust it. I've always migrated all of our agents to Pi SDK, we aren't going back.”

   proof ↗⚑ flag

   Google ADK✓fullclaimed8/10

   ADK is an open-source framework (google/adk-python) that supports running agents locally via `adk run`/`adk web`, packaging into containers with `adk deploy docker`, deploying to any container-supporting environment, and explicitly documents an offline/disconnected mode with no Google Cloud connection required, alongside optional managed services like Agent Runtime/Cloud Run/GKE. missing for 10: independent/hands-on confirmation of fully vendor-free operation (e.g., third-party report of running ADK completely offline with non-Google models) and clarity on whether any telemetry/model calls still phone home by default.

   • [claimed-docs] “This is a good option if you prefer to run offline or disconnected, or otherwise in a system that has no connection to Google Cloud.”
   • [claimed-docs] “You can manually package your Agent into a container image and then run it in any environment that supports container images.”
   • [github] “adk deploy docker --with_ui <agent-folder>”
   • [github] “adk run path/to/my_agent # Web UI (supports multi-agent directories or pointing directly to a single agent folder) adk web path/to/agents_d…”
   • [claimed-docs] “ADK can work with almost any generative AI model. The framework provides easy access to Gemini as well as other leading models, and we provi…”
   • [claimed-docs] “GKE is a good option if you need more control over the deployment as well as for running Open Models.”

   proof ↗⚑ flag

Portability

1. developerSwap the underlying LLM provider or model without rewriting my agent

   weight 3 · round to Google ADK
   Claude Agent SDK—none0/10

   The evidence shows the Agent SDK is architected specifically around Anthropic's Claude models — it bundles and spawns a 'claude CLI subprocess' and is built to power Claude Code — with no mention of an abstraction layer for swapping in other LLM providers/models. The only related item is a migration guide *from* the OpenAI Agents SDK *to* this SDK (docs-33), which is a one-way onboarding path, not evidence of provider-agnostic model swapping within the SDK itself.

   • [github] “The Claude Code CLI is automatically bundled with the package - no separate installation required! The SDK will use the bundled CLI by defau…”
   • [claimed-docs] “The Agent SDK spawns and supervises a claude CLI subprocess that owns a shell, a working directory, and session files on disk.”
   • [claimed-docs] “Migrating from the OpenAI Agents SDK instead? The OpenAI Agents SDK migration recipe maps each primitive onto the Claude Agent SDK through a…”

   proof ↗⚑ flag

   Google ADK✓fullclaimed8/10

   Docs explicitly state ADK works with 'almost any generative AI model,' providing adapters for Gemini and many other model providers including locally running models, and the agent definition just takes a `model` string parameter (e.g., 'gemini-flash-latest'), implying swapping providers is a config change rather than a rewrite. Missing for 10: independent/hands-on confirmation that switching providers requires no code changes to agent logic, and no explicit list of supported non-Gemini providers with concrete migration examples.

   • [claimed-docs] “ADK can work with almost any generative AI model. The framework provides easy access to Gemini as well as other leading models, and we provi…”
   • [claimed-docs] “agent = Agent( name="researcher", model="gemini-flash-latest", instruction="You help users research topics thoroughly.", too…”
   • [claimed-docs] “The basic components of an Agent are an artificial intelligence (AI) model, task instructions, and optionally, a set of tools to be used by …”

   proof ↗⚑ flag

Evals

1. engineering-leadScore agent quality with built-in evals and run them as part of CI

   weight 2 · round to Google ADK
   Claude Agent SDK—none0/10

   No evidence pack item mentions evals, scoring frameworks, benchmarks, or CI integration for agent quality; documentation covers tools, hooks, sessions, permissions, structured outputs, and hosting but nothing about built-in evaluation or CI test harnesses.

   ⚑ flag

   Google ADK✓fullclaimed8/10

   ADK ships a first-party evaluation framework with groundtruth and rubric-based metrics, expected tool-use trajectories, evalset.json test files, and a documented CLI command (`adk eval <agent> <evalset>`) that can be scripted/invoked headlessly, which is exactly the shape needed for CI integration. Missing for 10: explicit CI/CD pipeline documentation (e.g., a GitHub Actions example) and independent/third-party corroboration of running adk eval in CI.

   • [claimed-docs] “This approach involves creating individual test files, each representing a single, simple agent-model interaction (a session).”
   • [claimed-docs] “ADK provides both groundtruth based and rubric based tool use evaluation metrics.”
   • [claimed-docs] “This approach involves creating individual test files, each representing a single, simple agent-model interaction (a session). It's most eff…”
   • [claimed-docs] “Expected Intermediate Tool Use Trajectory: The tool calls we expect the agent to make in order to respond correctly to the user query.”
   • [github] “adk eval \ samples_for_testing/hello_world \ samples_for_testing/hello_world/hello_world_eval_set_001.evalset.json”

   proof ↗⚑ flag

Testing

1. developerUnit-test agents with mocked models and tools

   weight 2 · round to Google ADK
   Claude Agent SDK—none0/10

   The evidence pack documents custom tools, hooks, permissions, sessions, and structured outputs, but there is no mention of a testing framework, mock model/tool harness, or any guidance for unit-testing agents with mocked dependencies.

   ⚑ flag

   Google ADK~partialclaimed5/10

   ADK docs describe a test-file based evaluation approach explicitly described as 'a form of unit testing' for single agent-model interactions, with expected tool-use trajectories and groundtruth/rubric metrics plus an `adk eval` CLI — but none of this evidence explicitly describes mocking models or tools (e.g., swapping in fake LLM responses or stub tool implementations) for isolated unit tests. Missing for 10: explicit mocked-model/mocked-tool test fixtures or APIs, independent/hands-on confirmation of mocking support, and unit-test framework integration examples (e.g., pytest with mock objects).

   • [claimed-docs] “This approach involves creating individual test files, each representing a single, simple agent-model interaction (a session).”
   • [claimed-docs] “This approach involves creating individual test files, each representing a single, simple agent-model interaction (a session). It's most eff…”
   • [claimed-docs] “Expected Intermediate Tool Use Trajectory: The tool calls we expect the agent to make in order to respond correctly to the user query.”
   • [claimed-docs] “ADK provides both groundtruth based and rubric based tool use evaluation metrics.”
   • [github] “adk eval \ samples_for_testing/hello_world \ samples_for_testing/hello_world/hello_world_eval_set_001.evalset.json”

   proof ↗⚑ flag

Tracing

1. developerTrace every LLM call and tool invocation of an agent run in an observability UI

   weight 3 · round to Google ADK
   Claude Agent SDK!disputedcontradicted4/10

   Docs mention 'observability' as a topic covered in production hosting guidance and hooks/streaming provide raw events for tool calls and messages, but there's no dedicated tracing/observability UI documented (e.g., no trace viewer, no integration with an eval/observability platform). Community hands-on reports directly contradict any claim of built-in observability, describing the default harness as having '0 observability' and failing to display full tool-call/session details in its UI. missing for 10: a dedicated observability/tracing UI or integration, documented trace export (OpenTelemetry/etc.), and evidence resolving the community complaints about poor tool-call visibility.

   • [claimed-docs] “Deploy the Agent SDK in production: subprocess architecture, session persistence, scaling, observability, and multi-tenant isolation for Doc…”
   • [claimed-docs] “Hooks are callback functions that run your code in response to agent events, like a tool being called, a session starting, or execution stop…”
   • [community] “There is no difference between claude -p and typing into their 'harness' in tmux. They want to make you pay for API which is subsidizing the…”
   • [community] “I've been using claude -p with a harness called codelayer. Their [default] harness is completely garbage when it comes at displaying full de…”

   proof ↗⚑ flag

   Google ADK~partialclaimed5/10

   ADK ships a built-in development Web UI explicitly for testing, evaluating, and debugging agents, and provides callbacks to hook into execution lifecycle events for logging/monitoring, which together imply some run-level visibility into tool and model calls. However, the evidence never explicitly describes a trace view showing each LLM call and tool invocation of a run, nor mentions integration with tracing standards (e.g., OpenTelemetry) or a dedicated observability dashboard beyond the dev/eval UI. Missing for 10: explicit documentation of per-call tracing UI, tool-invocation-level trace inspection, and any third-party/hands-on confirmation of this granularity.

   • [github] “A built-in development UI to help you test, evaluate, debug, and showcase your agent(s).”
   • [github] “Web UI (supports multi-agent directories or pointing directly to a single agent folder)”
   • [github] “adk run path/to/my_agent # Web UI (supports multi-agent directories or pointing directly to a single agent folder) adk web path/to/agents_d…”
   • [claimed-docs] “Callbacks: Hook into specific events during an agent's execution lifecycle to add logging, monitoring, or custom side-effects without alteri…”

   proof ↗⚑ flag

Guardrails

1. developerAttach input/output guardrails that validate, transform, or block unsafe content

   weight 3 · round to Claude Agent SDK
   Claude Agent SDK~partialclaimed6/10

   Hooks provide a mechanism to intercept tool calls and block dangerous operations before execution, and canUseTool/permissions callbacks allow runtime validation/blocking of tool use, which together approximate input/output guardrails. However, there is no dedicated 'guardrails' API for validating or transforming model output content itself (e.g., content moderation, output rewriting) beyond structured-output schema validation. missing for 10: explicit output-content validation/transformation guardrail API, first-party examples of blocking/altering unsafe generated text (not just tool calls), independent verification of guardrail robustness.

   • [claimed-docs] “Hooks are callback functions that run your code in response to agent events, like a tool being called, a session starting, or execution stop…”
   • [claimed-docs] “With hooks, you can: Block dangerous operations before they execute, like destructive shell commands or unauthorized file access”
   • [claimed-docs] “The Claude Agent SDK provides permission controls to manage how Claude uses tools. Use permission modes and rules to define what's allowed a…”
   • [claimed-docs] “Pass a canUseTool callback in your query options. The callback fires whenever Claude needs user input, receiving the tool name and input as …”
   • [claimed-docs] “Structured outputs let you define the exact shape of data you want back from an agent. ... you still get validated JSON matching your schema…”

   proof ↗⚑ flag

   Google ADK~partialclaimed5/10

   ADK exposes general extensibility hooks—Callbacks to intercept execution events for custom logic/side-effects, Plugins for pre-packaged behaviors, and a Tool Confirmation (HITL) flow that can guard tool execution—which developers could use to build input/output guardrails, but there is no dedicated 'guardrails' feature, built-in content-safety/validation API, or example showing blocking/transforming unsafe content end-to-end. Missing for 10: explicit guardrail/validation API or moderation integration, documented examples of blocking/transforming unsafe input or output, and any third-party/community confirmation of this pattern in practice.

   • [claimed-docs] “Callbacks: Hook into specific events during an agent's execution lifecycle to add logging, monitoring, or custom side-effects without alteri…”
   • [claimed-docs] “Plugins: Integrate complex, pre-packaged behaviors and third-party services directly into your agent's workflow.”
   • [github] “Tool Confirmation: A tool confirmation flow (HITL) that can guard tool execution with explicit confirmation and custom input.”
   • [github] “A tool confirmation flow (HITL) that can guard tool execution with explicit confirmation and custom input.”

   proof ↗⚑ flag

2. engineering-leadRestrict what an agent may do with fine-grained tool permissions and sandboxed execution

   weight 2 · round to Claude Agent SDK
   Claude Agent SDK✓fullclaimed8/10

   Docs describe granular permission modes, rules, and a canUseTool runtime callback (permissions.md), hooks that can block dangerous operations before execution (hooks.md), and hosting guidance covering multi-tenant isolation via Docker, Kubernetes, and sandbox providers (hosting.md) — directly matching fine-grained tool control plus sandboxed execution. Missing for 10: independent/hands-on verification that sandbox isolation holds up in production and more detail on the exact rule syntax for per-tool allow/deny policies.

   • [claimed-docs] “The Claude Agent SDK provides permission controls to manage how Claude uses tools. Use permission modes and rules to define what's allowed a…”
   • [claimed-docs] “Pass a canUseTool callback in your query options. The callback fires whenever Claude needs user input, receiving the tool name and input as …”
   • [claimed-docs] “With hooks, you can: Block dangerous operations before they execute, like destructive shell commands or unauthorized file access”
   • [claimed-docs] “Deploy the Agent SDK in production: subprocess architecture, session persistence, scaling, observability, and multi-tenant isolation for Doc…”
   • [claimed-docs] “The Agent SDK spawns and supervises a claude CLI subprocess that owns a shell, a working directory, and session files on disk.”
   • [claimed-docs] “The Claude Agent SDK provides permission controls to manage how Claude uses tools.”

   proof ↗⚑ flag

   Google ADK~partialclaimed4/10

   ADK provides a Tool Confirmation (HITL) flow that can gate tool execution with explicit confirmation/custom input, plus callbacks/plugins hooks to intercept agent actions, giving some control over agent behavior. However there is no evidence of fine-grained per-tool permission policies or an actual sandboxed execution environment for code/tool runs. Missing for 10: explicit sandboxing of tool/code execution, a permissions/ACL system scoping tool access, and independent verification of these guardrails in practice.

   • [github] “Tool Confirmation: A tool confirmation flow (HITL) that can guard tool execution with explicit confirmation and custom input.”
   • [github] “A tool confirmation flow (HITL) that can guard tool execution with explicit confirmation and custom input.”
   • [claimed-docs] “Callbacks: Hook into specific events during an agent's execution lifecycle to add logging, monitoring, or custom side-effects without alteri…”
   • [claimed-docs] “Plugins: Integrate complex, pre-packaged behaviors and third-party services directly into your agent's workflow.”

   proof ↗⚑ flag

Approval flows

1. developerPause an agent mid-run for human input or approval and resume with the human's decision

   weight 3 · round drawn
   Claude Agent SDK✓fullclaimed8/10

   The SDK explicitly supports pausing for human approval via the canUseTool callback and AskUserQuestion tool, which fires whenever Claude needs user input, and lets developers surface approval requests/clarifying questions and return the human's decision back to the SDK to resume execution. Permission modes/rules and hooks further allow blocking operations pending human input, and streaming mode supports long-lived interactive sessions that handle interruptions and permission requests. missing for 10: no independent/hands-on corroboration of the pause-resume UX in practice, and no explicit example showing resumption after a long delay or across process restarts specifically for approval workflows.

   • [claimed-docs] “Pass a canUseTool callback in your query options. The callback fires whenever Claude needs user input, receiving the tool name and input as …”
   • [claimed-docs] “Claude requests user input in two situations: when it needs permission to use a tool (like deleting files or running commands), and when it …”
   • [claimed-docs] “Surface Claude's approval requests and clarifying questions to users, then return their decisions to the SDK.”
   • [claimed-docs] “The Claude Agent SDK provides permission controls to manage how Claude uses tools. Use permission modes and rules to define what's allowed a…”
   • [claimed-docs] “It allows the agent to operate as a long lived process that takes in user input, handles interruptions, surfaces permission requests, and ha…”
   • [claimed-docs] “With hooks, you can: Block dangerous operations before they execute, like destructive shell commands or unauthorized file access”

   proof ↗⚑ flag

   Google ADK✓fullclaimed8/10

   ADK explicitly documents a Tool Confirmation flow described as HITL that can 'guard tool execution with explicit confirmation and custom input,' plus a Workflow Runtime and Task API both explicitly listing human-in-the-loop support with state management for pausing and resuming execution. This directly matches pausing mid-run for human approval and resuming with the decision, though missing for 10: a concrete end-to-end code example showing pause/resume state persistence and independent third-party corroboration beyond vendor GitHub README claims.

   • [github] “Tool Confirmation: A tool confirmation flow (HITL) that can guard tool execution with explicit confirmation and custom input.”
   • [github] “A tool confirmation flow (HITL) that can guard tool execution with explicit confirmation and custom input.”
   • [github] “Workflow Runtime: A graph-based execution engine for composing deterministic execution flows for agentic apps, with support for routing, fan…”
   • [github] “A graph-based execution engine for composing deterministic execution flows for agentic apps, with support for routing, fan-out/fan-in, loops…”
   • [github] “Task API: Structured agent-to-agent delegation with multi-turn task mode, single-turn controlled output, mixed delegation patterns, human-in…”
   • [github] “Structured agent-to-agent delegation with multi-turn task mode, single-turn controlled output, mixed delegation patterns, human-in-the-loop,…”

   proof ↗⚑ flag

2. engineering-leadRequire human approval before specific sensitive tool calls execute

   weight 2 · round drawn
   Claude Agent SDK✓fullclaimed8/10

   The SDK provides a documented canUseTool callback that fires when Claude needs permission for a sensitive tool call, allowing engineering leads to intercept and require approval before execution, plus hooks that can block operations before they run and permission modes/rules for fine-grained control. missing for 10: independent/hands-on corroboration of the approval flow in production and more detail on configuring which specific tools trigger approval vs. auto-allow.

   • [claimed-docs] “The Claude Agent SDK provides permission controls to manage how Claude uses tools. Use permission modes and rules to define what's allowed a…”
   • [claimed-docs] “Pass a canUseTool callback in your query options. The callback fires whenever Claude needs user input, receiving the tool name and input as …”
   • [claimed-docs] “Claude requests user input in two situations: when it needs permission to use a tool (like deleting files or running commands), and when it …”
   • [claimed-docs] “With hooks, you can: Block dangerous operations before they execute, like destructive shell commands or unauthorized file access”
   • [claimed-docs] “Surface Claude's approval requests and clarifying questions to users, then return their decisions to the SDK.”

   proof ↗⚑ flag

   Google ADK✓fullclaimed8/10

   ADK explicitly documents a 'Tool Confirmation' HITL flow that guards tool execution with explicit confirmation and custom input, plus broader human-in-the-loop support in its workflow/task orchestration engines, directly matching the story of requiring approval before sensitive tool calls execute. Missing for 10: no independent/hands-on validation or detailed walkthrough of configuring per-tool approval policies beyond the feature summary.

   • [github] “Tool Confirmation: A tool confirmation flow (HITL) that can guard tool execution with explicit confirmation and custom input.”
   • [github] “A tool confirmation flow (HITL) that can guard tool execution with explicit confirmation and custom input.”
   • [github] “Workflow Runtime: A graph-based execution engine for composing deterministic execution flows for agentic apps, with support for routing, fan…”
   • [github] “A graph-based execution engine for composing deterministic execution flows for agentic apps, with support for routing, fan-out/fan-in, loops…”
   • [github] “Task API: Structured agent-to-agent delegation with multi-turn task mode, single-turn controlled output, mixed delegation patterns, human-in…”
   • [github] “Structured agent-to-agent delegation with multi-turn task mode, single-turn controlled output, mixed delegation patterns, human-in-the-loop,…”

   proof ↗⚑ flag

Memory

1. developerTrim, summarize, or filter conversation history to keep an agent inside its context window

   weight 2 · round to Google ADK
   Claude Agent SDK~partialclaimed4/10

   Docs mention the SDK provides the same 'context management' as Claude Code and that subagents can be used to isolate context for subtasks, implying some context-window management exists, but no explicit API for trimming, summarizing, or filtering conversation history is documented. Missing for 10: explicit compaction/summarization API, documented context-window truncation controls, and independent confirmation that developers can programmatically filter history.

   • [claimed-docs] “The Agent SDK gives you the same tools, agent loop, and context management that power Claude Code, programmable in Python and TypeScript.”
   • [claimed-docs] “Subagents are separate agent instances that your main agent can spawn to handle focused subtasks. Use them to isolate context, run multiple …”
   • [claimed-docs] “A session is the conversation history the SDK accumulates while your agent works. ... The SDK writes it to disk automatically so you can ret…”
   • [claimed-docs] “Fork is different: it creates a new session that starts with a copy of the original's history. The original stays”

   proof ↗⚑ flag

   Google ADK✓fullclaimed7/10

   ADK docs explicitly state it "automatically filters irrelevant events, summarizes older conversational turns, lazy-loads artifacts, and tracks token usage," directly addressing trimming/summarizing/filtering to manage context window, reinforced by mention of designing for AI context window limits. Missing for 10: no code example/API reference showing how a developer configures or customizes this summarization/filtering behavior, and no independent/hands-on corroboration beyond first-party docs.

   • [claimed-docs] “ADK automatically filters irrelevant events, summarizes older conversational turns, lazy-loads artifacts, and tracks token usage.”
   • [claimed-docs] “Use prebuilt or custom Agent Skills to extend agent capabilities in a way that works efficiently inside AI context window limits.”

   proof ↗⚑ flag

2. developerGive agents long-term memory that persists across sessions and threads

   weight 2 · round to Claude Agent SDK
   Claude Agent SDK~partialclaimed6/10

   Sessions persist conversation history to disk and can be resumed with full prior context (docs-7, docs-16, docs-24), and SessionStore lets you mirror transcripts to external backends for cross-host resumption (docs-29). However this is session/thread-level persistence rather than true cross-session long-term memory (e.g. semantic memory, facts recalled across unrelated threads); CLAUDE.md/rules provide some persistent instructions but not dynamic memory. missing for 10: dedicated long-term/semantic memory store distinct from raw transcript replay, cross-thread memory retrieval mechanism, independent verification of persistence working reliably in production.

   • [claimed-docs] “A session is the conversation history the SDK accumulates while your agent works. ... The SDK writes it to disk automatically so you can ret…”
   • [claimed-docs] “A session is the conversation history the SDK accumulates while your agent works... The SDK writes it to disk automatically so you can retur…”
   • [claimed-docs] “Returning to a session means the agent has full context from before: files it already read, analysis it already performed, decisions it alre…”
   • [claimed-docs] “A `SessionStore` adapter lets you mirror those transcripts to your own backend, such as an object store, a key-value store, or a database, s…”
   • [claimed-docs] “The Agent SDK is built on the same foundation as Claude Code, which means your SDK agents have access to the same filesystem-based features:…”

   proof ↗⚑ flag

   Google ADK~partialclaimed3/10

   The docs mention session-based interactions and automatic context management (filtering irrelevant events, summarizing older turns, tracking token usage) but there is no explicit evidence of a dedicated long-term memory service or store that persists agent knowledge across separate sessions/threads. missing for 10: explicit memory/session-store API docs, cross-session persistence guarantees, first-party examples of retrieving memory in a new thread.

   • [claimed-docs] “ADK automatically filters irrelevant events, summarizes older conversational turns, lazy-loads artifacts, and tracks token usage.”
   • [claimed-docs] “This approach involves creating individual test files, each representing a single, simple agent-model interaction (a session).”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Claude Agent SDK
   Claude Agent SDK~partialcommunity7/10

   Docs explicitly claim the SDK exposes 'the same tools, agent loop, and context management that power Claude Code' and shares 'the same foundation... CLAUDE.md, skills, hooks' as the CLI/UI, suggesting strong feature parity between API and interactive UI. However, community reports describe the default programmatic harness as having 'poor DX,' 'zero observability,' and being 'garbage' for surfacing tool-call detail compared to interactive use, and note new subscription-usage restrictions on SDK-driven apps, indicating parity in practice is imperfect. Missing for 10: independent verification that every UI-only feature (e.g. full interactive session UX, all slash-commands) is reachable via API, and resolution of the observability/extensibility gaps raised by developers.

   • [claimed-docs] “The Agent SDK gives you the same tools, agent loop, and context management that power Claude Code, programmable in Python and TypeScript.”
   • [claimed-docs] “The Agent SDK is built on the same foundation as Claude Code, which means your SDK agents have access to the same filesystem-based features:…”
   • [community] “There is no difference between claude -p and typing into their 'harness' in tmux. They want to make you pay for API which is subsidizing the…”
   • [community] “I've been using claude -p with a harness called codelayer. Their [default] harness is completely garbage when it comes at displaying full de…”

   proof ↗⚑ flag

   Google ADK~partialprobed5/10

   ADK is primarily a code-first Python framework where agents are built and orchestrated programmatically (Agent(), Workflow Runtime, Task API), and the CLI (adk run/web/eval/deploy) exposes most dev-loop actions including the same UI functions, suggesting reasonable parity between programmatic/CLI and the built-in dev UI. However, there's no evidence of a documented REST/OpenAPI API for driving the dev UI's specific features programmatically, and probes show no OpenAPI spec or llms.txt discoverability. missing for 10: explicit API/CLI parity documentation for every dev-UI feature (debug, evaluate, showcase), a published OpenAPI/REST spec, and confirmation that UI-only actions (e.g. visual debugging, showcase mode) are fully scriptable.

   • [github] “A built-in development UI to help you test, evaluate, debug, and showcase your agent(s).”
   • [github] “Web UI (supports multi-agent directories or pointing directly to a single agent folder)”
   • [github] “adk run path/to/my_agent”
   • [github] “adk run path/to/my_agent # Web UI (supports multi-agent directories or pointing directly to a single agent folder) adk web path/to/agents_d…”
   • [github] “adk eval \ samples_for_testing/hello_world \ samples_for_testing/hello_world/hello_world_eval_set_001.evalset.json”
   • [github] “adk deploy docker --with_ui <agent-folder>”
   • [probe] “PROBE openapi: all candidate paths 404 (https://google.github.io/openapi.json, https://google.github.io/swagger.json, https://google.github.…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://google.github.io/llms.txt”

   proof ↗⚑ flag

2. ai-native userRead the product's source under an open license

   weight 2 · round to Google ADK
   Claude Agent SDK—none0/10

   There is no evidence the Claude Agent SDK's source is released under an open license; the Python/TypeScript SDK wraps a proprietary bundled Claude Code CLI and no license/open-source repo details are provided beyond a GitHub package listing. Community evidence even discusses restrictive usage terms, further indicating a closed, controlled distribution model rather than open-source code.

   • [github] “The Claude Code CLI is automatically bundled with the package - no separate installation required! The SDK will use the bundled CLI by defau…”
   • [community] “You can no longer use your Claude subscription with apps that use the Claude Agent SDK, e.g. claude -p, Conductor, T3code, etc.”
   • [community] “There is no difference between claude -p and typing into their 'harness' in tmux. They want to make you pay for API which is subsidizing the…”

   proof ↗⚑ flag

   Google ADK✓fullclaimed7/10

   The evidence repeatedly links to the public GitHub repository https://github.com/google/adk-python, which hosts the full source code and CLI (adk run, adk web, adk eval, adk deploy) that AI-native users can read and inspect directly. Missing for 10: an explicit citation of the license file/type (e.g., Apache-2.0) confirming the open-license terms, and independent third-party confirmation of licensing.

   • [github] “Agent Config: Build agents without code.”
   • [github] “A built-in development UI to help you test, evaluate, debug, and showcase your agent(s).”
   • [github] “adk run path/to/my_agent”
   • [github] “adk run path/to/my_agent # Web UI (supports multi-agent directories or pointing directly to a single agent folder) adk web path/to/agents_d…”

   proof ↗⚑ flag

3. ai-native userSelf-host the core product

   weight 3 · round to Google ADK
   Claude Agent SDK—none0/10

   The SDK's 'hosting' docs only describe deploying the wrapper application (Docker/Kubernetes/subprocess supervision) — the core product itself, the Claude model, remains a hosted Anthropic service accessed via subscription/API, and community evidence confirms usage is gated by Anthropic's cloud plans and subject to policy restrictions, not something a user can run independently. No evidence describes self-hosting Claude's weights or inference outside Anthropic's infrastructure.

   • [claimed-docs] “Deploy the Agent SDK in production: subprocess architecture, session persistence, scaling, observability, and multi-tenant isolation for Doc…”
   • [claimed-docs] “The Agent SDK spawns and supervises a claude CLI subprocess that owns a shell, a working directory, and session files on disk.”
   • [community] “You can no longer use your Claude subscription with apps that use the Claude Agent SDK, e.g. claude -p, Conductor, T3code, etc.”
   • [community] “Currently the credit doesn't apply to interactive Claude Code, web/desktop/mobile apps, Claude Cowork, etc. Next month, interactive claude c…”
   • [community] “My frustration with Anthropic has been around the uncertainty of all of this. What constitutes fair usage, what can I play with and not risk…”

   proof ↗⚑ flag

   Google ADK✓fullclaimed8/10

   ADK is an open-source framework (github.com/google/adk-python) that can be run entirely locally via `adk run`/`adk web`, packaged into containers, and deployed offline/disconnected from Google Cloud, evidencing full self-hosting capability without requiring the vendor's managed service. Missing for 10: no independent third-party report confirming a full self-hosted production deployment, and no explicit self-hosted infra requirements/scaling guidance beyond container packaging.

   • [claimed-docs] “This is a good option if you prefer to run offline or disconnected, or otherwise in a system that has no connection to Google Cloud.”
   • [claimed-docs] “You can manually package your Agent into a container image and then run it in any environment that supports container images.”
   • [github] “adk run path/to/my_agent”
   • [github] “adk run path/to/my_agent # Web UI (supports multi-agent directories or pointing directly to a single agent folder) adk web path/to/agents_d…”
   • [github] “adk deploy docker --with_ui <agent-folder>”
   • [claimed-docs] “GKE is a good option if you need more control over the deployment as well as for running Open Models.”

   proof ↗⚑ flag

Multi agent

1. developerOrchestrate multiple agents — handoffs, subagents, or crews — inside one workflow

   weight 3 · round to Google ADK
   Claude Agent SDK✓fullclaimed8/10

   Docs explicitly cover subagents spawned by a main agent for parallel/focused subtasks, hooks to coordinate/intercept events, session forking to branch workflows, and MCP integration — together supporting multi-agent orchestration within one workflow. Missing for 10: independent hands-on validation of complex multi-agent crews/handoffs beyond first-party docs, and no explicit named 'handoff' primitive comparable to other agent frameworks.

   • [claimed-docs] “Subagents are separate agent instances that your main agent can spawn to handle focused subtasks. Use them to isolate context, run multiple …”
   • [claimed-docs] “Subagents are separate agent instances that your main agent can spawn to handle focused subtasks.”
   • [claimed-docs] “Hooks are callback functions that run your code in response to agent events, like a tool being called, a session starting, or execution stop…”
   • [claimed-docs] “With hooks, you can: Block dangerous operations before they execute, like destructive shell commands or unauthorized file access”
   • [claimed-docs] “Fork is different: it creates a new session that starts with a copy of the original's history. The original stays”
   • [claimed-docs] “With MCP, your agent can query databases, integrate with APIs like Slack and GitHub, and connect to other services without writing custom to…”

   proof ↗⚑ flag

   Google ADK✓fullclaimed9/10

   ADK explicitly supports multi-agent orchestration: workflows are defined as any application with more than one agent/node, with a graph-based Workflow Runtime supporting routing, fan-out/fan-in, loops, nested workflows, and a Task API for structured agent-to-agent delegation including multi-turn task mode and mixed delegation patterns; the CLI/Web UI explicitly supports multi-agent directories. missing for 10: independent third-party hands-on validation of complex multi-agent orchestration at scale.

   • [claimed-docs] “you can use the ADK development framework to expand them into workflows, which allow you to combine and orchestrate multiple agents and code…”
   • [claimed-docs] “In ADK, any agent application that has more than one agent or executable Node is considered a workflow.”
   • [github] “Workflow Runtime: A graph-based execution engine for composing deterministic execution flows for agentic apps, with support for routing, fan…”
   • [github] “Task API: Structured agent-to-agent delegation with multi-turn task mode, single-turn controlled output, mixed delegation patterns, human-in…”
   • [github] “Structured agent-to-agent delegation with multi-turn task mode, single-turn controlled output, mixed delegation patterns, human-in-the-loop,…”
   • [github] “adk run path/to/my_agent # Web UI (supports multi-agent directories or pointing directly to a single agent folder) adk web path/to/agents_d…”

   proof ↗⚑ flag

Workflow control

1. developerCompose agents into an explicit graph or workflow with branching, loops, and parallel steps

   weight 2 · round to Google ADK
   Claude Agent SDK~partialclaimed4/10

   The SDK supports spawning subagents for parallel subtasks and gives developers full Python/TypeScript control flow (which can express branching/loops in code), but there is no documented explicit graph/workflow abstraction (nodes, edges, conditional branches, loop constructs) as a first-class SDK feature. Missing for 10: a dedicated workflow/graph API, documented branching/loop primitives, and independent examples of complex multi-step orchestration graphs beyond simple subagent spawning.

   • [claimed-docs] “Subagents are separate agent instances that your main agent can spawn to handle focused subtasks. Use them to isolate context, run multiple …”
   • [claimed-docs] “Subagents are separate agent instances that your main agent can spawn to handle focused subtasks.”
   • [claimed-docs] “The Agent SDK gives you the same tools, agent loop, and context management that power Claude Code, programmable in Python and TypeScript.”
   • [claimed-docs] “Use ClaudeSDKClient for interactive applications such as chat interfaces, or when the next action depends on Claude's response.”

   proof ↗⚑ flag

   Google ADK✓fullclaimed9/10

   ADK provides a dedicated graph-based Workflow Runtime with explicit support for routing, fan-out/fan-in (parallel), loops, retry, nested workflows, and dynamic nodes, plus structured Task API for agent delegation and workflow nodes—directly matching branching/loops/parallel composition; docs also describe 'graph-based architectures with explicit execution paths.' Missing for 10: independent/hands-on third-party validation beyond vendor docs and GitHub README.

   • [github] “Workflow Runtime: A graph-based execution engine for composing deterministic execution flows for agentic apps, with support for routing, fan…”
   • [github] “A graph-based execution engine for composing deterministic execution flows for agentic apps, with support for routing, fan-out/fan-in, loops…”
   • [github] “Task API: Structured agent-to-agent delegation with multi-turn task mode, single-turn controlled output, mixed delegation patterns, human-in…”
   • [github] “Structured agent-to-agent delegation with multi-turn task mode, single-turn controlled output, mixed delegation patterns, human-in-the-loop,…”
   • [claimed-docs] “Weave deterministic code with adaptive AI reasoning. Orchestrate complex tasks through structured, graph-based architectures, with explicit …”
   • [claimed-docs] “In ADK, any agent application that has more than one agent or executable Node is considered a workflow.”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   Claude Agent SDK—none0/10

   No evidence in the pack addresses data residency, regional storage selection, or compliance controls for where data/sessions are stored; docs mention local disk session storage and a SessionStore adapter but nothing about choosing a geographic region.

   ⚑ flag

   Google ADK—none0/10

   ADK is a framework that can be deployed via Cloud Run, GKE, or self-hosted/offline (google-adk-docs-7, google-adk-docs-14, google-adk-docs-19), which implies developers control infrastructure location, but there is no explicit documentation about data residency, region selection, or storage location controls for agent data.

   • [claimed-docs] “This is a good option if you prefer to run offline or disconnected, or otherwise in a system that has no connection to Google Cloud.”
   • [claimed-docs] “Cloud Run is a managed auto-scaling compute platform on Google Cloud that enables you to run your agent as a container-based application.”
   • [claimed-docs] “GKE is a good option if you need more control over the deployment as well as for running Open Models.”

   proof ↗⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Claude Agent SDK—none0/10

   The evidence describes session persistence and a SessionStore adapter for mirroring transcripts to a user's own backend, but nothing addresses data retention policies, deletion controls, or how long Anthropic/the SDK retains data. missing for 10: any documentation on data retention periods, explicit deletion APIs/commands, or privacy/compliance controls governing stored conversation or tool-use data.

   • [claimed-docs] “A session is the conversation history the SDK accumulates while your agent works. ... The SDK writes it to disk automatically so you can ret…”
   • [claimed-docs] “A `SessionStore` adapter lets you mirror those transcripts to your own backend, such as an object store, a key-value store, or a database, s…”

   proof ↗⚑ flag

   Google ADK—none0/10

   The evidence describes ADK as a self-hosted/deployable agent framework (Cloud Run, GKE, offline/disconnected deployment) but contains no documentation of explicit data retention policies, session/state deletion APIs, or user-facing controls for purging stored data. missing for 10: explicit retention/deletion controls, session data lifecycle docs, any privacy/compliance statements about stored artifacts or memory.

   • [claimed-docs] “This is a good option if you prefer to run offline or disconnected, or otherwise in a system that has no connection to Google Cloud.”
   • [claimed-docs] “ADK automatically filters irrelevant events, summarizes older conversational turns, lazy-loads artifacts, and tracks token usage.”

   proof ↗⚑ flag

3. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Claude Agent SDK—none0/10

   No evidence in the pack mentions telemetry, usage tracking, opt-out settings, or privacy controls for the Agent SDK; the docs cover tools, hooks, sessions, permissions, and hosting but never data-collection controls.

   ⚑ flag

   Google ADK—none0/10

   No evidence in the pack addresses telemetry collection or an opt-out mechanism for ADK; the docs cover agent building, deployment, evaluation, and workflows but never mention usage tracking or privacy controls. This is a fair axis for a developer framework/SDK, but absence of evidence means it counts as none. missing for 10: any mention of telemetry collection, an opt-out flag/env var, or a privacy policy describing data tracking.

   ⚑ flag

Durable state

1. developerCheckpoint agent state so a run can resume exactly where it left off after a crash or restart

   weight 3 · round to Claude Agent SDK
   Claude Agent SDK✓fullclaimed7/10

   Docs describe sessions being written to disk automatically, resumable with full prior context, forkable, and a SessionStore adapter to persist transcripts to external backends so a session can resume on a different host — directly matching checkpoint/resume-after-crash needs, and hosting docs explicitly call out 'session persistence' as a production concern. Missing for 10: independent/hands-on confirmation that resume restores in-flight tool/subprocess state after an actual crash (not just conversation history), and any benchmark showing exact-resume fidelity.

   • [claimed-docs] “A session is the conversation history the SDK accumulates while your agent works. ... The SDK writes it to disk automatically so you can ret…”
   • [claimed-docs] “A session is the conversation history the SDK accumulates while your agent works... The SDK writes it to disk automatically so you can retur…”
   • [claimed-docs] “Returning to a session means the agent has full context from before: files it already read, analysis it already performed, decisions it alre…”
   • [claimed-docs] “A `SessionStore` adapter lets you mirror those transcripts to your own backend, such as an object store, a key-value store, or a database, s…”
   • [claimed-docs] “Fork is different: it creates a new session that starts with a copy of the original's history. The original stays”
   • [claimed-docs] “Deploy the Agent SDK in production: subprocess architecture, session persistence, scaling, observability, and multi-tenant isolation for Doc…”
   • [claimed-docs] “The Agent SDK spawns and supervises a claude CLI subprocess that owns a shell, a working directory, and session files on disk.”

   proof ↗⚑ flag

   Google ADK—none0/10

   Evidence only mentions generic 'state management' as one feature in the workflow runtime engine, with no documentation of session/state persistence, checkpointing, or resuming an agent run after a crash or restart. Missing for 10: explicit checkpoint/save-state API, resume-from-crash mechanism, persistence backend documentation, and any hands-on confirmation of durable resumption.

   • [github] “Workflow Runtime: A graph-based execution engine for composing deterministic execution flows for agentic apps, with support for routing, fan…”
   • [github] “A graph-based execution engine for composing deterministic execution flows for agentic apps, with support for routing, fan-out/fan-in, loops…”
   • [claimed-docs] “ADK automatically filters irrelevant events, summarizes older conversational turns, lazy-loads artifacts, and tracks token usage.”

   proof ↗⚑ flag

2. engineering-leadRun long-lived agents durably across process restarts and deploys, natively or via durable-execution integrations

   weight 2 · round to Claude Agent SDK
   Claude Agent SDK~partialclaimed7/10

   The SDK documents native session persistence (auto-written to disk, resumable/forkable) plus a SessionStore adapter for mirroring transcripts to external stores so sessions can resume across hosts, and hosting docs cover session persistence, scaling, and multi-tenant isolation for Docker/Kubernetes deploys — directly supporting durability across restarts and redeploys. However, there is no mention of integration with dedicated durable-execution frameworks (e.g., Temporal/Restate) and no independent/hands-on evidence validating resilience across actual crash/restart scenarios. Missing for 10: durable-execution framework integrations, independent verification of crash/restart resilience.

   • [claimed-docs] “A session is the conversation history the SDK accumulates while your agent works. ... The SDK writes it to disk automatically so you can ret…”
   • [claimed-docs] “A session is the conversation history the SDK accumulates while your agent works... The SDK writes it to disk automatically so you can retur…”
   • [claimed-docs] “Returning to a session means the agent has full context from before: files it already read, analysis it already performed, decisions it alre…”
   • [claimed-docs] “A `SessionStore` adapter lets you mirror those transcripts to your own backend, such as an object store, a key-value store, or a database, s…”
   • [claimed-docs] “Deploy the Agent SDK in production: subprocess architecture, session persistence, scaling, observability, and multi-tenant isolation for Doc…”
   • [claimed-docs] “The Agent SDK spawns and supervises a claude CLI subprocess that owns a shell, a working directory, and session files on disk.”

   proof ↗⚑ flag

   Google ADK~partialclaimed3/10

   ADK's Workflow Runtime mentions 'state management' and 'retry' in its graph-based execution engine, and deployment docs describe scalable hosting (Agent Runtime, Cloud Run), but there is no explicit evidence of session/state persistence surviving process restarts or redeploys, nor any named durable-execution integration (e.g., Temporal, Cloud Workflows checkpointing). Missing for 10: documented durable state store or checkpoint/resume mechanism, explicit claim of surviving restarts/redeploys, and any third-party durable-execution integration.

   • [github] “Workflow Runtime: A graph-based execution engine for composing deterministic execution flows for agentic apps, with support for routing, fan…”
   • [claimed-docs] “Agent Runtime is a fully managed auto-scaling service on Google Cloud specifically designed for deploying, managing, and scaling AI agents b…”
   • [claimed-docs] “Cloud Run is a managed auto-scaling compute platform on Google Cloud that enables you to run your agent as a container-based application.”
   • [claimed-docs] “ADK automatically filters irrelevant events, summarizes older conversational turns, lazy-loads artifacts, and tracks token usage.”

   proof ↗⚑ flag

Streaming

1. developerStream tokens and intermediate agent events (tool calls, steps) to my UI in real time

   weight 3 · round to Claude Agent SDK
   Claude Agent SDK✓fullclaimed8/10

   Docs explicitly describe streaming input mode as the preferred method for real-time interactive apps, a dedicated streaming-output guide showing how to enable token-level streaming via include_partial_messages/includePartialMessages, plus hooks and canUseTool callbacks that surface tool-call and step events during execution, directly matching the story. missing for 10: independent hands-on corroboration of real-time UI streaming quality, and no explicit end-to-end UI code example beyond flag/callback docs

   • [claimed-docs] “To enable streaming, set `include_partial_messages` (Python) or `includePartialMessages` (TypeScript) to `true` in your options.”
   • [claimed-docs] “Streaming input mode is the preferred way to use the Claude Agent SDK. It provides full access to the agent's capabilities and enables rich,…”
   • [claimed-docs] “It allows the agent to operate as a long lived process that takes in user input, handles interruptions, surfaces permission requests, and ha…”
   • [claimed-docs] “Hooks are callback functions that run your code in response to agent events, like a tool being called, a session starting, or execution stop…”
   • [claimed-docs] “Pass a canUseTool callback in your query options. The callback fires whenever Claude needs user input, receiving the tool name and input as …”
   • [claimed-docs] “Use ClaudeSDKClient for interactive applications such as chat interfaces, or when the next action depends on Claude's response.”

   proof ↗⚑ flag

   Google ADK~partialclaimed4/10

   The evidence shows a built-in Web/dev UI (`adk web`) for testing/debugging agents and a Callbacks mechanism to hook into execution-lifecycle events (tool calls, steps), which implies some visibility into intermediate agent activity, but nothing explicitly documents token-level streaming to a custom UI (no mention of SSE/websocket/streaming API). missing for 10: explicit documentation of real-time token streaming API/protocol, evidence of streaming tool-call/step events to an arbitrary UI beyond the built-in dev UI, independent confirmation of streaming behavior.

   • [github] “A built-in development UI to help you test, evaluate, debug, and showcase your agent(s).”
   • [github] “Web UI (supports multi-agent directories or pointing directly to a single agent folder)”
   • [github] “adk run path/to/my_agent # Web UI (supports multi-agent directories or pointing directly to a single agent folder) adk web path/to/agents_d…”
   • [claimed-docs] “Callbacks: Hook into specific events during an agent's execution lifecycle to add logging, monitoring, or custom side-effects without alteri…”

   proof ↗⚑ flag

Structured output

1. developerGet schema-validated structured output from an agent, with automatic retries when validation fails

   weight 3 · round to Claude Agent SDK
   Claude Agent SDK~partialclaimed6/10

   Docs explicitly describe structured outputs with schema-validated JSON returned at the end of an agent run, confirming schema validation support, but no evidence describes automatic retry behavior when validation fails. missing for 10: explicit documentation of retry/re-prompt behavior on validation failure, and any independent/hands-on confirmation of retry mechanics.

   • [claimed-docs] “Structured outputs let you define the exact shape of data you want back from an agent. ... you still get validated JSON matching your schema…”
   • [claimed-docs] “Structured outputs let you define the exact shape of data you want back from an agent... you still get validated JSON matching your schema a…”
   • [claimed-docs] “Structured outputs let you define the exact shape of data you want back from an agent.”

   proof ↗⚑ flag

   Google ADK—none0/10

   No evidence in the pack mentions schema-validated structured output (e.g., Pydantic output_schema) or automatic retry-on-validation-failure behavior for ADK agents; the evidence covers agent setup, tools, workflows, deployment, and evaluation but not structured output validation. Missing for 10: any mention of output schema enforcement, structured output configuration, or validation-retry mechanism.

   ⚑ flag