Google Agent Development Kit (ADK) Introduction (5): Developer Mindset

Conceptual Comparison: Developer Mindset, Responsibility Separation, and Task Decomposition Building on the previous article, this one will explore the shift in developers' mindset when transitioning from API development to A2A development. Developer Mindset Shift: Function-Oriented vs. Agent-Oriented. Traditional development often involves thinking in terms of functions or API call sequences: starting from input, invoking services step-by-step, and finally producing output. Developers act as "orchestrators," controlling every step. In contrast, agent-oriented architecture requires a new mindset—designing a community of agents, each responsible for a subtask and interacting via messages and protocols. Instead of scripting flows directly, developers configure systems of autonomous agents, each with its own goal. Since agents make decisions independently (via LLMs), developers must shift from controlling every detail to setting up high-level rules and supervision. Responsibility Separation and Task Decomposition. In monolithic models, task decomposition happens at the code level—breaking big functions into smaller ones or chaining API calls. But the entire task remains owned by a single system component. Agent-based architectures promote system-level separation of responsibilities, assigning different subtasks to specialized agents. For example, in the meeting_workflow project, the workflow is split into three agents: one for input validation (email format), one for Google Calendar scheduling, and one for sending notifications. Each agent does what it's best at, and a sequential agent links them. This clear boundary improves maintainability and debuggability. In a traditional model, the same process would likely be a single script chaining everything, with tightly coupled logic that hinders reuse or evolution. This kind of agent-based decomposition is similar to team collaboration: breaking a big goal into professional subtasks executed by different roles. The multi_agent_pm project demonstrates this: Manager, Engineering, and QA/Test agents work together. The manager plans and assigns tasks, the engineering agent executes them, and QA ensures quality. With A2A, they coordinate like a real team. Each agent keeps context within its domain, avoiding the confusion of a single model tracking everything. Adding new roles (e.g., a design agent) is simple—just define its role and connections. Ultimately, the big shift is this: from commanding computers to enabling agent collaboration. Developers need to think at a higher level—turning hardcoded flows into agent-to-agent protocols. It also requires accepting partial autonomy of agents and trusting them to complete subtasks and return results. This shift takes practice, but it enables more flexible and intelligent systems. Transitioning Your Developer Mindset (Function-Oriented → Agent-Oriented) To adopt these new paradigms, engineers must adjust both mindset and skills. As some have put it, "MCP is just the prelude—ADK and A2A are the beginning of the Agent era." Here's how to make that transition: Think Like an Architect: Break problems down into agent roles instead of steps in a script. Ask: what subtasks exist? What kind of agents should own each one? For example, a support system might include an analyzer agent, a retriever agent, and a responder agent—not a monolithic chain. Learn the New Tools and Protocols: Study ADK, A2A, and MCP. Understand how to create tools, define agent metadata files (like .well-known/agent.json), and integrate MCP services. Start small and build confidence. Shift Design Philosophy: Move from OOP or functional programming to models like Actor systems or Microservices. Each agent is like a self-contained actor with its own state, communicating via protocols. Focus on defining interfaces and message contracts—not just function inputs/outputs. Plan for Asynchrony and Uncertainty: Agent interactions are often async and non-deterministic. Responses may be delayed or require multiple exchanges. Agents may misunderstand or misbehave due to model randomness. Plan for retries, validations, and human-in-the-loop steps where needed. Migrate Gradually: Don’t overhaul everything. Start by refactoring one sub-feature into a mini-agent workflow or building a multi-agent demo. Limit the number of agents initially. Reflect after each iteration—what got better? What got more complex? Adjust accordingly. In summary, transitioning to agent-oriented development means evolving from micro-managing logic to coordinating intelligent actors. Developers must expand their skills to cover LLMs, natural language, and distributed architecture. Early adopters of this shift will be well-positioned for the next wave of AI software. Summary and Application Suggestions Key Difference: Google ADK + A2A enables highly modular, scalable agent collaboration, while MCP/traditional APIs rely on centralized, sequential flows. ADK/A2A br

May 16, 2025 - 03:06

Google Agent Development Kit (ADK) Introduction (5): Developer Mindset

Conceptual Comparison: Developer Mindset, Responsibility Separation, and Task Decomposition

Building on the previous article, this one will explore the shift in developers' mindset when transitioning from API development to A2A development.

Developer Mindset Shift: Function-Oriented vs. Agent-Oriented. Traditional development often involves thinking in terms of functions or API call sequences: starting from input, invoking services step-by-step, and finally producing output. Developers act as "orchestrators," controlling every step. In contrast, agent-oriented architecture requires a new mindset—designing a community of agents, each responsible for a subtask and interacting via messages and protocols. Instead of scripting flows directly, developers configure systems of autonomous agents, each with its own goal. Since agents make decisions independently (via LLMs), developers must shift from controlling every detail to setting up high-level rules and supervision.

