DEV Community: Sireesha Pulipati

Vibecoding EventMatch, built with Antigravity, ADK, and Gemini

Sireesha Pulipati — Thu, 13 Aug 2026 04:18:51 +0000

Every week I get invited to more AI events than I can attend. Bond AI, Founders Bay, AI Collective, half a dozen other newsletters, each one dropping a handful of events into my inbox with no way to tell, at a glance, which ones I’m actually free for. Public aggregators like Luma and Eventbrite don’t help either. The interesting events, the ones from niche community newsletters, never show up there in the first place. If you live in a city like New York or San Francisco, this is a familiar kind of overload, too many good options, scattered across too many places, with no single view of what actually fits your week.

So I built EventMatch. And I vibecoded it, using Antigravity, Gemini 3.5 Flash, and Google’s Agent Development Kit.

Code · Kaggle writeup

Here’s the walkthrough, what I wanted the app to do, how the agents are put together, and what building it actually taught me.

What I wanted the app to do

The core ask was simple to state and harder to deliver. Pull events from public platforms and from the private newsletters sitting in my inbox, check every one of them against my real calendar, and only show me what’s actually conflict free.

A few things went beyond that baseline. Preferences needed to be conversational, not a set of rigid tags, something like “a mix of tech networking, AI workshops, creative art showcases, and relaxed social gatherings,” not a checkbox list. And those preferences needed to stay stable. If I ask a one off question like “show me free events this weekend,” that shouldn’t silently overwrite my standing preferences. Only an explicit request to update them should.

The rest was polish that ended up counting for more than I expected. Price shown as a tier, free, , $ , $$$, instead of raw text pulled from the source. One register button per event, not two competing ones in the same modal.

The multi agent architecture

EventMatch runs on ADK 2.0, and the workflow alternates between plain Python nodes and LLM agents. That alternation is the whole design.

prepare_extractor (Python) sanitizes the incoming message and reads the current session state.

preference_extractor (LlmAgent) parses the user’s message to pull out location, and decides whether this is a persistent preference change or a one off search.

filter_events_node (Python) pulls public data from Luma and Eventbrite, triggers background fetches from Gmail and Google Calendar, and merges everything. This is where the actual grounding happens. It runs a millisecond level time overlap check against the live calendar and flags conflicts before anything reaches the model, and converts events to plain text descriptions to keep the token count down for the next step.

vibe_ranker (LlmAgent) takes the conflict free events and scores them against the user’s preferences, 0 to 100, with a short explanation for each one.

formatter_node (Python) closes the loop, and it’s the piece that holds the whole system together. The vibe_ranker only ever sees plain text descriptions and returns ranked IDs. formatter_node takes those IDs and re-joins them against the original database records. Registration URLs, host names, event locations, none of it passes through the model twice.

Python does the things Python is reliable at, filtering, matching, deduplicating. The LLM does the one thing it’s actually needed for, judging fit against a vague preference. An LLM asked to both evaluate and format a result will, often enough, paraphrase a URL wrong or invent a detail that sounds plausible. Keeping those two jobs separate removes that failure mode instead of trying to prompt it away.

Integrations

Underneath the agents is a fairly ordinary web app, FastAPI on the backend, Python 3.11, React on the frontend, built with Vite and Tailwind.

The integration that makes everything else possible is OAuth. EventMatch requests read only scopes for Gmail and Calendar through Google’s official client libraries. Once authorized, the backend caches the credentials and the UI shows the connected account in the navbar. Everything downstream, the newsletter parsing, the conflict checking, only works because that connection is live.

Public event data comes from Luma and Eventbrite, which meant working around scraping restrictions rather than clean APIs. Deployment is Docker on Cloud Run, provisioned with Terraform.

Building it, and what it taught me

I built this in Antigravity, following a spec driven process rather than jumping straight into code. Start with a product requirements document. Turn that into a high level design. Turn the design into a spec detailed enough for an agent to build from. Only then does actual development start.

Coding a working app over a weekend is genuinely exciting. It’s also where that process got tested, and where it broke down. The pattern showed up early and kept showing up. Fix one bug, move to the next, fix that one, and the first bug resurfaces. Back and forth, the same category of issue reappearing in a slightly different shape each time.

The spec was the actual problem. When the requirements document and the spec are vague about what the app needs to do and what it needs to be tested against, the agent has room to solve the same problem two different ways in two different places, and neither implementation knows about the other. Every fix becomes local. Nothing stays fixed.

The fix is spending more time upfront, at the PRD stage and the spec stage, reviewing what the agent actually produced there before writing a line of application code. Get the spec and the test plan tight enough that they cover what “done” actually means, and the back and forth during development drops off. Skip that step, and you pay for it later, one resurfacing bug at a time.

Google's AI tools for developers and enterprise, and when to actually reach for each

Sireesha Pulipati — Mon, 03 Aug 2026 21:51:04 +0000

