How Google Cloud says AI agents should delegate work

Smarter multi-agent systems need selective friction

Multi-agent automation becomes harder to control when one agent delegates work to another. Google Cloud’s framework focuses on four risks at those hand-offs: whether the result can be verified, whether the model fits the task, whether the agent receives appropriate access, and whether the instruction deserves challenge.

Google Cloud proposes four principles in response: design delegated work for verification, choose models for the task, limit delegated data and permissions, and make agents question suspect instructions. Google Cloud sells cloud infrastructure and AI services that can support these systems, so it has a commercial stake in how organizations design and expand agent deployments.

The design problem is selective friction. Organizations must decide which automated hand-offs can proceed directly and which require verification, tighter restrictions, resistance, or human judgment.

Start with what can be verified

Google Cloud’s first principle is a “contract-first” approach. An orchestrating agent, meaning the system that coordinates work among other agents, divides a larger assignment into smaller tasks whose outputs can be monitored and checked.

A system can delegate work successfully yet produce an outcome that is difficult to evaluate. Google Cloud therefore puts verifiability early in workflow design. A larger job may need repeated division into sub-goals until individual results are simple enough to assess.

For executives, this adds a test when choosing processes to automate: which intermediate and final outputs can be graded reliably? When a result has a clear test, verification can be automated. When correctness depends on context or expert judgment, the workflow can introduce a human decision point.

Google Cloud’s approach concentrates human review on results that automated checks cannot reliably resolve. Coordinating multiple agents is only part of the challenge. An organization also needs a credible way to assess the work as tasks move downstream.

Match model capability to the task

Delegation also determines how much model capability an organization uses for each task. Google Cloud says customers are increasingly asking whether individual jobs can go to smaller, cheaper models rather than larger reasoning systems.

Google Cloud contrasts a complex business process such as payroll with a basic administrative task such as spreadsheet reformatting. In its framing, payroll may justify a more advanced model because errors carry greater consequences. Spreadsheet reformatting may justify a cheaper endpoint.

The orchestrator must match model capability and cost to the work. That requires clear criteria for deciding which classes of tasks warrant more capable models.

Google Cloud says some of its customers already use model routing through API gateways to send tasks to different models, while others use client-side proxy tools. These are examples reported by a vendor that benefits commercially from greater use of cloud and AI infrastructure. The design choice is independent of the routing mechanism: organizations must decide how much model capability each type of work requires.

Delegate the minimum data and permissions required

Google Cloud’s third principle says an orchestrating agent should give a sub-agent only the permissions and information required for its assigned task.

Consider payroll. Passing an entire payroll dataset to a secondary agent for a narrow operation can expose confidential information the agent does not need. Limiting the hand-off narrows that exposure.

Verification becomes harder when one agent needs assurance about work involving data it should not receive. Google Cloud points to zero-knowledge proofs as one potential mechanism. A zero-knowledge proof is a cryptographic technique for demonstrating that a statement or computation is valid without disclosing the underlying secret information.

In an agent workflow, the proposed use is for one agent to prove that a computation was performed correctly without revealing the private dataset behind it. Google Cloud presents advanced cryptographic methods including zero-knowledge proofs as a possible approach.

The operational rule is straightforward: each delegated task creates a new access decision. Before passing authority downstream, the orchestrator should determine which data and permissions that specific task requires.

A capable agent must sometimes challenge an instruction

Google Cloud’s fourth principle adds friction to compliance itself. It draws on the organizational-theory concept of a “zone of indifference”: a range of requests a worker accepts without challenge because they appear to be part of ordinary duties.

Google Cloud argues that agents can face a related risk. Current systems may follow requests unless system instructions or post-training safety measures give them a clear reason to refuse. Across a delegation chain, a request can appear acceptable at each step even as its intent or context changes.

Research attributed to Google DeepMind describes the concern this way: “As delegation chains lengthen (? → ? → ?), a broad zone of indifference allows subtle intent mismatches or context-dependent harms to propagate rapidly downstream, with each agent acting as an unthinking router rather than a responsible actor.”

Google Cloud calls its proposed response “dynamic cognitive friction.” In this approach, an agent tests whether a request is accurate, relevant, sufficiently clear, and appropriate to its context. When those tests fail, the agent may challenge an ambiguous instruction or seek human verification.

Successful delegation requires more than compliance. In workflows where mistakes carry serious consequences, an agent may also need to recognize when an instruction requires additional scrutiny before acting.

Key takeaways for decision-makers

• Design for verification: Break delegated work into tasks with outputs that can be reliably checked, and reserve human review for results that require context or expert judgment.
• Match models to the work: Route routine tasks to smaller, cheaper models and use more capable models where complexity and the consequences of errors justify the added cost.
• Limit delegated access: Give each sub-agent only the data and permissions required for its task. Treat every hand-off as a new access decision.
• Build in selective resistance: Agents should not automatically comply with every delegated instruction. Add checks that challenge requests that are unclear, inaccurate, irrelevant or inappropriate, with human verification where needed.