You Don't Add Google's ADK to Use a Tool. You Add It to Build an Agent. Our Security Tool is a Tool."

✓ Human-authored analysis; AI used for formatting and proofreading.

The Technology Radar's note on Google's Agent Development Kit (ADK) shows it has matured: multi-language development, stronger observability and runtime features, software-engineering abstractions for orchestration, tools, evaluation, and deployment. The Radar also notes it's still pre-GA in parts, with "occasional rough edges and upgrade friction," and lands best for teams "already invested in Google's platform." And it's now one entry in a crowded field with Microsoft Agent Framework, Amazon Bedrock AgentCore, the OpenAI Agents SDK, the Claude Agent SDK, plus LangGraph and CrewAI.

That crowd is the point. Every one of those is a framework for building and operating an agent. Each comes with a programming model to learn, a runtime to operate, a version to track, and for the vendor-native ones a platform to commit to.

We build a cloud-security evaluator. The temptation, when agentic is in the air, is to reach for one of these and rebuild the tool as an agent. We didn't. And the reason is a category distinction the crowd makes:

ADK is for building an agent. Our tool is a thing an agent uses. You don't take on a framework's complexity and learning curve to call a command.

ADK's four abstractions, and why a tool needs none of them

ADK's value is because building an agent is hard. But map its four pillars onto "I have a capability I want an agent to invoke," and each one evaporates:

Notice that three of the four exist to manage non-determinism and statefulness. The inherent properties of an LLM agent. An agent's behavior varies, so you need an eval harness. An agent holds state across turns, so you need orchestration and a runtime. Those abstractions are the cost of the thing they manage.

A deterministic command holds no state and produces the same output every run. The abstractions designed to tame variance and state have nothing to tame. You're paying for machinery you don't use.

The learning curve is the hidden line item

The Radar's phrase "pre-GA in parts, with occasional rough edges and upgrade friction" is the part teams underestimate. A framework is not a one-time cost. It's:

• a programming model every engineer on the team must learn,
• a dependency you upgrade and whose breaking changes you absorb,
• a runtime you observe, operate, and debug,
• and, for vendor-native kits, a platform you're now coupled to.

Against that, here is the entire onboarding for our tool:

stave apply --controls ./controls --observations ./obs

There is no SDK to import, no graph to declare, no agent class to subclass, no runtime to stand up. An engineer who has run grep can run this. The framework they're using is the shell. The thing they have to learn is one --help page, and the output is JSON they already know how to read.

That's not a smaller framework. It's the absence of one which is a different and better thing when your job is to expose a capability, not to build an agent.

Portability: works under all of them, locked to none

Here's the move the framework comparison misses. Choosing ADK is choosing Google's platform. Choosing Bedrock AgentCore is choosing AWS. The Radar is explicit that vendor-native frameworks pay off mainly for teams "already invested" in that vendor, which is lock-in.

A deterministic CLI over files has no such opinion. Because it communicates through code execution and files, a command in, JSON out, it runs identically under:

• ADK (stave apply as a tool the agent calls)
• LangGraph or CrewAI (a node that shells out)
• the OpenAI / Claude Agent SDKs (a function tool)
• a plain bash script, or make, or a cron job
• a human at a terminal

The framework, if you even need one, becomes the caller's choice and a reversible one. Switch agent frameworks next quarter and the tool doesn't change. That's the opposite of platform commitment: the capability outlives whatever orchestrator is fashionable.

Why "lighter" doesn't mean "less rigorous"

It would be a mistake to read "no framework" as "no engineering." The rigor moved to a different place:

• Determinism — same inputs + same --eval-time produce byte-identical output. This lets a caller treat a command's output as a trustworthy message instead of an oracle reading, and what lets you debug by re-running one command in isolation. It's the property ADK's evaluation pillar tries to recover for agents; we have it by construction.
• Single responsibility — each command does one thing (evaluate, export, prove, map). We recently deleted the commands that strayed into orchestration territory such as continuous monitoring, scheduling, multi-account fan-out because those are the caller's job. We refused to grow our own orchestration layer, which is the same layer ADK sells.
• Provenance — every emitted fact carries a deterministic id tracing back to the observation property that produced it. You don't need the framework's observability stack to answer "where did this verdict come from"; the answer is in the output.

So the comparison isn't "heavyweight framework vs. cutting corners." It's "the rigor lives in the tool's contract (deterministic, scoped, traceable) instead of in a framework's runtime (orchestrated, observed, hosted)." For a capability, the former is cheaper to adopt, cheaper to operate, and impossible to lock you in.

When you should reach for ADK

If you are building a stateful, multi-turn, multi-agent system, one that reasons over shared memory, calls many tools, and needs runtime observability and managed deployment ADK earns its complexity. That's the problem it was built for.

The error is reaching for that complexity when your actual need is "let an agent invoke a capability and trust the result." For that, you don't need a development kit. You need a command that behaves the same way every time, reads a file, and writes a file.

The takeaway

The crowded agent-framework field with ADK, Microsoft Agent Framework, Bedrock AgentCore, OpenAI and Claude SDKs, LangGraph, CrewAI is solving the agent-builder's problem: orchestration, state, evaluation, deployment. If that's your problem, pick one.

But if you're shipping a capability for agents to use, the leanest, most portable, lowest-lock-in path is the unglamorous one: a deterministic CLI over files, with the orchestration left to whoever's calling. No programming model to learn, runtime to operate, platform or upgrade treadmill. It works under every framework on that list, and survives the day the list changes.

We didn't skip the framework to cut corners. We skipped it because a tool that does one thing deterministically doesn't need one and a team that doesn't have to learn one ships faster.

How this relates to existing compliance mods

The "deterministic CLI over files" property the article defends is shared with the rest of the Steampipe/Powerpipe mod ecosystem. turbot/steampipe-mod-aws-compliance runs the same way: a CLI invocation, framework benchmarks as content, deterministic output an agent can read. Same agent-friendly properties (no SDK to learn, orchestration runtime or upgrade treadmill), different content layer. An agent reaching for "evaluate cloud safety" doesn't have to pick one of these tools — it invokes both and reads both outputs. That's the agent-tool composition the article argues for, applied to the cloud-security tool ecosystem: framework coverage from the AWS Compliance Mod, compositional coverage from Stave, the agent stitching the two streams of binary verdicts into one decision. Comparison: aws-compliance-mod.