Beyond the consumer surfaces most people know, the Gemini app and Gemini Notebook (formerly NotebookLM), Google offers a whole set of AI tools and interfaces built for developers and enterprise teams. At first glance, it's a lot to wrap your head around. AI Studio, Gemini Enterprise Agent Platform, the Gemini Enterprise app, Antigravity in its various forms. The names overlap, the marketing language overlaps, and it's not obvious where one tool's job ends and another's begins.

AI Studio is for prototyping and building web and Android apps

AI Studio is where you test a prompt, try a multimodal input, or compare models before committing to anything. It also builds full applications straight from a prompt, complete with backend infrastructure. When your app needs to store data or handle sign-ins, AI Studio provisions a database and authentication for you, either Cloud Firestore or Cloud SQL for a relational setup, and Firebase Authentication, without you configuring any of that by hand. It also connects to Google Workspace APIs, so an app you build there can work with a user's real Gmail, Docs, Sheets, or Calendar data. It supports mobile app development as well, for native Android apps.

Use AI Studio when you want to validate an idea or ship a lightweight web or Android app fast, with real backend support, and without provisioning any Google Cloud infrastructure yourself.

Gemini Enterprise Agent Platform is where agents actually get built

This is the next generation of Vertex AI. Google folded Vertex AI's entire service catalog, model access, custom training, evaluation, pipelines, all of it, into what's now called the Agent Platform. If you go looking for Vertex AI in the console today, it redirects you here.

This is the one-stop shop for the full agent development lifecycle. You build with Agent Studio, the low-code visual builder, or the Agent Development Kit for code-first development in Python, Go, Java, or TypeScript. Agent Engine handles the managed runtime, Model Garden gives you access to over 200 models including Gemini and Claude, and the governance layer, IAM, VPC-SC, compliance controls, gives a production agent what it needs to survive a security review.

Use this when what you're building needs to act with real autonomy inside your enterprise environment, holding state and making decisions across steps.

Gemini Enterprise app is for business users and knowledge workers

This is the surface your non-technical colleagues will actually touch. A SaaS chat interface, grounded search across Drive, SharePoint, and Jira, no-code agent creation for business users, all without opening the Agent Platform directly. If your job is to register, govern, and hand off an agent so people across the org can use it, this is the distribution layer.

The Agent Platform builds the agent. The Enterprise app is how it reaches an employee, packaged for their actual job.

Antigravity is a bundle of tools

Each piece in the bundle enables a different way of working with the same underlying coding agent.

Antigravity IDE is for interactive, local, visual development. It's VS Code-style, with the agent chat sitting next to your code and inline diffs as it works. This is for engineers doing day-to-day, hands-on development with an AI partner sitting next to them.
Antigravity 2.0 is a standalone desktop app. It runs multiple agents in parallel across different projects, handles scheduled or cron-based tasks, and produces reviewable output. This is for delegation at a higher level.
Antigravity CLI is the terminal-native surface. Scriptable, headless, built for CI/CD pipelines and shell-level workflows.
Antigravity SDK is what you use when you want the agent loop itself embedded inside your own code, particularly Python-based systems. You call it from your own code, the same way you'd call any other library.

Underneath all of them sits the same agent harness, the actual execution engine that runs code, executes shell commands, browses the web, and does the multi-step work autonomously. It powers the IDE, the CLI, and the SDK from underneath, so improvements to the core agent land on all three surfaces at once.

Where this leaves you

Need	Tool	Why
Validate an idea or ship a lightweight web or Android app fast	AI Studio	Full-stack app building with automatic backend and auth, no infra setup
Build a governed, autonomous agent for production	Agent Platform	Full agent development lifecycle, IAM, VPC-SC, compliance
Roll an agent out to non-technical staff	Gemini Enterprise app	No-code distribution, grounded search
Hands-on coding with an AI partner	Antigravity IDE	Interactive, visual, local development
Delegate multiple background tasks	Antigravity 2.0	Async, parallel, scheduled work
Terminal or CI/CD automation	Antigravity CLI	Scriptable, headless
Embed the agent loop in your own code	Antigravity SDK	Programmatic, especially Python systems

Once you know what each of these actually does, the overlapping names stop being confusing. AI Studio for prototyping and lightweight apps, the Agent Platform for production agents, the Enterprise app for distribution, Antigravity for the coding work itself. Pick based on what you're building and who it's for.

Guarding the till while autonomous data agents do the digging

Sireesha Pulipati — Thu, 09 Jul 2026 22:24:23 +0000

Autonomous agents are genuinely good at answering messy business questions. Give one an LLM and a set of tools, and it can query a database, dig through files, and build a chart to investigate why a metric moved. No fixed script required.

The problem is what happens when nobody’s watching the meter.

If a question is simple, you don’t need an agent. You write one SQL query and you’re done. But most real analytical questions aren’t simple. They’re ambiguous, open ended, and take a few rounds of trial and error before they resolve. An agent handles that the way a human analyst would if you turned them loose on a data warehouse with no supervision. It tries a query, gets a weird result, tries a different angle, hits a dead end, and tries again.

