LangGraph vs Google ADK

Agent access

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

   weight 2 · round to LangGraph
   LangGraph✓fullprobed9/10

   Probes confirm a live llms.txt at docs.langchain.com (HTTP 200) with a documentation index, and individual doc pages are available in agent-friendly .md format (e.g., overview.md) that explicitly reference the llms.txt index for further crawling — this is exactly the agent-oriented docs pattern the story asks for. Missing for 10: no independent/community confirmation of an agent actually consuming llms.txt successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.langchain.com/llms.txt # Docs by LangChain > Documentation for LangSmith, Fleet, and our open sour…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.langchain.com/oss/python/langgraph/overview.md > ## Documentation Index > Fetch the complete documen…”

   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 to Google ADK
   LangGraph~partialclaimed6/10

   LangGraph is a pip-installable Python library with a programmatic graph API (stream/astream, Command, checkpointers) and a CLI that builds/runs an Agent Server locally, all of which support non-interactive, scriptable execution suitable for CI/automation. However, there is no explicit documentation or example of running LangGraph in a CI pipeline or headless automation context specifically. Missing for 10: explicit CI/automation guide or example, documented headless/non-interactive invocation patterns, and independent evidence of real-world CI usage.

   • [github] “pip install -U langgraph”
   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally.”
   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally. The resulting server exposes all API endpoints for r…”
   • [claimed-docs] “LangGraph CLI** is a command-line tool for building and running the [Agent Server](/langsmith/agent-server) locally. The resulting server ex…”
   • [claimed-docs] “LangGraph graphs expose the stream (sync) and astream (async) methods to yield streamed outputs as iterators.”
   • [claimed-docs] “Checkpointers persist a thread's graph state as checkpoints. Use them for short-term, thread-scoped memory, including conversation continuit…”

   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 to Google ADK
   LangGraph✓fullclaimed6/10

   Docs confirm LangChain/LangGraph agents can consume MCP servers via MCPAdapter, which discovers a server's tools and adapts them into LangChain tools for use inside graphs. Missing for 10: deeper first-party walkthrough/code example of wiring an MCP server into a LangGraph agent, and independent/community corroboration of this working in practice.

   • [claimed-docs] “LangChain agents call tools defined on MCP servers through MCPAdapter, which discovers a server's tools and adapts them into LangChain tools…”

   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 userConnect an agent via an official MCP server

   weight 3 · round to Google ADK
   LangGraph—none0/10

   Evidence shows LangGraph/LangChain agents can act as MCP clients (via MCPAdapter, discovering and calling tools from external MCP servers), but there is no evidence LangGraph itself exposes an official MCP server that other agents could connect to. As a framework/platform (not itself an agent), shipping an official MCP server is a fair axis, but nothing in the evidence pack shows this capability.

   • [claimed-docs] “LangChain agents call tools defined on MCP servers through MCPAdapter, which discovers a server's tools and adapts them into LangChain tools…”

   proof ↗⚑ flag

   Google ADK~partialclaimed6/10

   ADK's official docs explicitly document how to expose ADK tools via an MCP server ('build an MCP server that wraps ADK tools, making them accessible to any MCP client'), showing the framework supports the server side of MCP, not just being an MCP client. However, this is a build-your-own-server guide rather than a turnkey, pre-hosted official MCP endpoint, so it requires developer setup work. Missing for 10: a ready-made hosted/official MCP server endpoint, independent hands-on confirmation that the generated server works reliably with third-party MCP clients.

   • [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.”
   • [claimed-docs] “An ADK agent can act as an MCP client and use tools provided by external MCP servers.”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round to LangGraph
   LangGraph✓fullprobed9/10

   LangGraph ships an official CLI (LangGraph CLI) documented for building and running the Agent Server locally, exposing API endpoints for runs, threads, assistants, etc., with supporting services like managed DB for checkpointing — confirmed by first-party docs and a live probe of the doc page. missing for 10: no independent/community hands-on confirmation of CLI usage beyond vendor docs.

   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally.”
   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally. The resulting server exposes all API endpoints for r…”
   • [claimed-docs] “LangGraph CLI** is a command-line tool for building and running the [Agent Server](/langsmith/agent-server) locally. The resulting server ex…”
   • [probe] “official CLI documented at https://docs.langchain.com/langsmith/cli”

   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

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

   weight 3 · round to LangGraph
   LangGraph~partialprobed7/10

   LangGraph's Python API (graph construction, streaming, persistence, interrupts) is extensively documented, and the LangGraph CLI/Agent Server exposes REST endpoints for runs, threads, and assistants (docs-30, docs-37), giving programmatic/API access beyond just an SDK. However, a probe for a formal OpenAPI/swagger spec returned 404 on all candidate paths, and community comments note documentation gaps and breaking changes, suggesting the 'public API' is real but not as formally discoverable as a REST-first product. Missing for 10: a published OpenAPI/swagger spec or API reference, and independent confirmation the Agent Server API is stable/production-documented rather than CLI-only.

   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally. The resulting server exposes all API endpoints for r…”
   • [claimed-docs] “LangGraph CLI** is a command-line tool for building and running the [Agent Server](/langsmith/agent-server) locally. The resulting server ex…”
   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.langchain.com/openapi.json, https://docs.langchain.com/swagger.json, https://docs.langc…”
   • [probe] “official CLI documented at https://docs.langchain.com/langsmith/cli”
   • [community] “I read the article but have yet to understand why someone would want to use a framework that introduces meaningless abstractions that are no…”
   • [claimed-docs] “LangGraph models agent workflows as graphs. You define the behavior of your agents using three key components: State, Nodes, Edges.”
   • [claimed-docs] “LangGraph graphs expose the stream (sync) and astream (async) methods to yield streamed outputs as iterators.”

   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

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

   weight 2 · round drawn
   LangGraph—none0/10

   No evidence in the pack addresses issuing scoped or least-privilege API credentials for an agent; LangGraph's docs cover orchestration, persistence, streaming, memory, and deployment but nothing about credential scoping or permission-limited API keys.

   ⚑ 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

8. ai-native userBuild against official SDKs

   weight 2 · round to Google ADK
   LangGraph✓fullprobed8/10

   LangGraph itself is shipped as an official, well-documented SDK/package (pip install langgraph) with extensive first-party API docs (graph API, persistence, streaming, interrupts), an official CLI/Agent Server, and GitHub-hosted source, all confirming it is a legitimate SDK for building AI-native agent systems. Missing for 10: evidence of official SDKs beyond Python (e.g., JS/TS parity claims) and independent hands-on validation of SDK API stability (community notes mention breaking changes/documentation gaps).

   • [github] “pip install -U langgraph”
   • [github] “LangGraph is a low-level orchestration framework for building, managing, and deploying long-running, stateful agents.”
   • [claimed-docs] “At its core, LangGraph models agent workflows as graphs. You define the behavior of your agents using three key components”
   • [claimed-docs] “LangGraph models agent workflows as graphs. You define the behavior of your agents using three key components: State, Nodes, Edges.”
   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally. The resulting server exposes all API endpoints for r…”
   • [probe] “official CLI documented at https://docs.langchain.com/langsmith/cli”
   • [community] “I read the article but have yet to understand why someone would want to use a framework that introduces meaningless abstractions that are no…”

   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

9. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   LangGraph—none0/10

   Evidence covers streaming, checkpointing, interrupts, and an Agent Server exposing API endpoints, but nowhere mentions webhook subscriptions or push-based event notifications for external systems. missing for 10: any documentation of a webhook registration/subscription mechanism, delivery guarantees, or event-push API.

   ⚑ 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 to LangGraph
   LangGraph~partialcommunity7/10

   LangGraph explicitly supports durable, long-running agent execution that persists through failures and resumes automatically, with checkpointing, human-in-the-loop interrupts, and a CLI/Agent Server for production deployment (langgraph-gh-6, langgraph-docs-13, langgraph-docs-30). This covers the core of 'autonomous background automation' but it is a low-level orchestration framework requiring developers to build and deploy the graph themselves rather than a turnkey scheduler/trigger system, and community feedback notes rough edges in streaming/persistence implementation (langgraph-comm-13). Missing for 10: built-in scheduling/trigger mechanisms for kicking off automations, independent hands-on verification of unattended long-running runs, and clearer distinction of 'autonomous' (no human) vs human-in-the-loop operation.

   • [github] “Durable execution — Build agents that persist through failures and can run for extended periods, automatically resuming from exactly where t…”
   • [github] “Production-ready deployment — Deploy sophisticated agent systems confidently with scalable infrastructure designed to handle the unique chal…”
   • [claimed-docs] “In production, use a checkpointer backed by a database: from langgraph.checkpoint.postgres import PostgresSaver”
   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally. The resulting server exposes all API endpoints for r…”
   • [claimed-docs] “Checkpointing keeps your place: the checkpointer writes the exact graph state so you can resume later, even when in an error state.”
   • [community] “The one thing I wish was better developed is persistence and streaming - they give sample code to stream, but it's essentially a complete im…”

   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 userOperate the product with natural-language commands

   weight 2 · round to Google ADK
   LangGraph—none0/10

   LangGraph is a code-first orchestration framework (graphs, nodes, edges, checkpointers, CLI for running a server) with no evidence of any natural-language command interface for operating the product itself — developers configure and run it via Python/JS APIs and CLI flags, not NL prompts. Missing for 10: any documented chat/NL interface, NL-driven graph builder, or NL-based CLI/administration capability.

   • [claimed-docs] “At its core, LangGraph models agent workflows as graphs. You define the behavior of your agents using three key components”
   • [claimed-docs] “LangGraph models agent workflows as graphs. You define the behavior of your agents using three key components: State, Nodes, Edges.”
   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally.”
   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally. The resulting server exposes all API endpoints for r…”

   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
   LangGraph—none0/10

   The evidence pack shows conventional markdown documentation and a probe confirming no OpenAPI/interactive API spec is published (all candidate paths 404). There is no mention of an interactive API reference or runnable examples/playground anywhere in the docs or GitHub materials.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.langchain.com/openapi.json, https://docs.langchain.com/swagger.json, https://docs.langc…”

   proof ↗⚑ 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
   LangGraph—none0/10

   While LangGraph's Agent Server is documented as exposing REST API endpoints for runs, threads, and assistants (langgraph-docs-30/37), no evidence shows a downloadable machine-readable spec (OpenAPI/Swagger) — a direct probe for openapi.json, swagger.json, and related paths returned 404 on all candidates (langgraph-probe-3). missing for 10: a documented OpenAPI/Swagger endpoint or downloadable spec file, any doc page referencing 'openapi' or 'swagger' for the Agent Server, confirmation from the actual running server rather than just the docs site.

   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally. The resulting server exposes all API endpoints for r…”
   • [claimed-docs] “LangGraph CLI** is a command-line tool for building and running the [Agent Server](/langsmith/agent-server) locally. The resulting server ex…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.langchain.com/openapi.json, https://docs.langchain.com/swagger.json, https://docs.langc…”

   proof ↗⚑ 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
   LangGraph~partialclaimed4/10

   LangGraph docs show a local/dev path (LangGraph CLI running the Agent Server locally, in-memory or dev checkpointers) distinct from a production database-backed checkpointer, which implies a way to iterate locally without touching production data, but there is no explicit 'sandbox environment' or test-data-isolation feature documented. missing for 10: no dedicated sandbox/staging environment concept, no explicit guidance on isolating test data from production, no independent confirmation that local runs are safely isolated from production stores.

   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally. The resulting server exposes all API endpoints for r…”
   • [claimed-docs] “LangGraph CLI** is a command-line tool for building and running the [Agent Server](/langsmith/agent-server) locally. The resulting server ex…”
   • [claimed-docs] “In production, use a checkpointer backed by a database: from langgraph.checkpoint.postgres import PostgresSaver”
   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally.”

   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
   LangGraph—none0/10

   The evidence pack contains no documentation of API versioning scheme or a formal deprecation policy for LangGraph's APIs; only general framework descriptions and a community complaint that the framework 'often introduces breaking changes' without being well documented, which is unrelated to any specific versioning/deprecation guarantee. This is an applicable axis for a developer framework/API, but no supporting evidence exists.

   • [community] “I read the article but have yet to understand why someone would want to use a framework that introduces meaningless abstractions that are no…”

   proof ↗⚑ 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 Google ADK
   LangGraph~partialcommunity4/10

   Evidence confirms LangGraph nodes/tools can be freely custom-coded (comm-10) and that tool integration exists via MCPAdapter (docs-22), implying developers can define custom tools, but the pack lacks any concrete code example showing typed tool definitions or a 'few lines of code' walkthrough for tool creation. Missing for 10: a documented tool-definition API/decorator with type hints, a minimal code snippet, and independent confirmation of ease-of-use for typed tools.

   • [community] “In langgraph nodes are just functions that can do whatever you want... you don't have to use langchain tools or ToolNode with langgraph, you…”
   • [claimed-docs] “LangChain agents call tools defined on MCP servers through MCPAdapter, which discovers a server's tools and adapts them into LangChain tools…”
   • [claimed-docs] “At its core, LangGraph models agent workflows as graphs. You define the behavior of your agents using three key components”
   • [claimed-docs] “LangGraph models agent workflows as graphs. You define the behavior of your agents using three key components: State, Nodes, Edges.”

   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
   LangGraph~partialprobed4/10

   An official LangGraph CLI is documented (installable, used to build/run the Agent Server locally), which is the kind of official tool a scaffold command would live in, but the evidence never shows a specific one-command project/template scaffolding action (e.g., `langgraph new`) — only server build/run functionality is described. missing for 10: explicit scaffold/template command documentation, a first-command quickstart example, independent confirmation it works as a one-command project generator.

   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally.”
   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally. The resulting server exposes all API endpoints for r…”
   • [claimed-docs] “LangGraph CLI** is a command-line tool for building and running the [Agent Server](/langsmith/agent-server) locally. The resulting server ex…”
   • [probe] “official CLI documented at https://docs.langchain.com/langsmith/cli”

   proof ↗⚑ 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
   LangGraph~partialprobed4/10

   LangGraph ships a CLI that runs an Agent Server locally and graphs expose sync/async invoke and stream methods that can be called headlessly from a terminal or script, which technically enables scripted verification runs. However, there is no evidence of a curated set of 'example agents' meant for headless self-verification, nor any documented workflow where an agent inspects its own build via terminal output. Missing for 10: dedicated example-agent scripts/quickstarts, explicit headless verification/testing workflow, and any first-party or community confirmation that agents use this for self-check.

   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally.”
   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally. The resulting server exposes all API endpoints for r…”
   • [claimed-docs] “LangGraph CLI** is a command-line tool for building and running the [Agent Server](/langsmith/agent-server) locally. The resulting server ex…”
   • [claimed-docs] “LangGraph graphs expose the stream (sync) and astream (async) methods to yield streamed outputs as iterators.”
   • [probe] “official CLI documented at https://docs.langchain.com/langsmith/cli”

   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 LangGraph
   LangGraph~partialclaimed3/10

   The only relevant evidence is a passing mention that the graph builder performs 'basic checks on the structure of your graph (no orphaned nodes, etc.)' at compile time, which is a thin form of build-time validation but not strict typing or schema validation of agent outputs/tools. No evidence describes typed state schemas, Pydantic/TypedDict validation, or static type-checking catching agent mistakes. missing for 10: explicit schema/type validation for node inputs-outputs, evidence of build-time type errors being caught, independent confirmation of this behavior in practice.

   • [claimed-docs] “It provides a few basic checks on the structure of your graph (no orphaned nodes, etc). It is also where you can specify runtime args like c…”

   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 Google ADK
   LangGraph—none0/10

   The evidence pack describes graph orchestration, streaming, checkpointing, memory, and human-in-the-loop features, and mentions internal parallel execution within a single graph (Pregel/BSP model), but there is no documentation of a bulk/batch API for invoking the graph across many independent items or records at once (e.g., a .batch()/.abatch() method or bulk import/export tooling). Missing for 10: explicit batch invocation API, bulk data import/export tooling, or evidence of processing many independent items concurrently as a first-class feature.

   • [community] “LangGraph implements a variant of the Pregel/BSP algorithm for orchestrating workflows with cycles (ie. not DAGs) and parallelism without da…”
   • [claimed-docs] “LangGraph graphs expose the stream (sync) and astream (async) methods to yield streamed outputs as iterators.”
   • [claimed-docs] “It exposes graph execution through stream modes such as updates, values, messages, custom, checkpoints, tasks, and debug.”

   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 to Google ADK
   LangGraph~partialclaimed4/10

   LangGraph's graph model (State, Nodes, Edges) and interrupts allow conditional routing and pausing at specific points, which can act like internal rules driving actions as state changes, and its Agent Server exposes API endpoints for runs/threads that could be invoked on external events. However, the evidence pack contains no explicit documentation of an event-trigger system (e.g., webhooks, schedules, external event listeners, conditional-edge rule definitions) that automatically fires actions outside of manually invoked graph runs. Missing for 10: explicit conditional-edge/rule syntax, documented external event triggers (webhook/cron), and evidence of automatic action firing without a user-initiated run.

   • [claimed-docs] “At its core, LangGraph models agent workflows as graphs. You define the behavior of your agents using three key components”
   • [claimed-docs] “By composing Nodes and Edges, you can create complex, looping workflows that evolve the state over time.”
   • [claimed-docs] “LangGraph models agent workflows as graphs. You define the behavior of your agents using three key components: State, Nodes, Edges.”
   • [claimed-docs] “Interrupts allow you to pause graph execution at specific points and wait for external input before continuing.”
   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally. The resulting server exposes all API endpoints for r…”

   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
   LangGraph—none0/10

   No evidence in the pack mentions cron-style scheduling, recurring triggers, or time-based/periodic job execution; LangGraph's docs focus on persistence, checkpointing, interrupts, streaming, and durable execution but not scheduled/recurring workflow invocation.

   ⚑ 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 to LangGraph
   LangGraph~partialclaimed5/10

   LangGraph's checkpointer/time-travel and interrupt features let developers pause for human review and resume or roll back to prior graph states, and LangSmith tracing gives visibility into execution paths, covering 'review' and partial 'rollback'. However there's no evidence of an explicit versioning system for automations (e.g., named/versioned assistant deployments, diffing or rollback UI) beyond code-level state checkpoints. missing for 10: explicit automation/version management (e.g., versioned assistants/deployments), a UI for reviewing/rolling back workflow versions, independent hands-on confirmation of rollback working in production.

   • [claimed-docs] “Checkpointers persist a thread's graph state as checkpoints. Use them for short-term, thread-scoped memory, including conversation continuit…”
   • [claimed-docs] “Checkpointing keeps your place: the checkpointer writes the exact graph state so you can resume later, even when in an error state.”
   • [github] “Seamlessly incorporate human oversight by inspecting and modifying agent state at any point during execution.”
   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally. The resulting server exposes all API endpoints for r…”
   • [claimed-docs] “Trace and compare these workflow patterns with LangSmith... Follow the tracing quickstart to see how data flows through each step.”

   proof ↗⚑ 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
   LangGraph~partialcommunity6/10

   Docs confirm a LangGraph CLI/Agent Server that exposes API endpoints for runs, threads, and assistants with managed checkpointing/storage (langgraph-docs-30/37/23), and GitHub claims 'production-ready deployment' with scalable infrastructure for stateful agents (langgraph-gh-9). However, a community engineer explicitly asks how to deploy LangGraph as a production API beyond 'langgraph serve' locally, suggesting the managed/production deployment path is not fully clear from hands-on experience (langgraph-comm-7). Missing for 10: independent hands-on confirmation of a hosted managed cloud runtime (vs. local CLI server), and details on production SLAs/scaling beyond marketing claims.

   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally. The resulting server exposes all API endpoints for r…”
   • [claimed-docs] “LangGraph CLI** is a command-line tool for building and running the [Agent Server](/langsmith/agent-server) locally. The resulting server ex…”
   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally.”
   • [github] “Production-ready deployment — Deploy sophisticated agent systems confidently with scalable infrastructure designed to handle the unique chal…”
   • [community] “How can one deploy LangGraph as an API (with production like features)? I have worked with langgraph serve to deploy locally, but are there …”

   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
   LangGraph✓fullcommunity7/10

   LangGraph is open-source, pip-installable, and includes a CLI to build/run the Agent Server locally with self-managed checkpointing via Postgres or other backends, meaning agents can run fully on self-hosted infra without the vendor's managed platform. However, evidence pack emphasizes LangSmith for tracing/debugging and doesn't explicitly discuss self-hosting at scale or full platform parity without LangSmith. missing for 10: independent verification of large-scale self-hosted production deployments, explicit statement that all deployment features (e.g., cron/scheduling, multi-tenant auth) work without LangSmith/LangGraph Platform, and clearer separation of open-source vs paid-platform features.

   • [github] “pip install -U langgraph”
   • [claimed-docs] “In production, use a checkpointer backed by a database: from langgraph.checkpoint.postgres import PostgresSaver”
   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally.”
   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally. The resulting server exposes all API endpoints for r…”
   • [claimed-docs] “LangGraph CLI** is a command-line tool for building and running the [Agent Server](/langsmith/agent-server) locally. The resulting server ex…”
   • [community] “How can one deploy LangGraph as an API (with production like features)? I have worked with langgraph serve to deploy locally, but are there …”

   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
   LangGraph—none0/10

   The evidence pack contains no documentation or examples showing that LangGraph nodes use a provider-agnostic model interface (e.g., a single call that can swap between OpenAI, Anthropic, etc. without code changes); it focuses on graph structure, checkpointing, streaming, and human-in-the-loop features, not model abstraction. A stray community comment about 'bring your own keys' apps is too thin and non-technical to establish this capability. missing for 10: any docs on a unified chat-model interface, model-swap examples, or provider abstraction demonstrating no-rewrite portability.

   • [community] “The use case where they are helpful is 'bring your own keys' apps... The abstraction is very much worth it for me. That said: I migrated fro…”

   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
   LangGraph—none0/10

   The evidence pack shows LangGraph provides tracing/visualization via LangSmith and debugging tools, but contains no mention of built-in evals, scoring agent quality, or running evals as part of CI. Evals appear to be a separate LangSmith capability not documented here.

   ⚑ 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
   LangGraph—none0/10

   No evidence pack item documents unit-testing patterns, mocking of models/tools, or a testing framework/utilities for LangGraph agents; the closest is a community remark that nodes are plain functions you can implement however you like, which only implies testability rather than demonstrating it.

   • [community] “In langgraph nodes are just functions that can do whatever you want... you don't have to use langchain tools or ToolNode with langgraph, you…”

   proof ↗⚑ 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 LangGraph
   LangGraph✓fullcommunity8/10

   LangGraph integrates with LangSmith to provide tracing and debugging UI that visualizes execution paths, captures state transitions, and provides runtime metrics for agent runs, with docs explicitly directing users to trace and compare workflow patterns via the tracing quickstart. missing for 10: no independent/hands-on confirmation of trace fidelity for LLM calls and tool invocations specifically, and one community comment notes streaming/observability implementation is left partly to the client.

   • [github] “Debugging with LangSmith — Gain deep visibility into complex agent behavior with visualization tools that trace execution paths, capture sta…”
   • [github] “Gain deep visibility into complex agent behavior with visualization tools that trace execution paths, capture state transitions, and provide…”
   • [claimed-docs] “Trace and compare these workflow patterns with LangSmith... Follow the tracing quickstart to see how data flows through each step.”
   • [claimed-docs] “It exposes graph execution through stream modes such as updates, values, messages, custom, checkpoints, tasks, and debug.”
   • [community] “The one thing I wish was better developed is persistence and streaming - they give sample code to stream, but it's essentially a complete im…”

   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 Google ADK
   LangGraph—none0/10

   The evidence describes LangGraph's general graph/node architecture, persistence, interrupts, and human-in-the-loop features, but nothing documents a guardrails feature (input/output validation, content moderation, or blocking unsafe content). While nodes are flexible functions (allowing a developer to hand-roll such logic), there is no first-party guardrails API, validator, or moderation integration cited.

   • [community] “In langgraph nodes are just functions that can do whatever you want... you don't have to use langchain tools or ToolNode with langgraph, you…”
   • [claimed-docs] “At its core, LangGraph models agent workflows as graphs. You define the behavior of your agents using three key components”
   • [claimed-docs] “By composing Nodes and Edges, you can create complex, looping workflows that evolve the state over time.”

   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 Google ADK
   LangGraph—none0/10

   The evidence pack documents human-in-the-loop interrupts, checkpointing, and custom node logic (langgraph-docs-4, langgraph-gh-2), but nowhere describes fine-grained per-tool permission scoping or sandboxed/isolated execution environments for agent actions. Community notes even mention nodes/tools are 'whatever you want' custom code (langgraph-comm-10), implying no built-in permissioning or sandbox layer is provided by the framework itself.

   • [claimed-docs] “Interrupts allow you to pause graph execution at specific points and wait for external input before continuing.”
   • [github] “Seamlessly incorporate human oversight by inspecting and modifying agent state at any point during execution.”
   • [github] “Human-in-the-loop — Seamlessly incorporate human oversight by inspecting and modifying agent state at any point during execution.”
   • [community] “In langgraph nodes are just functions that can do whatever you want... you don't have to use langchain tools or ToolNode with langgraph, you…”
   • [community] “Almost none of those things are part of the LangGraph framework? LangGraph does the scheduling, checkpointing, state management, etc. All of…”

   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 to LangGraph
   LangGraph✓fullclaimed9/10

   LangGraph has a dedicated interrupts feature explicitly designed to pause graph execution and wait for external input, with resumption via re-invoking the graph with a Command object carrying the human's decision; this is backed by checkpointer-based persistence for durability across pauses, and GitHub docs explicitly list 'Human-in-the-loop' as a core capability allowing inspection/modification of agent state mid-execution. Missing for 10: independent hands-on developer account specifically validating the interrupt/resume workflow (community evidence discusses persistence/streaming generally but not this exact HITL pause-resume flow).

   • [claimed-docs] “Interrupts allow you to pause graph execution at specific points and wait for external input before continuing.”
   • [claimed-docs] “you resume execution by re-invoking the graph using Command, which then becomes the return value of the interrupt() call from inside the nod…”
   • [claimed-docs] “when you're ready to continue, you resume execution by re-invoking the graph using Command, which then becomes the return value of the inter…”
   • [claimed-docs] “Checkpointing keeps your place: the checkpointer writes the exact graph state so you can resume later, even when in an error state.”
   • [claimed-docs] “Checkpointers persist a thread's graph state as checkpoints. Use them for short-term, thread-scoped memory, including conversation continuit…”
   • [github] “Seamlessly incorporate human oversight by inspecting and modifying agent state at any point during execution.”
   • [github] “Human-in-the-loop — Seamlessly incorporate human oversight by inspecting and modifying agent state at any point during execution.”

   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
   LangGraph✓fullcommunity8/10

   LangGraph's interrupt() mechanism explicitly lets a graph pause execution at any node (e.g., a node calling a sensitive tool) and wait for external input, resuming only via Command re-invocation — this is the standard pattern for gating tool calls on human approval, and checkpointers back this with durable state. GitHub feature list and docs independently confirm 'Human-in-the-loop — seamlessly incorporate human oversight... at any point during execution,' and community commentary (HN) corroborates LangGraph as providing 'a state machine framework for human in the loop.' missing for 10: a first-party worked example specifically gating a tool-call node (vs. generic interrupt points), and independent hands-on validation of the approval-before-tool-call pattern.

   • [claimed-docs] “Interrupts allow you to pause graph execution at specific points and wait for external input before continuing.”
   • [claimed-docs] “you resume execution by re-invoking the graph using Command, which then becomes the return value of the interrupt() call from inside the nod…”
   • [claimed-docs] “when you're ready to continue, you resume execution by re-invoking the graph using Command, which then becomes the return value of the inter…”
   • [claimed-docs] “Checkpointing keeps your place: the checkpointer writes the exact graph state so you can resume later, even when in an error state.”
   • [github] “Seamlessly incorporate human oversight by inspecting and modifying agent state at any point during execution.”
   • [github] “Human-in-the-loop — Seamlessly incorporate human oversight by inspecting and modifying agent state at any point during execution.”
   • [community] “I think the main thing LangGraph adds is a state machine framework for human in the loop with time travel... you won't have to make your own…”

   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
   LangGraph—none0/10

   Evidence describes LangGraph's persistence/checkpointing and short-term vs long-term memory model, but nothing in the pack documents specific mechanisms to trim, summarize, or filter conversation history to manage context window size. Missing for 10: any mention of message trimming utilities, summarization nodes/chains, or history-filtering APIs, and independent confirmation these features work as intended.

   • [claimed-docs] “Short-term memory (thread-level persistence) enables agents to track multi-turn conversations.”
   • [claimed-docs] “Add short-term memory as a part of your agent's state to enable multi-turn conversations.”
   • [claimed-docs] “Short-term memory (thread-level persistence) enables agents to track multi-turn conversations. To add short-term memory:”
   • [claimed-docs] “Checkpointers persist a thread's graph state as checkpoints. Use them for short-term, thread-scoped memory, including conversation continuit…”
   • [claimed-docs] “Stores persist application-defined data outside the graph state. Use them for long-term, cross-thread memory, including user preferences, fa…”

   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 LangGraph
   LangGraph✓fullcommunity8/10

   LangGraph documents a dedicated Store abstraction explicitly for 'long-term, cross-thread memory' (user preferences, facts, shared knowledge) separate from thread-scoped checkpointers, with guidance to back it with production databases (e.g., Postgres) and docs explicitly stating 'Add long-term memory to store user-specific or application-level data across sessions.' GitHub README also markets 'long-term persistent memory across sessions' as a core feature. Missing for 10: independent/hands-on corroboration of cross-thread memory at scale — one community comment vaguely notes persistence 'could be better developed,' but this is not a concrete failure report.

   • [claimed-docs] “Stores persist application-defined data outside the graph state. Use them for long-term, cross-thread memory, including user preferences, fa…”
   • [claimed-docs] “In production, use a checkpointer backed by a database: from langgraph.checkpoint.postgres import PostgresSaver”
   • [claimed-docs] “Add long-term memory to store user-specific or application-level data across sessions.”
   • [github] “Comprehensive memory — Create truly stateful agents with both short-term working memory for ongoing reasoning and long-term persistent memor…”
   • [community] “The one thing I wish was better developed is persistence and streaming - they give sample code to stream, but it's essentially a complete im…”

   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 Google ADK
   LangGraph~partialprobed4/10

   The LangGraph CLI/Agent Server exposes API endpoints for runs, threads, assistants, etc., suggesting programmatic access mirrors what LangGraph Studio UI shows, but there's no explicit documentation confirming full feature parity between the Studio UI and the API. missing for 10: explicit parity documentation, a public OpenAPI spec (probe found only 404s), and hands-on confirmation that every UI action (e.g., time-travel, breakpoints, state edits) is scriptable via API.

   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally. The resulting server exposes all API endpoints for r…”
   • [claimed-docs] “LangGraph CLI** is a command-line tool for building and running the [Agent Server](/langsmith/agent-server) locally. The resulting server ex…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.langchain.com/openapi.json, https://docs.langchain.com/swagger.json, https://docs.langc…”
   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally.”

   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
   LangGraph~partialclaimed5/10

   Evidence confirms LangGraph's source is publicly hosted on GitHub (langchain-ai/langgraph) with install instructions and repo links, implying the code is readable, but no evidence pack item explicitly states or cites an open-source license (e.g., MIT/Apache) for the repo. missing for 10: explicit license file/citation, confirmation of license terms, any independent verification of licensing terms.

   • [github] “pip install -U langgraph”
   • [github] “LangGraph is a low-level orchestration framework for building, managing, and deploying long-running, stateful agents.”
   • [github] “Low-level orchestration framework for building stateful agents.”

   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 drawn
   LangGraph✓fullclaimed8/10

   LangGraph core is a pip-installable open-source library (langgraph-gh-5) with a CLI to build and run the Agent Server locally (langgraph-docs-23, langgraph-docs-30, langgraph-docs-37), and supports production-grade self-hosted persistence via PostgresSaver (langgraph-docs-13), confirming a fully self-hostable core product outside any managed SaaS. missing for 10: explicit license/self-hosting infra docs (scaling, containerization) and independent hands-on confirmation of self-hosting beyond CLI docs.

   • [github] “pip install -U langgraph”
   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally.”
   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally. The resulting server exposes all API endpoints for r…”
   • [claimed-docs] “LangGraph CLI** is a command-line tool for building and running the [Agent Server](/langsmith/agent-server) locally. The resulting server ex…”
   • [claimed-docs] “In production, use a checkpointer backed by a database: from langgraph.checkpoint.postgres import PostgresSaver”

   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
   LangGraph✓fullcommunity8/10

   LangGraph explicitly documents multi-agent orchestration patterns (handoffs, subagents/crews) via its graph-api and multi-agent docs, letting developers embed agent patterns as nodes, mix deterministic/agentic steps, and use Command/interrupts for handoffs, all within one stateful graph with persistence and streaming. Community evidence corroborates it as a legitimate stateful orchestration engine (not just a wrapper) supporting cycles/parallelism. Missing for 10: no hands-on demonstration of a specific named multi-agent 'crew' example or independent benchmark of handoff reliability at scale.

   • [claimed-docs] “Build bespoke execution flows with LangGraph, mixing deterministic logic and agentic behavior. Embed other patterns as nodes in your workflo…”
   • [claimed-docs] “Custom workflow: Build bespoke execution flows with LangGraph, mixing deterministic logic and agentic behavior. Embed other patterns as node…”
   • [claimed-docs] “Custom workflow — Build bespoke execution flows with LangGraph, mixing deterministic logic and agentic behavior. Embed other patterns as nod…”
   • [claimed-docs] “Here are the main patterns for building multi-agent systems, each suited to different use cases”
   • [claimed-docs] “At its core, LangGraph models agent workflows as graphs. You define the behavior of your agents using three key components”
   • [claimed-docs] “LangGraph models agent workflows as graphs. You define the behavior of your agents using three key components: State, Nodes, Edges.”
   • [claimed-docs] “Interrupts allow you to pause graph execution at specific points and wait for external input before continuing.”
   • [claimed-docs] “when you're ready to continue, you resume execution by re-invoking the graph using Command, which then becomes the return value of the inter…”
   • [community] “LangGraph implements a variant of the Pregel/BSP algorithm for orchestrating workflows with cycles (ie. not DAGs) and parallelism without da…”
   • [community] “LangGraph is different. It is a legitimate piece of workflow software and not a wrapper framework. Now, when it comes to workflow there are …”

   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 drawn
   LangGraph✓fullcommunity9/10

   LangGraph's core model is explicitly graph-based (State, Nodes, Edges) with support for loops/cycles, branching, and parallelism via its Pregel/BSP execution model, confirmed both by docs and independent community technical commentary. missing for 10: no first-party hands-on benchmark of parallel-branch execution at scale, and community notes some friction with built-in parallelism complicating debugging.

   • [claimed-docs] “By composing Nodes and Edges, you can create complex, looping workflows that evolve the state over time.”
   • [claimed-docs] “LangGraph models agent workflows as graphs. You define the behavior of your agents using three key components: State, Nodes, Edges.”
   • [claimed-docs] “Workflows have predetermined code paths and are designed to operate in a certain order.”
   • [community] “LangGraph implements a variant of the Pregel/BSP algorithm for orchestrating workflows with cycles (ie. not DAGs) and parallelism without da…”
   • [community] “by predeclaring the structure, you can show debugging UI of the full graph, even if you've only executed part of it... The downside is that …”
   • [community] “Hot take #1: For experienced developers, framework abstractions can add unnecessary complexity. Hot take #2: Built-in parallelism, while pro…”
   • [claimed-docs] “At its core, LangGraph models agent workflows as graphs. You define the behavior of your agents using three key components”

   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
   LangGraph—none0/10

   The evidence pack describes LangGraph's checkpointing/persistence architecture (Postgres checkpointer, Agent Server with managed database) but contains no documentation of region selection, data residency controls, or geographic deployment options for stored data. Since LangGraph offers a hosted Agent Server/deployment platform, region/residency is a fair question, but nothing in the pack addresses it.

   • [claimed-docs] “In production, use a checkpointer backed by a database: from langgraph.checkpoint.postgres import PostgresSaver”
   • [claimed-docs] “LangGraph CLI is a command-line tool for building and running the Agent Server locally. The resulting server exposes all API endpoints for r…”
   • [claimed-docs] “LangGraph CLI** is a command-line tool for building and running the [Agent Server](/langsmith/agent-server) locally. The resulting server ex…”

   proof ↗⚑ 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
   LangGraph—none0/10

   The evidence describes checkpointers and stores that persist conversation state and long-term memory (e.g., via Postgres), but nothing in the pack documents any deletion API, TTL/retention policy, or user-facing control to purge stored threads/state. As a self-hosted framework the user technically owns the database, but no LangGraph-specific retention/deletion mechanism is evidenced.

   • [claimed-docs] “Checkpointers persist a thread's graph state as checkpoints. Use them for short-term, thread-scoped memory, including conversation continuit…”
   • [claimed-docs] “Stores persist application-defined data outside the graph state. Use them for long-term, cross-thread memory, including user preferences, fa…”
   • [claimed-docs] “In production, use a checkpointer backed by a database: from langgraph.checkpoint.postgres import PostgresSaver”
   • [claimed-docs] “Checkpointers persist a thread's graph state as checkpoints. Use them for short-term, thread-scoped memory... Stores persist application-def…”

   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
   LangGraph—none0/10

   No evidence in the pack addresses telemetry, usage tracking, or an opt-out mechanism for LangGraph itself; the docs focus on orchestration, memory, streaming, and deployment, and LangSmith tracing is presented as an opt-in observability feature rather than a telemetry opt-out control.

   ⚑ 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 LangGraph
   LangGraph✓fullclaimed9/10

   LangGraph's checkpointer system explicitly persists exact graph state per thread, enabling resume after error/crash ('checkpointing keeps your place... even when in an error state'), with production-grade backends like PostgresSaver documented and GitHub README explicitly touting 'durable execution' that resumes 'exactly where they left off' after failures. This is a well-documented, core feature with clear technical backing across multiple doc pages; missing for 10: independent hands-on verification of crash-recovery behavior beyond docs/marketing claims.

   • [claimed-docs] “Checkpointers persist a thread's graph state as checkpoints. Use them for short-term, thread-scoped memory, including conversation continuit…”
   • [claimed-docs] “In production, use a checkpointer backed by a database: from langgraph.checkpoint.postgres import PostgresSaver”
   • [claimed-docs] “Checkpointing keeps your place: the checkpointer writes the exact graph state so you can resume later, even when in an error state.”
   • [github] “Build agents that persist through failures and can run for extended periods, automatically resuming from exactly where they left off.”
   • [github] “Durable execution — Build agents that persist through failures and can run for extended periods, automatically resuming from exactly where t…”

   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 LangGraph
   LangGraph✓fullclaimed8/10

   LangGraph explicitly advertises 'Durable execution' as a core feature, with checkpointers (including production Postgres-backed checkpointers) that persist thread state so agents 'automatically resume from exactly where they left off' after failures, and interrupts that preserve execution state even in error conditions. This directly matches the engineering-lead's requirement for durable, restart-resilient long-running agents. Missing for 10: independent hands-on verification of actual crash/restart recovery in production, and explicit coverage of third-party durable-execution integrations (e.g., Temporal) beyond LangGraph's native mechanism.

   • [github] “Durable execution — Build agents that persist through failures and can run for extended periods, automatically resuming from exactly where t…”
   • [github] “Build agents that persist through failures and can run for extended periods, automatically resuming from exactly where they left off.”
   • [claimed-docs] “Checkpointers persist a thread's graph state as checkpoints. Use them for short-term, thread-scoped memory, including conversation continuit…”
   • [claimed-docs] “In production, use a checkpointer backed by a database: from langgraph.checkpoint.postgres import PostgresSaver”
   • [claimed-docs] “Checkpointing keeps your place: the checkpointer writes the exact graph state so you can resume later, even when in an error state.”
   • [github] “Production-ready deployment — Deploy sophisticated agent systems confidently with scalable infrastructure designed to handle the unique chal…”

   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 LangGraph
   LangGraph~partialcommunity7/10

   LangGraph docs clearly document multiple stream modes including 'messages' for token streaming and 'updates'/'debug'/'tasks' for intermediate node/tool events, plus separate iterators per projection via stream/astream, directly supporting real-time UI streaming of tokens and agent steps. However, a community report notes the streaming implementation is minimal sample code that each client must fully reimplement, indicating real-world integration effort beyond the docs. missing for 10: independent hands-on confirmation of smooth tool-call/step event streaming in a UI, and clearer first-party UI integration examples beyond sample code.

   • [claimed-docs] “It exposes graph execution through stream modes such as updates, values, messages, custom, checkpoints, tasks, and debug.”
   • [claimed-docs] “Event streaming gives you separate iterators per projection (messages, values, subgraphs, output) so you can consume them independently”
   • [claimed-docs] “LangGraph graphs expose the stream (sync) and astream (async) methods to yield streamed outputs as iterators.”
   • [claimed-docs] “It exposes graph execution through stream modes such as `updates`, `values`, `messages`, `custom`, `checkpoints`, `tasks`, and `debug`.”
   • [claimed-docs] “Event streaming gives you separate iterators per projection (messages, values, subgraphs, output) so you can consume them independently inst…”
   • [community] “The one thing I wish was better developed is persistence and streaming - they give sample code to stream, but it's essentially a complete im…”

   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 drawn
   LangGraph—none0/10

   The evidence pack covers persistence, streaming, human-in-the-loop, checkpointing, and multi-agent workflows, but contains no mention of structured output, schema validation, or automatic retries on validation failure for LangGraph agents.

   ⚑ 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