Google announces the Agent Development Kit

Announcement record

Google announced the Agent Development Kit, an open-source framework for building and evaluating multi-agent applications. The company described model flexibility, tool use, workflow composition, and Vertex AI deployment integration. Application security, evaluation quality, data handling, and operational ownership remain work for each implementing team directly.

Why it matters

Framework convenience should not hide orchestration complexity. Define agent roles, tool boundaries, termination conditions, and test scenarios before adopting multi-agent patterns in practice.

What the announcement established

Google's April 9, 2025 post announced the Agent Development Kit as an open-source framework for building multi-agent applications. It described model flexibility, tool use, workflow composition, evaluation, and integration with Vertex AI deployment paths. A framework can standardize handoffs and local development, but it cannot decide which agent is permitted to act, what data it may see, or whether an evaluation represents production traffic. The announcement is therefore useful as a record of an implementation option, not as proof of a complete control plane. This briefing does not claim the kit's present APIs, model compatibility, hosting terms, or release state.

Roles need executable boundaries

A multi-agent design should begin with a role matrix: planner, researcher, formatter, policy checker, executor, and reviewer may exchange structured artifacts, but each sees only necessary data and tools. Define input and output schemas before prose prompts. The planner can request a task; it cannot call a connector. The executor can run an approved action; it cannot rewrite policy. The reviewer can reject evidence; it cannot silently repair the producer's work. Termination matters too: cap turns, retries, fan-out, cost, and elapsed time so a disagreement cannot become an endless conversation. These are product decisions that remain with the implementing team.

Orchestration failure is state failure

Multi-agent systems often fail through lost context, duplicate delegation, incompatible schemas, circular assignments, or a worker continuing after its grant expired. A handoff that looks complete in natural language may omit the policy decision or source version that made it valid. Store task state in a durable, typed record with owner, parent, deadline, capability grant, evidence links, and terminal reason. Make retries idempotent and distinguish retryable infrastructure errors from a denied action. When an agent cannot satisfy its contract, return a bounded partial artifact and escalation reason rather than asking another agent to guess what the first one meant.

Hypothetical change-review swarm

Hypothetical: a platform team wants faster review of a documentation parser. A planner opens a task with a one-file ownership boundary. A researcher identifies expected behavior from the supplied specification. A worker proposes the patch. A test agent runs only the named local checks and attaches results. An independent reviewer receives the diff plus acceptance criteria and flags a malformed-input gap. The task returns to the worker with that exact finding; the planner cannot approve it. When the validator passes, the human owner sees one record containing base revision, owned path, review finding, follow-up diff, and results. No agent receives deployment access because this is a source-review workflow.

Acceptance checks before adoption

Use fixtures that force conflicting worker recommendations, a circular delegation attempt, a timeout, schema-invalid handoff data, duplicate retries, policy denial, and an unavailable model. Assert that every terminal task has one owner and one explicit completion or failure reason. Confirm that tool grants do not broaden during delegation and that a reviewer is independent from the producer. Track fan-out count, token and tool budget, elapsed time, and abandoned work. Run integration tests where a downstream agent receives an incomplete artifact and must stop rather than infer missing facts. A framework passes only when its execution records are useful to an operator under failure.

Hypler connection

Hypler evaluates multi-agent designs by assigning bounded responsibilities, defined handoffs, and clear stop conditions. Cooperative components can gather evidence, draft work, or test alternatives, while accountable owners retain decisions involving architecture, permissions, customer commitments, and production change.

Operating model decision

Before adopting a multi-agent topology, specify the work that remains single-owner work. Architecture decisions, permission changes, customer commitments, and production mutations need a named accountable person even if agents supply analysis. Use agents for bounded evidence collection, drafting, testing, and comparison when their artifacts can be independently checked. Define a queue for blocked work so an uncertain worker does not seek a more permissive peer. Track whether parallelism shortened the critical path or merely created review overhead. A system that can stop, summarize what is known, and wait for a decision is more operationally useful than one that keeps delegating until it produces confident language.

Related capabilities

• Custom software and product engineering