“Agentic Exposure” Is Not the Same as Agent Engineering

A new question has started appearing in engineering conversations and leadership meetings:

“Do you have enough agentic workflow exposure?”

In practice, this often means: have you built something using Google’s Agent Development Kit, LangGraph or whichever orchestration framework is currently attracting attention?

Familiarity with these tools is useful. But it is not the same as understanding how to build reliable agentic systems.

The Moving Target of Agent Frameworks

Expecting years of production experience with a recently released framework is an obvious contradiction.

Google released ADK 2.0 for Python in May 2026. It introduced a graph-based workflow runtime, moving beyond the hierarchical execution model used by ADK 1.x. Agents, functions and tools can now operate as nodes within workflows supporting routing, parallel execution, loops and human intervention.

It is a significant change—and one accompanied by breaking changes to the agent API, event model and session schema.

That does not make ADK unsuitable for production. It does mean that its APIs, conventions and recommended patterns are still evolving. Memorising today’s syntax is therefore a poor substitute for understanding the problems the framework is attempting to solve.

Framework fluency demonstrates that someone can use a tool. Engineering capability determines whether they know when the tool is appropriate, where it may fail and what safeguards must surround it.

The Context Tax of Agentic Coding

Framework churn is visible. The growing cost of context is easier to overlook.

Ask a coding agent to fix a small type error and it may need to inspect the directory structure, dependency files, imported modules, tests and recent terminal output before changing a single line. The request may be small, but the context required to complete it safely is not.

As the session continues, that working set grows. The agent accumulates conversation history, file contents, tool results, compiler errors and its own earlier decisions. Some of that information remains useful; some becomes stale or redundant.

Prompt caching can reduce the cost and latency of repeatedly processing stable content. But it does not make context free. Cache behaviour depends on which parts of the prompt change, while long-running tasks still require decisions about what should be retained, summarised or discarded. Anthropic’s own Claude Code cost guidance treats context management, model selection and token monitoring as practical engineering concerns.

This is the real context tax: useful agents need enough information to act intelligently, but gathering and maintaining that information consumes tokens, time and attention.

No orchestration framework can remove that trade-off. It can only help manage it.

Frameworks Do Not Create Boundaries

The second misconception is that an orchestration layer automatically makes an agent safe or reliable.

My experience with Atlassian Rovo provides a simple example. I opened Rovo from within a specific Jira project and asked it to create a work item. It created the item in an unrelated team’s project instead.

Atlassian documents that Rovo can use the page or work item currently being viewed as context. It can also create, edit, transition and delete Jira work items through its supported actions.

What we cannot see is Rovo’s internal prompt, tool-selection logic or API orchestration. It would therefore be speculative to claim exactly why it selected the wrong project.

What the failure does demonstrate is that interface context was not enforced as an action boundary. The system either needed to bind the active project to the mutation or ask me to choose a destination.

This resembles the risk OWASP describes as Excessive Agency: a model has enough functionality, permission or autonomy to cause an unintended action when its interpretation is wrong or ambiguous.

The problem is not unique to Rovo. It is a general property of systems in which probabilistic models can modify persistent data.

A framework can route the model’s output to a tool. It cannot determine whether that action is appropriate unless engineers define and enforce the boundary.

What Actually Matters

Agent frameworks are worth learning. They provide useful abstractions for routing, state, tool execution, retries and human intervention. Shared frameworks can also make systems easier for teams to understand and maintain.

But the durable engineering skills sit beneath them:

• Controlling how context is selected, refreshed and discarded
• Separating model suggestions from trusted runtime parameters
• Validating the meaning of an action, not merely its JSON structure
• Limiting tools and permissions to the minimum required
• Asking for clarification instead of allowing the model to guess
• Testing complete conversations and tool sequences
• Monitoring latency, token usage and failure rates
• Logging mutations and making important actions reversible

These concerns remain whether the workflow is written in ADK, LangGraph or plain Python.

The Framework Is Not the Skill

“Agentic exposure” is a reasonable starting point for a technical conversation. It becomes misleading when treated as a proxy for engineering maturity.

Someone who understands distributed systems, access control, testing, observability and the limitations of probabilistic models can learn a new orchestration framework. The reverse is not guaranteed.

The syntax will change. The difficult questions will remain: What context does the model receive? What is it allowed to do? How is intent verified? What happens when it is wrong?

Those are the questions that determine whether an agentic prototype can become a dependable system.