On a warehouse the size of BigQuery, that trial-and-error loop gets expensive fast. Add in the token costs of a long-context LLM reasoning through fifteen turns, and a single agent run can blow past your budget before anyone notices.

In this post, I’ll walk through how I built a cost-safe version of this kind of agent, using the Google Antigravity SDK and the Data Agent Kit (DAK) extension. Two guardrails do the work.

A BigQuery scan cost guardrail. It dry-runs every query before it executes and blocks anything that would scan too much data.
An LLM token spend guardrail. It pauses the agent for human approval once a session crosses a token budget.

Why autonomous analysis runs amok at scale

To see why this matters, it helps to look at how BigQuery bills, how agents actually reason, and where the two collide.

The columnar trap

A lot of people assume that adding a LIMIT 10 or a WHERE clause keeps a query cheap. In a columnar database like BigQuery, that assumption will bite you.

BigQuery charges by the bytes it reads from the columns you reference, across the whole table, not the rows you end up seeing. Run something like SELECT body FROM comments WHERE body LIKE '%pandas%' and it scans the entire body column for every row before it even gets to filtering. There's no row-level index to jump to matching rows, so evaluating that filter means reading every value in the column first. The LIMIT clause runs after that scan is already paid for, so it doesn't save you anything.

The only real lever is filtering on a partitioned column, which restricts the query to specific physical blocks like a date range, or a clustered column, which prunes blocks based on sorted keys.

Why agentic exploration is so inefficient

A human analyst scopes a query carefully before running it. An agent doesn’t work that way. It loops.

For an open-ended problem, the path usually looks like this. It runs a few queries to discover table structures and columns. It tries different combinations of joins, filters, and aggregations to test its hypotheses, and when it hits an empty result or a syntax error, it rewrites and tries again. It runs heavy string scans, LIKE '%error%' across a text column, to pull out logs or comments. And when it needs to merge sources, it runs wide multi-key joins that shuffle data across worker slots.

Here’s where it gets real. In a production environment with tables in the hundreds of terabytes, a single on-demand query scanning 100 TB of one column costs $625 at standard $6.25/TB pricing. Stack a few window functions and nested joins on top and you’re triggering shuffle operations that move gigabytes between worker slots. If you’re on capacity-based billing instead of on-demand, those same queries burn through slot-hours and degrade everyone else’s performance.

An agent running fifteen turns of unoptimized exploratory queries on TB-scale tables can rack up thousands of dollars in a single run. That’s not a hypothetical. That’s what happens the first time you point one of these things at a real warehouse without a guardrail.

Investigating dev sentiment and tech stack health

To build and test this, I used the Stack Overflow dataset from BigQuery Public datasets.

Here’s the question I tried to get the answer to:

Developer engagement metrics for Python data science libraries (pandas, numpy) on Stack Overflow dropped in late 2023. Answer rates and comment volumes fell. Did that correlate with a specific library release? Was it a boycott, or something more transient?

That’s a genuinely open-ended problem, and answering it takes a few steps. First, verify the trend actually happened, and check whether it was unique to pandas and numpy or part of a broader Stack Overflow slowdown (a seasonal dip, or the rise of ChatGPT, would show up across all topics). Second, cross-reference the comment trend with PyPI download stats to see whether people actually stopped installing the library, or just stopped needing to ask about it, say, after pandas 2.1 shipped in September 2023. Third, run text searches on the comments themselves to find the specific error messages or breaking changes people were complaining about, like the PyArrow dependency changes.

To run this without setting up a bunch of infrastructure, the agent queries across two systems. BigQuery holds the Stack Overflow public dataset (bigquery-public-data.stackoverflow), hundreds of gigabytes of partitioned post and comment data. A local CSV holds monthly PyPI download rates for pandas and numpy.

Wiring up Data Agent Kit and Antigravity

Data Agent Kit (DAK) runs as an extension inside the Antigravity IDE or CLI, and it handles the data-connection plumbing so you don’t have to.

It exposes database tools as MCP servers, bigquery_remote being the one I used here, which run remotely in GCP and talk directly to your data in BigQuery. It also ships filesystem-based Agent Skills for performing various data operations, such as data cleaning, building data pipelines, querying data etc., using Google Cloud services and standard tools such as Python and Notebooks. Skills are pre-packaged directories with standard SKILL.md instruction files and references.

Once you install DAK in your IDE, you configure it with the Google Cloud Project you want to work with. The MCP tools and skills get injected into the agent’s workspace automatically. I didn’t have to write connection pooling, manage GCP credentials by hand, or wire up custom Python imports for BigQuery access.

The Antigravity SDK sits on top of that as the agent runtime. It’s where I write the governance logic, the lifecycle hooks that intercept and control whatever tools DAK injects. That’s where the guardrails live.

from google.antigravity.hooks import policy

