For the vibe-coding capstone in Kaggle’s 5-Day AI Agents course, I built Olist Ecommerce Analytics Agent around a practical question: could a multi-agent system analyze ecommerce data in BigQuery without giving an LLM unrestricted access to the warehouse?

The agent layer runs on Google ADK, Google’s official open-source, code-first framework for building agents. I used google/agents-cli, Google’s official CLI and skills package for build, evaluation, and deployment workflows, to support the development and evaluation path. This project was not deployed to production. Its evidence stops at working code, explicit safeguards, and local evaluations.

I used ADK here to test routing, tools, and safeguards in an end-to-end analytics workflow rather than an isolated demo. Its maintained public repository helps with inspection; activity alone does not establish production readiness.

What the system had to handle

The goal was not another chat interface that happened to generate SQL. A user should be able to ask an analytics question about Olist data while the system decides which specialist should handle it, queries BigQuery, and returns an answer in the context of the original request.

I split orchestration from specialist work. A coordinator routes each request instead of forcing one oversized prompt to interpret the question, choose an analysis method, access data, and explain the result. That separation made three responsibilities visible in code: understand the request, select the right capability, and access the data.

BigQuery was the boundary that needed the most discipline. An analytics agent can be useful and still be unsafe or unexpectedly expensive. I therefore put three concrete limits around query execution:

  • queries must be SELECT statements;
  • each query has a 10 GB billing cap;
  • each query has a 30-second timeout.

These controls do not make generated SQL correct. They reduce the blast radius when routing or query generation fails: no writes, no unbounded scan chosen by the agent, and no query left running indefinitely.

What held up under evaluation

The useful part of ADK here was its code-first model. Routing, tools, and safeguards live in code that can be inspected and exercised, not only in an architecture diagram. The official ADK repository also provides a public reference point for the framework itself.

agents-cli gave me one workflow for the build and evaluation work. I used that support without treating its deployment capability as evidence of a deployment. Tooling that can drive a deploy is not the same thing as a system that has survived production traffic.

The local project evidence currently records:

  • 17/17 ADK evaluations passed;
  • 12/12 agents-cli evaluations passed.

Those results show that every encoded case met the project’s current criteria. They do not prove that the agent understands every valid Olist question, but they are stronger evidence than a few hand-picked chat transcripts.

The implementation is available in the project repository. A separate video walkthrough shows the product flow and how the pieces connect. These are inspectable artifacts, not claims of winning the challenge or receiving an award.

Limits and current conclusion

The biggest gap sits between local evaluation and real usage. The current suites cover 17 ADK cases and 12 agents-cli cases. They do not exhaust the ways users can phrase questions, schema can drift, valid SQL can remain wasteful, or a technically correct query can support the wrong business interpretation.

The safeguards have narrow jobs. SELECT-only prevents writes; it does not prevent every poor read. A 10 GB cap and 30-second timeout bound consumption, but they do not replace SQL inspection, cost monitoring, or answer-quality evaluation. Specialist routing makes responsibilities clearer while adding another failure point: a wrong route can still produce a confident, plausible answer.

My current conclusion: Google ADK was practical enough to build an inspectable multi-agent analytics system, and agents-cli made the build/evaluation loop less fragmented. Olist Ecommerce Analytics Agent passed every evaluation currently in the project and keeps BigQuery behind explicit limits. It remains a challenge project, not a production-proven system. Its strongest result is simpler: the important claims can be checked against code, safeguards, evaluation records, and a walkthrough.