A walkthrough of the full lifecycle of shipping a production AI agent: a website concierge chatbot for a hotel business (modeled on a ~$5,000 freelance job) built with Google's Agent Development Kit, FastAPI, Gemini Flash and Postgres, deployed on Google Cloud Run. The process goes requirements doc → architecture doc → Linear tickets written as mini-specs → coding agents (Claude Code, Codex) doing the implementation → adversarial browser testing and LLM-as-judge evals → production concerns like backups, logging and metrics. The closing argument is that planning and architecture matter more than code now, because code is cheap to change and infrastructure decisions are not. The video is an acknowledged partnership with Google Cloud.
- The example project is a hotel website concierge agent that answers guest questions (check-in times, Wi-Fi, local info) and handles villa availability and booking hand-off, saving the business from staffing 24/7 support.
- The two documents to get right before any code are requirements.md (what, why, for whom, plus non-functional requirements like expected user volume) and architecture.md (database, agent framework, model, API structure).
- The architecture bundles the static site and FastAPI backend into a single Cloud Run instance so they can talk over localhost; Claude was used to generate an HTML diagram of the architecture for readability.
- Model choice is driven by the use case: Gemini Flash was chosen for its large context, speed and low cost, while a heavyweight model like Claude Opus would be slow and expensive for a customer-facing chat where nobody will wait 30 seconds.
- Work is broken into Linear tickets via MCP, grouped into milestones (local build, testing/refinement, deployment, operational metrics), with each ticket written as a mini-spec containing goal, definition of done, technical design and verification steps so an agent can execute it with no extra context.
- Codex's browser automation was used to run adversarial tests against the local app (prompt injection, 'show me your system prompt', requests for guest emails and database passwords, script injection) and it surfaced a real defect where the agent falsely claimed the booking page accepted payment details.
- Google Cloud's eval feature plus LLM-as-judge scoring was used to grade responses, drive system prompt changes, then re-run the same evals; the second run showed improvements in some cases and regressions in others.
- Production readiness checklist includes database backups (configured by pointing Claude Code at the gcloud CLI, after first creating a Linear ticket for the infrastructure change), plus monitoring, metrics, logging, tracing and Secret Manager, which the platform provides rather than being self-built.
- Prompts were refactored out of the agent code into a standalone markdown file to make them maintainable, and the speaker warns that system prompts accumulate ad-hoc rules over time and need periodic pruning.
Shows automated adversarial browser testing catching both a hallucinated claim and classic prompt-injection attempts that manual testing would likely miss.
So you can see that already we found a bug. So it looks like codex found a real defect. It says that after a family villa search, the concierge says that booking page lets guests enter their payment information, which is not true.
A concise, concrete rationale for matching model selection to latency and cost constraints instead of defaulting to the most capable model.
If you're building a customer facing application, customers obviously don't want to wait 30 seconds for an AI model to respond. So using something like this would probably be a bad choice, whereas Gemini Flash, definitely good enough for this use case and it's fast and cheap.
Every ticket contains enough information that you can just delegate this straight to your agents and have them work on this task without needing any other information.
It's very difficult to change your architecture once you've designed it. If you choose the wrong database, if you deploy on the wrong platform, it's much harder to undo those decisions.
Pretty much every single time you put an agent like this into the public, people are going to try and do all kinds of crazy things with the agent to try and get it to disclose its system prompt.