# 2. Config is clean: the IDE automatically injects DAK tools and skills
config = LocalAgentConfig(
    system_instructions="You are an autonomous data investigator...",
    policies=[
        policy.deny("search_web")           # Force the agent to use BigQuery instead of search shortcuts
    ],
    hooks=[
        bq_cost_guardrail_hook,             # Intercepts the injected BQ tool for dry-run check
        check_token_budget_hook             # Intercepts chat turns for budget validation
    ]
)

Splitting the data platform layer (DAK) from the agent harness layer (Antigravity SDK) is what makes this clean. The guardrails live as harness hooks, and DAK just handles the database connections underneath.

Guardrail 1: the BigQuery scan cost guardrail

This one intercepts SQL queries with the Antigravity SDK’s @hooks.pre_tool_call_decide hook.

Before a query runs, I do a dry run. It’s a free operation, and it tells you exactly how many bytes the query will scan. If that number blows past the budget, the call gets rejected and the agent gets a message back telling it why, so it can rewrite the query with a proper partition filter.

One thing worth saying up front. The 10 GB limit below is small on purpose, small enough that you’ll actually see the guardrail trigger and self-correct within a couple of turns. Your real limit depends on your table sizes, your pricing tier, and what you’re actually willing to spend on a single exploratory query. Treat it as a placeholder and set your own before you point this at a real workload.

from google.cloud import bigquery
from google.antigravity import types
from google.antigravity.hooks import hooks

# Cost settings
SINGLE_QUERY_SCAN_LIMIT_GB = 10.0  # 10 GB limit per query
BQ_PRICE_PER_TB = 6.25             # Standard BigQuery on-demand pricing

def estimate_bq_query_cost(sql: str) -> tuple[float, float]:
    """Perform a dry run to estimate the query scan size and cost."""
    client = bigquery.Client()
    job_config = bigquery.QueryJobConfig(dry_run=True, use_query_cache=False)
    try:
        query_job = client.query(sql, job_config=job_config)
        bytes_scanned = query_job.total_bytes_processed
        gb_scanned = bytes_scanned / (1024 ** 3)
        cost = (bytes_scanned / (1024 ** 4)) * BQ_PRICE_PER_TB
        return gb_scanned, cost
    except Exception:
        # If the dry run fails (e.g. syntax error), let the actual query run fail naturally
        return 0.0, 0.0

@hooks.pre_tool_call_decide
async def bq_cost_guardrail_hook(data: types.ToolCall) -> types.HookResult:
    # Intercept BigQuery tool execution from DAK MCP tools
    if data.name in ["execute_sql", "execute_sql_readonly", "query_bigquery"]:
        sql = data.args.get("sql") or data.args.get("query")
        if not sql:
            return types.HookResult(allow=True)

        gb_scanned, cost = estimate_bq_query_cost(sql)
        # Print status so users running this in a terminal can see the guardrail in action!
        print(f"\n[Guardrail Check] Intercepted Query: {sql[:120].strip()}...")
        print(f"[Guardrail Check] Estimated Scan: {gb_scanned:.2f} GB (Estimated Cost: ~${cost:.4f})")

        if gb_scanned > SINGLE_QUERY_SCAN_LIMIT_GB:
            error_message = (
                f"Query rejected by Cost Guardrail! "
                f"This query is estimated to scan {gb_scanned:.2f} GB of data (costing ~${cost:.4f}), "
                f"which exceeds your safety limit of {SINGLE_QUERY_SCAN_LIMIT_GB} GB per query. "
                f"Please rewrite your query to limit scan costs by filtering on partitioned/clustered "
                f"columns (e.g., creation_date) and avoiding SELECT *."
            )
            print(f"❌ [Guardrail Triggered] BLOCKING query scan ({gb_scanned:.2f} GB > {SINGLE_QUERY_SCAN_LIMIT_GB} GB).")
            # Block the tool execution and send the guidance back to the agent's context
            return types.HookResult(allow=False, message=error_message)
        else:
            print(f"✅ [Guardrail Approved] Query scan approved ({gb_scanned:.2f} GB <= {SINGLE_QUERY_SCAN_LIMIT_GB} GB).")

    return types.HookResult(allow=True)

Here is the visual flow of how this cost interceptor and the agent self-correction loop function:

The Agent Self-Correction Loop

When the agent receives this rejection as the “tool result,” its LLM reads the guidance, understands the partition requirement, and automatically rewrites the query. Here is what the self-correction log looks like when the agent attempts a raw scan:

[Agent Turn 1]
Thinking: I need to analyze comment text containing "pandas". Let me query the comments table.
Tool Call: execute_sql_readonly(sql="SELECT text FROM `bigquery-public-data.stackoverflow.comments` WHERE text LIKE '%pandas%'")

[Guardrail Triggered]
System Hook: Query rejected by Cost Guardrail! This query is estimated to scan 14.09 GB of data (costing ~$0.09), which exceeds your safety limit of 10.0 GB. Please rewrite your query to filter on partitioned columns (e.g., creation_date).

