The "Agentic Exposure" Checklist: SDK Churn, Context Taxes, and Real Systems

There is a new phrase circulating in engineering conversations and leadership syncs:

"Do you have enough agentic workflow exposure?"

In practice, this is usually code for whether someone has built on top of Google's Agent Development Kit (ADK) or whatever multi-agent framework was trending on GitHub last month.

It is a familiar reflex: mistaking familiarity with a rapidly shifting, bleeding-edge SDK for fundamental architectural understanding.

The Moving Target of Agent Frameworks

Demanding mature, multi-year production mastery over tools like ADK 2.0 is a contradiction in terms. The framework itself is still actively finding its feet.

ADK recently tore out its initial 1.x linear templates (SequentialAgent, ParallelAgent) in favour of an entirely new graph-based execution engine (adk.dev). The APIs are evolving, best practices are being written in real time, and breaking changes are standard fare.

Memorising the syntax of a transient SDK does not teach you how to handle the hard physics of AI systems: token economics, model drift, or execution latency. Treating an experimental kit as a rigid prerequisite confuses framework fluency with engineering capability.

The Compounding "Context Tax": The Claude Code Reality

Beyond framework churn, the biggest hidden friction in agentic workflows is the cost of feeding context.

Anyone using CLI agent tools like Claude Code in real engineering projects quickly discovers this reality:

1. The Recursive Read: You ask the agent to fix a minor type error. To understand the imports, it reads the directory tree, inspects package.json, and loads four related source files. That single turn dumps 30,000 tokens into the prompt buffer.

2. The Cache Invalidation: Prompt caching helps, but the moment the agent modifies a file or executes a shell command, chunks of the prefix cache invalidate.

3. The Quadratic Bill: By turn six of a multi-file refactor, the agent is re-feeding 120,000+ tokens of cumulative history, tool outputs, and terminal logs into the model on every single step.

A developer thinks they spent twenty minutes on a simple fix; under the hood, the agent quietly burned $10 in API compute. No orchestration framework—whether ADK, LangGraph, or custom Python—can abstract away the physical cost of repeatedly feeding context to a frontier model.

The Atlassian Rovo Paradox

If anyone believes autonomous agent workflows are a mature enterprise technology, they only need to look at how the software giants are struggling with basic boundaries.

Take Atlassian Rovo. Atlassian possesses enormous engineering resources and massive enterprise data graphs. Yet in actual daily use:

• You invoke the bot inside a specific project board, and it constructs a task in an unrelated team's backlog.

• It operates with over-privileged ambient permissions (OWASP LLM06: Excessive Agency).

• It suffers from a fundamental mismatch between what the user is looking at on screen and what its backend retrieves across the company graph (as discussed in TDD for Agents).

If Atlassian still struggles to prevent ambient context leakage and accidental cross-project mutations, pretending that an unproven developer kit will effortlessly deliver bulletproof enterprise autonomy is wishful thinking.

What Actually Matters

"Agentic exposure" is becoming the modern equivalent of asking for five years of experience in a two-year-old framework.

Frameworks like Google ADK and graph runtimes are well worth studying, but they are tools, not magic wands. Real engineering in AI isn't about memorising an SDK that will change next quarter. It is about understanding where models hallucinate, knowing when to enforce deterministic schemas, and respecting the practical boundaries of context and cost.