DEV Community

Cover image for Why your AI agents should be collaborative (and how to build the review gates)
Tran Tien Van
Tran Tien Van

Posted on • Originally published at vanaxity.com

Why your AI agents should be collaborative (and how to build the review gates)

Less than 10% of workplace AI interactions in Google’s July 23, 2026 ATLAS announcement fully automate tasks.

For developers, that points to a practical default: build agents that advance work, expose evidence, and pause before consequential actions.

Read the result narrowly

Google published ATLAS as a comprehensive analysis of how people adopt and use AI. Its workplace finding is striking because it separates adoption from autonomy. AI use is wide across occupations and employment, but remains selective within a typical job. Breadth does not equal complete job automation.

The dominant patterns are collaborative: ideation, strategy, information retrieval, and learning. That evidence does not say autonomous agents are useless, and it does not set a permanent ceiling on automation. It does say a hands-off architecture should not be the unexamined starting point.

There is another boundary worth preserving. Most interactions observed in ATLAS occur outside work. That observation alone does not prove that search behavior, purchase intent, or buying has changed. If you are building RAG pipelines for sales enablement, distinguish between user intent and mere information retrieval. Do not turn an interaction-location finding into a conversion claim.

Model the agent as a reviewed pipeline

A useful implementation pattern is a sequence of bounded stages rather than one opaque run. As a technical case study in state-machine agent architecture, consider a content agent that moves approved research into writing, illustration, publishing, and syndication, with human review at consequential steps.

Each state accepts a defined input, produces an inspectable artifact, and records whether it may continue automatically or needs approval. The important design choice is not the presence of a human everywhere. It is making the stop conditions explicit.

A practical contract for each transition could include:

  • the approved evidence and the claim it supports
  • a current date, version, or other freshness signal for brand information
  • the generated artifact plus a clear reviewer decision
  • the permitted next action, especially before publishing or syndication

This keeps the agent assistive without reducing it to autocomplete. It can still perform substantial work across several media. The gate exists where an error would propagate into a public or otherwise consequential step.

Make evidence part of the interface

To make brand information machine-readable, adopt these three schema standards.

  • Evidence schema: the approved material, the claim it supports, and a freshness signal such as a date or version
  • Artifact schema: the generated output, the stage that produced it, and the reviewer’s decision or changes
  • Transition schema: the permitted next action and whether approval is required before it runs

For a developer, these are interface requirements, not just editorial preferences.

A draft should not merely contain confident prose. It should preserve enough structure for a reviewer to distinguish a verified ATLAS finding from the case study’s analysis. A downstream illustration step should receive approved concepts, not infer them from an ambiguous chat history. A publishing step should know whether approval is present, not guess from conversational tone.

This is also where observability becomes useful. Track which stage produced an artifact, what evidence was available, what the reviewer changed, and why the run stopped. The goal is not to manufacture a new performance metric. It is to make the workflow understandable when a person needs to inspect it.

Accept the tradeoffs

Review gates add latency. They can create a bottleneck when ownership is unclear, and an excessive number of gates can erase the speed gained from automation. Structured evidence also requires more engineering than passing a block of text from one prompt to the next.

The opposite tradeoff is harder to see during a successful demo. A single autonomous run can hide unsupported inferences until they reach publishing, and a workflow optimized only for no-touch completion may not match the collaborative behavior ATLAS reports.

The balanced approach is selective autonomy: automate bounded transformations, preserve evidence between stages, and reserve review for consequential transitions. That design follows the current data without pretending current behavior can predict every future use of AI.

If you were instrumenting an assistive agent tomorrow, which transition would receive the first mandatory review gate: research to draft, draft to illustration, or approval to publish?


📖 Read the full guide → Google ATLAS AI Study: Collaborator, Not Automator

Top comments (0)