[Agent Turn 2]
Thinking: Ah, my query was blocked because it scans the entire comments table. I should restrict the scan size by adding a date filter. The 'comments' table is partitioned by 'creation_date'.
Tool Call: execute_sql_readonly(sql="SELECT text FROM `bigquery-public-data.stackoverflow.comments` WHERE creation_date >= '2022-01-01' AND creation_date < '2022-02-01' AND text LIKE '%pandas%'")

[Guardrail Approved]
System Hook: Query estimated to scan 1.8 GB. Approved.

Guardrail 2: the LLM token spend guardrail

The BigQuery guardrail watches the data layer. This one watches the reasoning budget.

Autonomous agents run in a loop, and every turn the conversation history grows, more prompts, more tool calls, more results, more reasoning steps. Token usage climbs with it, and so does your API bill.

Because the Antigravity SDK manages the agent’s internal reasoning loop asynchronously inside a single await agent.chat() call, you can't just check usage in a manual loop. You need an SDK hook. I built a stateful manager that checks the conversation's total_usage before each turn and asks a human for confirmation if the budget is breached.

import asyncio
from google.antigravity import Agent, LocalAgentConfig, types
from google.antigravity.hooks import hooks

class SessionGuardrail:
    def __init__(self, token_budget: int):
        self.token_budget = token_budget
        self.agent = None

    def register(self, agent: Agent):
        """Bind the agent reference to the guardrail manager."""
        self.agent = agent

    async def check_token_budget(self, data: str) -> types.HookResult:
        """Intercept before a chat turn starts to enforce the token budget."""
        if self.agent and self.agent.conversation:
            usage = self.agent.conversation.total_usage
            # Show active token monitoring in the terminal on every turn
            print(f"[Token Monitor] Session token count: {usage.total_token_count:,} / {self.token_budget:,}")

            if usage.total_token_count > self.token_budget:
                # Prompt the user asynchronously for authorization
                print(f"\n[Budget Alert] Cumulative token usage is {usage.total_token_count}. Budget is {self.token_budget}.")
                confirm = await asyncio.to_thread(input, "Authorize additional tokens? (y/n): ")

                if confirm.strip().lower() != 'y':
                    return types.HookResult(
                        allow=False,
                        message=f"Session suspended: Token budget of {self.token_budget} exceeded."
                    )
        return types.HookResult(allow=True)

One thing I want to call out here:

Using input() wrapped in asyncio.to_thread is a fast way to demonstrate human-in-the-loop validation from a local terminal, but it won't hold up in production. Blocking stdin reads can hang the event loop or throw an EOFError in a web backend, a CI runner, or a notebook. For anything real, swap the CLI prompt for an async request to a Slack webhook, a PagerDuty trigger, or a queue that resolves when someone clicks approve.

Running the safe agent loop

Now it all comes together in one config. The token budget here is another demo value. 150,000 tokens is enough to watch the guardrail trigger without waiting forever, not a number to carry into production. Set yours based on your actual session lengths and what a runaway session would cost you.

import asyncio
from google.antigravity import Agent, LocalAgentConfig
from google.antigravity.hooks import hooks, policy

# Global instance of the guardrail manager to hold state
guardrail = SessionGuardrail(token_budget=150_000)

@hooks.pre_turn
async def check_token_budget_hook(data: str) -> types.HookResult:
    return await guardrail.check_token_budget(data)

async def run_safe_investigation():
    # 1. Register cost guardrail hooks — DAK tools and skills are injected automatically by the IDE
    config = LocalAgentConfig(
        system_instructions=(
            "You are an autonomous data investigator. "
            "When outputting your reasoning, steps, or planned actions, you MUST format them clearly "
            "with newlines, bullet points, and spacing so they are clean and readable in a terminal console. "
            "Do not merge your planned actions into a single dense paragraph."
        ),
        policies=[
            policy.deny("search_web")     # Force the agent to use BigQuery instead of search shortcuts
        ],
        hooks=[
            bq_cost_guardrail_hook,       # Intercepts SQL queries
            check_token_budget_hook       # Intercepts chat turns
        ]
    )

    # 3. Execute the agent
    async with Agent(config) as agent:
        guardrail.register(agent)  # Give the manager access to the running agent

        user_query = (
            "You MUST run a live SQL query (using execute_sql or query_bigquery) to search the Stack Overflow "
            "comments table for pandas comments in Q4 2023, even if you think the table is unpartitioned. "
            "Use the standard file writing tools (like write_file) to save the final markdown report as "
            "'output/analysis_results.md' and the script as 'output/analyze_pandas.py' in the workspace. "
            "Do not use the save_artifact tool."
        )
        response = await agent.chat(user_query)
        print(await response.text())

if __name__ == "__main__":
    asyncio.run(run_safe_investigation())

Getting your hands dirty

Ready to run this yourself? Here’s the walkthrough.

Step 1: clone the repo and look around

git clone https://github.com/sireeshapulipati/guarding-the-till.git
cd guarding-the-till