Responsibility Separation and Task Decomposition. In monolithic models, task decomposition happens at the code level—breaking big functions into smaller ones or chaining API calls. But the entire task remains owned by a single system component. Agent-based architectures promote system-level separation of responsibilities, assigning different subtasks to specialized agents. For example, in the meeting_workflow project, the workflow is split into three agents: one for input validation (email format), one for Google Calendar scheduling, and one for sending notifications. Each agent does what it's best at, and a sequential agent links them. This clear boundary improves maintainability and debuggability. In a traditional model, the same process would likely be a single script chaining everything, with tightly coupled logic that hinders reuse or evolution.

This kind of agent-based decomposition is similar to team collaboration: breaking a big goal into professional subtasks executed by different roles. The multi_agent_pm project demonstrates this: Manager, Engineering, and QA/Test agents work together. The manager plans and assigns tasks, the engineering agent executes them, and QA ensures quality. With A2A, they coordinate like a real team. Each agent keeps context within its domain, avoiding the confusion of a single model tracking everything. Adding new roles (e.g., a design agent) is simple—just define its role and connections.

Ultimately, the big shift is this: from commanding computers to enabling agent collaboration. Developers need to think at a higher level—turning hardcoded flows into agent-to-agent protocols. It also requires accepting partial autonomy of agents and trusting them to complete subtasks and return results. This shift takes practice, but it enables more flexible and intelligent systems.

Transitioning Your Developer Mindset (Function-Oriented → Agent-Oriented)

To adopt these new paradigms, engineers must adjust both mindset and skills. As some have put it, "MCP is just the prelude—ADK and A2A are the beginning of the Agent era." Here's how to make that transition:

Think Like an Architect: Break problems down into agent roles instead of steps in a script. Ask: what subtasks exist? What kind of agents should own each one? For example, a support system might include an analyzer agent, a retriever agent, and a responder agent—not a monolithic chain.
Learn the New Tools and Protocols: Study ADK, A2A, and MCP. Understand how to create tools, define agent metadata files (like .well-known/agent.json), and integrate MCP services. Start small and build confidence.
Shift Design Philosophy: Move from OOP or functional programming to models like Actor systems or Microservices. Each agent is like a self-contained actor with its own state, communicating via protocols. Focus on defining interfaces and message contracts—not just function inputs/outputs.
Plan for Asynchrony and Uncertainty: Agent interactions are often async and non-deterministic. Responses may be delayed or require multiple exchanges. Agents may misunderstand or misbehave due to model randomness. Plan for retries, validations, and human-in-the-loop steps where needed.
Migrate Gradually: Don’t overhaul everything. Start by refactoring one sub-feature into a mini-agent workflow or building a multi-agent demo. Limit the number of agents initially. Reflect after each iteration—what got better? What got more complex? Adjust accordingly.

In summary, transitioning to agent-oriented development means evolving from micro-managing logic to coordinating intelligent actors. Developers must expand their skills to cover LLMs, natural language, and distributed architecture. Early adopters of this shift will be well-positioned for the next wave of AI software.

Summary and Application Suggestions

Key Difference: Google ADK + A2A enables highly modular, scalable agent collaboration, while MCP/traditional APIs rely on centralized, sequential flows. ADK/A2A breaks complexity into autonomous parts and uses open protocols for communication. Monolithic models are fine for static, predictable tasks but struggle with complexity or dynamic coordination.

Best Use Cases: If your app has multi-step workflows, cross-functional collaboration, or dynamic logic, use agent-based design. For example, internal enterprise assistants that interact with marketing, support, and analytics systems benefit from splitting tasks among specialized agents. ADK tools and A2A protocols simplify building and scaling this setup. For simple, one-off tasks (e.g., checking the weather), traditional API calls or function calling may be enough.

Note: ADK and MCP are not mutually exclusive—you can combine them. Agents built in ADK can call external MCP tools. Future AI systems may involve agents that collaborate (via A2A) and invoke tools (via MCP). Learning both gives you an edge.

In short, ADK and A2A represent a shift in developer thinking—not just toolkits, but a whole new mental model. This article aims to highlight that shift. Try it in your projects, validate it in small scopes, and once you're ready, you'll be capable of building smarter, more autonomous, and extensible AI systems ready for what’s next.

In the upcoming chapter, I want to learn the process of deploying an Agent to Vertex AI, containerizing it, and setting up monitoring.