The directory splits into two clean categories. The inputs, what you actually need to run it, are agent.py (setup, hooks, and the execution loop), requirements.txt, data/pypi_downloads.csv (monthly PyPI download stats for pandas and numpy), and .env.example. The outputs are pre-generated reference examples. output/analysis_results_example.md is the full markdown report from my run, and output/analyze_pandas_example.py is a standalone cost-guarded script the agent wrote to automate this in the future.

Step 2: sort out the GCP prerequisites

Before you boot the agent, make sure your terminal has access to Google Cloud. You need a project with the BigQuery API enabled, and you need to authenticate with Application Default Credentials.

gcloud auth application-default login

You’ve got two options here, and the .env.example file lays both out. Authenticate with ADC like above and the Antigravity SDK picks up your active GCP context automatically, hooking straight into Vertex AI's Gemini models, as long as the Gemini for Google Cloud API is enabled on your project. Or skip GCP auth entirely and drop a Gemini API key straight into .env instead. Either path works, pick whichever fits how you're already set up.

Step 3: spin up your Python environment

python -m venv .venv
source .venv/bin/activate  # On Windows, use: .venv\Scripts\activate
pip install -r requirements.txt

Step 4: configure your environment variables

cp .env.example .env

Open .env and swap your_gcp_project_id_here for your actual GCP project ID.

Step 5: let it run

python agent.py

Watch the logs. The agent starts up, formulates a plan, and immediately goes for the comments table. Agents are non-deterministic, so your exact run will vary depending on the prompt, but here’s roughly what happens.

The session opens with the token monitor reporting the starting count, something like [Token Monitor] Session token count: 0 / 150,000. This demo wraps in a single turn, so that's the only time you'll see it print. In a longer run with several self-correction turns, it fires at the start of each one, printing the cumulative count and pausing for approval once you cross budget. From there the agent reads the local files and narrates its plan, inspect the schema, then query Stack Overflow comments in BigQuery.

Then it tries the raw query, and the guardrail catches it before it runs. A dry run against the unpartitioned comments table comes back at 14.09 GB, over the 10 GB limit, so the hook blocks it and hands the rejection back as feedback. The agent reads that, realizes it needs the creation_date partition filter, rewrites the query, and resubmits. This time the scan comes in at 1.8 GB and gets approved.

Once the analysis wraps, the agent reaches for its file tools and writes the results straight into ./output/, a markdown report as analysis_results.md and a standalone script as analyze_pandas.py

Interpreting the results

Here is what the agent found:

Month	Pandas PyPI Downloads	Download MoM %	Pandas SO Comment Count	SO MoM %
Oct 2023	150,354,240	Baseline	6,210	Baseline
Nov 2023	147,923,892	-1.62%	5,845	-5.88%
Dec 2023	151,553,549	+2.45%	5,420	-7.27%

The agent calculated a Pearson Correlation Coefficient of $r \approx -0.3654$.

This is a weak-to-moderate negative correlation. Under normal circumstances, you would expect forum questions to rise as library installations rise. Instead, we see:

Installations increased: PyPI downloads reached their highest volume of the quarter in December (151.5M downloads).
Stack Overflow comments decreased: Stack Overflow comments mentioning pandas steadily declined month-over-month, dropping from 6,210 in October to 5,420 in December.

This divergence is likely driven by seasonality. In December, human developers take vacations and stop posting questions or answers on public forums, leading to a dip in active comments. Meanwhile, automated build systems, CI/CD runners, and deployment scripts continue pulling the package continuously, keeping the download numbers high.

What’s the standalone script for?

The agent also wrote output/analyze_pandas_example.py as part of its delivery. If you want to rerun this analysis every month in a production pipeline, an Airflow DAG, a cron job, you don't need to run the slow, non-deterministic agent loop again. Just run this.

python output/analyze_pandas_example.py

It’s a fast, deterministic ETL pipeline. It queries BigQuery, calculates the correlation, and spits out a fresh markdown report, no LLM reasoning layer involved, while keeping the exact same dry-run safety guardrails.

What I took away from this

These two guardrails do two different jobs. The BigQuery dry-run watches the data layer and stops runaway scan bills before they happen. The session token guardrail watches the reasoning layer and caps what the LLM itself costs you. Together they give the agent a bounded sandbox to actually explore in.

The semantic error feedback is what actually makes this useful. Instead of a fatal exception that kills the run, the scan guardrail hands the LLM a plain-language explanation of what went wrong. That turns a runtime constraint into something the agent can actually act on, and it rewrites its own query instead of just failing.

And wrapping the token budget check in a non-blocking async hook means the human-in-the-loop step doesn’t freeze the rest of the system while it waits for someone to click approve.

If you’re building agents that need to explore large, cross-system datasets, this is the difference between an agent you can trust with a warehouse and one you have to babysit.

I use AI to write. The fear: everyone starts sounding the same. Real risk, but only if you skip making it yours. Where do you draw the line? More here: https://sireeshap.substack.com/p/there-is-nothing-formulaic-about?r=3alo35

Sireesha Pulipati — Sat, 20 Jun 2026 00:04:39 +0000

There is nothing formulaic about how I write

On patterns, tells, and what voice actually is

sireeshap.substack.com

Agents are building their own UIs now. Here's when that's worth doing.

Sireesha Pulipati — Wed, 29 Apr 2026 21:02:06 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

During the developer keynote at Google Cloud NEXT '26, Google built an entire multi-agent system live on stage: a marathon planner that simulates routing a race through Las Vegas. The demo wasn’t just about the agents coordinating route planning, logistics, and runner simulation. It was about the interfaces those agents generated on the fly.

The route planning view showed a map with the proposed path, landmarks, and distance markers. The evaluation view displayed score breakdowns with both deterministic criteria (exactly 26.2 miles) and nondeterministic ones (community impact). The simulation view tracked live runner positions, traffic patterns, hydration stations, and Port-A-Potties. Each phase needed a different interface, and the agent built what it needed in real time using A2UI and the GenUI SDK for Flutter.

The keynote also highlighted FinnishIt, an AI-powered Finnish language tutor built with GenUI. Give it a topic and it generates custom flashcard decks specific to that context. Role-play scenarios shift from text exercises to tap-and-drag word puzzles to fill-in-the-blank modules depending on what the AI assesses you need right now.

Every session produces a different interface.

That's the point where I stopped treating A2UI as conference noise and started paying attention.

A2UI is an open standard Google donated to the community at NEXT '26. It lets agents generate UI dynamically at runtime. The GenUI SDK for Flutter is the developer-facing layer that makes it practical to build with. Most coverage either skipped it or described it without asking the more useful question: when does this actually make sense to use?

Where GenUI earns it

The marathon planner works because the interface IS the orchestration experience. Different workflow phases need different visualizations: route planning requires a map, evaluation needs scoring charts, simulation shows a live timeline.

FinnishIt works the same way for adaptive learning. There's no predetermined layout that serves a user practicing spoken conversational Finnish the same as one drilling grammar for the YKI citizenship test.

The right exercise type, difficulty, and interaction pattern depend on what the AI assesses the user needs right now. Hardcoding any of that produces a worse product.

The dynamic generation isn't a feature on top of the app. It is the app.

The same logic applies to onboarding flows, and this is where I think GenUI has untapped potential.

Most onboarding flows are static decision trees in disguise. You collect preferences on screen one, goals on screen two, then route users down one of two or three predetermined paths. The result feels personalized but is just filtered content behind a fixed interface.

Consider a personal finance app. Someone who opens it saying "I want to stop overspending" has a completely different mental model than someone who says "I want to start investing" or "I have irregular income and need to plan around it." Those aren't just different content buckets. They're different journeys, with different concepts to introduce, different decisions to make up front, and a different definition of what "getting to value" even means.

A GenUI-powered onboarding flow could read what a user brings to that first session and generate the next step as a direct response: not a static screen two, but a computed one.

A personal style app makes the case even more clearly, because here the interaction type itself changes, not just the content.

Someone who opens a style app saying "I have a job interview next week" needs an occasion-specific outfit construction flow: clear goal, tight timeline, specific constraints. Someone who says "I'm trying to figure out my personal style" needs a discovery experience: visual-first, exploratory, maybe swipe-on-images or mood board style. Someone who says "I want to build a capsule wardrobe on a budget" might need a wardrobe audit flow that starts with photographing what they already own.

These are not variations on the same form. They require different interface primitives: camera, swipe cards, visual grids, checklists. GenUI earns it here because you genuinely cannot know which one to show until the user tells you what they're trying to do.

The right interaction depends on the context. The context arrives at runtime.

A decision filter

Before reaching for GenUI, three questions:

Is the interface the experience, or is it a container for a fixed one?
In FinnishIt, the dynamically generated exercise is the product. That's different from a news reader or a task manager, where content arrives through a stable interface. Not every app benefits from a layout that changes each session.

Does the user need to find the same thing in the same place next time?
Adaptive learning, personalized onboarding, style discovery: each session is meant to feel different. An e-commerce checkout, a settings screen, a navigation menu: users build trust and speed through repetition. Those interfaces earn nothing from variation.

Is this an exploratory action, or one that requires confident understanding of what's about to happen?
Payment confirmation, account deletion, anything irreversible: users need to know exactly what they're looking at. Dynamic layout introduces uncertainty at exactly the wrong moment.

Where it doesn't fit

The failure cases aren't about regulation or compliance. They're about what users need from an interface to trust it.

A checkout flow that looks different each time isn't personalization. It's friction.

High-frequency task interfaces derive part of their value from the fact that users can operate them without thinking. Email, task management, booking flows: variability works against that entirely.
There's also a quieter design system concern. Most product teams ship against a component library: specific tokens, spacing rules, interaction patterns. An agent that approximately matches those patterns is not the same as one that respects the contract. That gap shows up in production in ways that are hard to articulate and easy to notice.

The open bet

A2UI and GenUI aren't solutions looking for a problem. There's a real category of app where static UI has always been the wrong answer: the kind where the right interaction depends on context that only arrives at runtime.

FinnishIt is an early, polished example of what that looks like when it's done well. Personalized onboarding, adaptive learning, style discovery: same category.

What I'm watching is whether developers build intuition for where this pattern belongs, or whether the next few years surface a wave of apps that introduced variability in exactly the places their users needed stability.

If you've seen agent-generated UI get it right, or quietly get in the way, I'd like to hear about it.

Why the Google Cloud Professional Data Engineer Certification Still Matters in an AI-First World

Sireesha Pulipati — Wed, 28 Jan 2026 05:57:23 +0000

Have you found yourself wondering recently whether cloud certifications still matter, especially now that AI can write SQL, generate pipelines, and suggest architectures?

Short answer: yes, arguably more than ever.

But the value just is not the credential. It is the depth of understanding the preparation forces you to develop.

The Google Cloud Professional Data Engineer certification was never about memorizing services or APIs. At its core, it has always been a structured way to internalize how data systems should be designed, operated, and evolved in real production environments.

In an AI-enabled world, that foundation matters more, not less.

Certification prep is about judgment

AI tools are powerful accelerators. They can draft code, propose architectures, and help debug issues. What they cannot reliably do is exercise engineering judgment in complex, real-world constraints.

Preparing seriously for the PDE exam pushes you to reason through questions such as:

When does streaming actually make sense versus batch?
How should reliability, cost, security, and governance be balanced?
What tends to fail first at scale, and how should systems be designed for that?
When is a simpler design the correct decision?

These are not trivia questions. They reflect the decisions practicing data engineers make every day. The exam tests whether you can reason through trade-offs, not whether you recognize product names.

How the exam has evolved

The Professional Data Engineer exam has evolved alongside the platform and the role itself.

Six or seven years ago, the exam covered a much broader surface area. It included significant emphasis on databases, analytics, and machine learning concepts. That breadth made sense at the time. Cloud data roles were still forming, and boundaries between responsibilities were less clear.

What has changed since then is not the philosophy of the exam, but its focus.

As Google Cloud introduced more specialized certifications, such as Associate Data Analyst, Professional Machine Learning Engineer, and Professional Database Engineer, those adjacent concerns moved into their own lanes. The PDE exam responded by narrowing its scope and going deeper.

Today, it is firmly focused on core data engineering responsibilities:

Designing secure and reliable data systems
Building and operating batch and streaming pipelines
Modeling, storing, and querying data at scale
Managing cost, automation, and operational reliability

That emphasis has always been present. What is different now is the level of concentration. With peripheral topics handled elsewhere, the exam prioritizes depth over breadth.

The quiet but meaningful 2025 exam guide update

The most recent exam guide update made this focus even clearer.

Data engineering for AI is now explicit

For the first time, the guide explicitly calls out responsibilities such as:

AI data enrichment within pipelines
Preparing unstructured data for embeddings
Supporting retrieval-augmented generation (RAG) workflows

These additions reflect how data engineering shows up in practice today.

Most data engineers are not building models end to end. They are enabling AI systems by ensuring data is reliable, enriched, governed, and retrievable at inference time. This includes handling unstructured data, managing feature pipelines, and supporting retrieval patterns that AI applications depend on.

Importantly, this does not turn the Professional Data Engineer exam into a machine learning exam. Model training and tuning remain the responsibility of ML engineers. What the PDE exam reinforces is a more fundamental truth:

AI systems succeed or fail based on data engineering quality.

The underlying competencies remain the same. Data modeling, pipeline design, reliability, cost control, and governance are still central. The difference is that the exam now names these AI-adjacent use cases explicitly, instead of assuming them implicitly.

“Data mesh” quietly disappeared

Another notable change is the removal of the explicit term “data mesh” from the guide.

This does not mean decentralization or domain ownership disappeared. It signals a shift away from buzzwords toward practical platform design, governance, and enablement. The exam now frames this work as building data platforms, not adhering to a specific architectural label.

That is a healthy evolution.

How to prepare today

If you are preparing for the PDE exam now, one principle matters more than any resource.

Do not study by service. Study by responsibility.

Map your preparation directly to the exam domains:

Designing data systems
Ingesting and processing data
Storing data
Preparing data for analytics and AI
Maintaining and automating workloads

For each domain, focus on trade-offs. Be able to explain why one approach is better than another in a given scenario. Anchor your understanding in production constraints such as cost, reliability, scale, and security. That is what the exam evaluates.

Final thought

The Professional Data Engineer certification is most valuable when treated as a learning framework, not a finish line. In a world where AI can generate solutions instantly, the differentiator is not speed. It is the ability to choose the right solution under real constraints. That is exactly what this certification, when approached thoughtfully, helps develop.