This is a submission for the Google I/O Writing Challenge

I went into Google I/O 2026 as someone still finding her footing in app development. I came out the other side genuinely excited — and a little overwhelmed — about how fast everything is moving.

I am an SDET with 9 years in software testing. A few months ago I started learning AI fundamentals and building my first real app: a family super-app that combines grocery tracking, shopping budgets, family calendar planning, and weekend activity planning all in one place. I am building it in Google AI Studio using Gemini 3 Flash Preview.

So when I watched Google I/O this week, I wasn’t watching as a passive observer. I was watching as someone actively building — and almost every announcement had me pausing the stream thinking “wait, that changes what I’m building.”

Here are the moments that hit hardest.

1. Antigravity Built a Full OS in 12 Hours for Under $1,000

This was the jaw-drop moment of the entire keynote for me.

Google unveiled Antigravity 2.0, their agent-first development platform with a new Antigravity CLI for orchestrating and building agents. But the live demo went further than any announcement slide could capture — an AI agent was given a single prompt and built a functioning operating system in approximately 12 hours at a cost of under $1,000.

Let that sink in. A full OS. Twelve hours. Less than a thousand dollars.

As someone coming from a quality engineering background with limited development experience, this felt like the ground shifting. The barrier to building software just got dramatically lower. I have been spending weeks learning how to wire up a Node.js backend. Antigravity is showing a future where you describe what you want and the agent scaffolds it, writes it, and tests it.

What this means for my app:

I am building a family app with multiple moving parts — grocery lists, budget tracking, a family calendar, a weekend planner. Normally that scope would take a solo developer months. With agentic coding tools like Antigravity, I can see a future where I describe a feature in plain English, the agent writes the code, and I use my QE skills to review and test what it produced.

That is a workflow I genuinely understand. I have been testing other people’s code for 9 years. Now the “other developer” is an AI agent, and my job is the same: find the gaps, validate the output, ship with confidence.

2. Agentic Coding in Search — Robby Stein’s Demo

The Search keynote by Robby Stein was the section I rewatched twice.

Google Search introduced an AI-powered experience that generates contextual answers, images, and short videos, making it more assistant-like in function. Generative UI was also unveiled, dynamically adjusting how results appear based on user intent.

What struck me was how Search is no longer just a lookup tool. It is starting to reason. It doesn’t just find — it understands what you are trying to accomplish and adapts the results to help you get there.

As someone building a family app, this matters because families don’t search like developers do. A parent doesn’t type “quinoa recipe low sodium 4 servings.” They type “something healthy for dinner the kids won’t complain about.” The new Search understands that intent. It adapts.

What this means for my app:

I want to build a search experience inside my family app that works the same way. Not a filter. Not a dropdown. A natural language input where a family member types “we have chicken and we’re on a budget this week” and the app understands the whole context — the ingredients they have, their budget remaining, what’s already on the grocery list — and surfaces a meal plan that fits.

That’s the bar Google just set. And it’s the bar I’m now designing toward.

3. Gemini Spark — The 24/7 Background Agent

Gemini Spark is a new AI agent that lives in the cloud and works proactively on tasks in the background, continuing to work even when you’re not actively using it.

This one I am still processing. An agent that doesn’t wait for you to ask. It monitors, plans, and acts — all while you go about your day.

For a family app, the implications are significant. Most family planning apps are reactive — you open the app, you add something, you check a list. Gemini Spark represents a shift to proactive. The agent notices that your grocery budget is running low mid-week, checks the family calendar and sees there’s a dinner party on Saturday, and quietly starts building a shopping list without you having to ask.

What this means for my app:

The Weekend Planner feature I’ve been designing fits perfectly here. Right now I was planning it as a manual feature — family members add activities, the app shows a view. But after watching Spark, I’m rethinking it as a proactive agent:

• Monday: Spark notices the weekend is approaching and checks the family calendar
• Tuesday: Spark suggests 3 weekend activity options based on past preferences and local weather
• Wednesday: Family approves a plan — Spark generates the shopping list and budget estimate
• Friday: Spark sends a reminder with the full weekend plan and what’s still needed

That’s not a feature. That’s a family assistant. And Google just showed us it’s possible.

4. Universal Cart — The Feature I Am Most Excited to Integrate

Universal Cart uses AI to proactively check your cart and understands context — like knowing which parts you’re buying for a PC build — across multiple retailers.

This was the announcement I immediately started sketching integration ideas for.

Families don’t shop at one store. We go to Costco for bulk, Metro for fresh produce, Shoppers for pharmacy items. Every week we’re mentally tracking prices across multiple places. Universal Cart is Google saying: you shouldn’t have to do that.

What this means for my app — in detail:

Here is exactly how I see Universal Cart fitting into the family app I am building:

Smart grocery sourcing:
A family member adds “Greek yogurt” to the shared grocery list. Universal Cart checks across nearby stores, finds the best price per unit, and flags it. The app shows: “Metro has this $1.20 cheaper this week.”

Budget-aware shopping:
The family sets a $200 weekly grocery budget. As items get added to the list, the app estimates the Universal Cart total in real time. When you hit $180, the app flags it: “You’re close to your budget — here are 3 items with cheaper alternatives.”

Weekend planner tie-in:
Planning a family BBQ this weekend? The weekend planner generates a suggested menu. Universal Cart sources every ingredient across nearby stores, finds the best combination of stores to hit, and estimates the total cost before anyone leaves the house.

Receipt reconciliation with ReceiptMind:
After shopping, you photograph the receipt in ReceiptMind. The app compares what Universal Cart estimated vs what you actually spent. Over time, this builds a real picture of where estimates were off and which stores are consistently cheaper for your family’s actual buying habits.

This integration is my north star for the next phase of this app.

5. Intelligent Eyewear — I Already Live in This World (Sort Of)

Google’s collaboration with Samsung brought working demos of intelligent eyewear designed by Warby Parker and Gentle Monster, with deep Gemini integration to perform tasks through voice commands.

Here’s my personal take on this one: I own a pair of Meta Ray-Bans.

I love them. I use them for calls. I take photos with them. But that is essentially it. The AI assistant on them feels like a novelty — it can answer general questions but it doesn’t know anything about me, my context, or what I’m actually trying to do.

What Google showed at I/O is a fundamentally different vision. Gemini embedded in glasses that actually understand your context — what you’re looking at, where you are, what you’re trying to accomplish — and assists without you having to pull out your phone.

What this means for families:

I walked into a grocery store last Saturday with a list on my phone. I kept having to unlock it, find the list, check off items, put it back. It’s friction. Small friction, but friction.

Intelligent eyewear with Gemini could eliminate that entirely. Walk into Metro, say “what do we still need?” — the glasses check the family list, see what’s already in the cart via camera, and tell you what’s missing. No phone. No unlocking. No friction.

For my family app, this is a future integration worth designing toward today — even if the hardware isn’t available yet. Building the API layer to support a glasses interface means we’re ready when the hardware ships this fall.

The Bigger Picture — What Google I/O Meant to Me Personally

I came into this as an SDET who made a decision a few months ago to stop watching AI from the sidelines and start building.

Google I/O showed me how fast the gap between “idea” and “working software” is closing. Antigravity is compressing development time. Search is raising the bar for what users expect from interfaces. Spark is redefining what “proactive” means in software. Universal Cart is eliminating friction that users didn’t even know they were tolerating.

As a quality engineer, my job has always been to ask: does this actually work for the person using it? That question doesn’t change with AI. If anything, it gets more important — because when AI agents are doing the building and the reasoning and the planning, the human who validates the output becomes more valuable, not less.

That’s the role I’m stepping into. And Google I/O 2026 gave me a much clearer picture of what I’m stepping into it for.

What I’m Building Next

Immediately after I/O, I added three things to my roadmap for the family app:

• Weekend Planner v2 — redesign as a proactive agent, not a manual feature
• Universal Cart integration — research the API, start designing the budget overlay
• Voice-first grocery list — design the UX today so it’s glasses-ready when the hardware ships

The deadline for this writing challenge is May 24. My app has no deadline. But Google I/O just gave it a much clearer direction.

Hemalatha — SDET and app builder patiently waiting for the Gemini upgrade

Building a family super-app with Google AI Studio + Gemini 3 Flash Preview

I still remember the night before my first day — tabs open, notes ready, convinced I was going to ship features on day one. Spoiler: I didn’t. But what I did get was something better — a crash course in what real software development actually looks like. Here’s the honest truth about my first month.

Reading Code Is a Skill Nobody Talks About

Every tutorial I ever followed started with a blank file. Real work doesn’t. On my first task, I was dropped into a codebase with hundreds of files, and I had no idea where to even begin. I kept waiting for it to “click” like tutorials did.
What actually helped was slowing down — not trying to understand everything at once, but tracing one feature from the UI all the way to the database. Like following a thread. Once I did that a few times, the codebase started feeling less like a maze and more like a map.
Takeaway: before you write a single line, spend time just reading. Good developers read code like others read books.

Googling Is Not Cheating — It’s the Job

I used to feel embarrassed opening Stack Overflow in front of my teammates. I thought it meant I didn’t know enough. Then I watched my senior dev — someone with years of experience — Google a CSS property without blinking.
Nobody memorizes everything. The real skill is knowing what to search, how to read documentation quickly, and how to tell a good answer from a bad one. That takes practice, not shame.
Takeaway: your browser history full of “how to do X in React” doesn’t make you a bad developer. It makes you a working one.

Git Will Save You — Once You Stop Fearing It

My first week I was committing everything to main and praying nothing broke. Then I accidentally overwrote two hours of work and nearly had a panic attack.
After that I finally sat down and learned branching properly. Feature branches, descriptive commit messages, pulling before pushing — it sounds boring until the day it saves your entire afternoon. Git isn’t just version control, it’s your safety net.
Takeaway: learn git branch, git stash, and git log early. Future you will be grateful.

Asking for Help Is Part of the Job Description

I spent an entire afternoon stuck on a bug, too nervous to ask anyone. When I finally did, my teammate spotted the issue in under two minutes. Two minutes vs four hours — that’s the cost of silence.
Good teams want you to ask questions. It’s not a sign of weakness, it’s a sign that you respect everyone’s time including your own. The rule I now follow: if I’m stuck for more than 30 minutes, I ask.
Takeaway: being stuck quietly is not the same as being productive. Speak up.

1. The Gap Between Tutorials and Real Projects Is Huge — And That’s Okay
   Tutorial projects are clean, scoped, and predictable. Real projects have legacy code, unclear requirements, half-finished features, and decisions made two years ago by someone who no longer works there.
   That gap feels brutal at first. But crossing it is exactly what turns you from someone who knows how to code into someone who can actually build things. Every confusing day is closing that gap a little more.
   Takeaway: feeling lost in a real codebase doesn’t mean you’re behind. It means you’re actually learning.

At the end,

Internships aren’t about being perfect — they’re about learning faster than you ever have before. If you’re just starting out, embrace the confusion. It means you’re in the right place.
What’s the first real thing you learned on the job? Drop it in the comments — I’d love to know.

The Sovereign Model Is Not Enough

The European AI debate keeps getting pulled toward the model race. Who has the frontier model? Who has the compute? Who is behind the US labs?

That race matters, but it is not the whole AI economy. Most companies do not experience AI as a leaderboard. They experience it as a workflow: invoices arrive, contracts need review, documents become structured fields, images need processing, reports get generated, and uncertain outputs need a human decision before anything reaches a customer.

That is where European AI can matter most. Not by copying the model-layer strategy of better-funded players, but by making business-critical AI workflows easier to build, run, audit, and trust under European constraints.

The first answer to sovereignty is usually model-centric. Pick a European model provider. Choose an EU region. Avoid sending prompts to a US endpoint. Those choices matter, but they do not solve the harder problem: most business workflows are not one model call. They need OCR, extraction, document conversion, image processing, generated PDFs, spreadsheets, review steps, retries, logs, and delivery. For many of those steps, there are still few sovereign providers that are both production-grade and easy to compose. And even when good providers exist, the team still has to stitch them into one workflow with consistent auth, pricing, retention, error handling, and audit behavior.

For agencies and technical consultancies, that gap is not theoretical. It shows up during client delivery. The demo extracts fields from contracts, generates a report, and creates a spreadsheet. Then the approval process starts: procurement asks for sub-processors, legal asks where personal data was processed, and security asks whether failed webhook payloads contain document text. The model answer is suddenly too narrow.

If sovereignty only lives at the model layer, the architecture will fail the first serious workflow review.

The Workflow Is Where Business Risk Lives

Most useful AI work is not a model call. It is a chain of steps around a business process.

A German fleet operator receives traffic-fine notices from municipalities across Europe. The workflow has to ingest PDFs, extract plate numbers and dates, route uncertain fields for review, generate a summary for the operations team, and export a clean register. A logistics company receives CMR waybills, delivery notes, and customs documents from carriers. The workflow has to extract shipment data, normalize dates and addresses, generate exception reports, and update the transport desk. A finance team receives supplier invoices from several EU countries. The workflow has to extract supplier details, VAT context, totals, and IBANs, check confidence, generate an approval packet, and export clean rows.

The model may help with interpretation. The workflow owns the promises:

• Which file entered the system.
• Which processor saw it.
• Which fields were extracted.
• Which values were uncertain.
• Which human approved a correction.
• Which generated output was sent to the client.
• Which logs explain the run without storing the document.

That is the layer where trust is won or lost. A model can be European and still sit inside an uncontrolled workflow. A workflow can be auditable and sovereign only if every content-processing handoff is designed that way.

This is also where GDPR document-processing requirements and the EU AI Act become engineering concerns instead of legal footnotes. GDPR asks where personal data goes, how much is processed, and how long it is retained. The AI Act asks what the AI system does, what risk category it falls into, and where human oversight belongs. Those questions cannot be answered by a model endpoint. They have to be answered by the workflow.

Why Agencies Feel This First

Agencies are the early warning system for this problem because they repeat workflows across clients.

A SaaS team may build one document pipeline and operate it for years. An agency builds variants of the same pattern again and again: intake, extraction, review, generation, delivery, reporting. Each project has different document types, templates, approval rules, and client expectations, but the underlying processing shape repeats.

That repetition creates pressure in both directions.

On the delivery side, custom vendor stacks eat margin. One client uses AWS Textract, another uses a PDF parsing library, a third needs an image processing service, and a fourth wants generated reports. Every new vendor adds credentials, billing units, retry behavior, and failure modes. Fixed-fee projects get harder to quote because the hidden work is not the API call. It is the glue code and the review explanation around it.

On the trust side, sovereignty-conscious clients do not only ask whether a model is hosted in Europe. They ask whether the agency can explain the full path. If the answer changes per project, the agency cannot reuse its compliance story. Every client review becomes a fresh reconstruction of vendor boundaries, retention policies, and generated artifacts.

The agency needs a repeatable workflow architecture, not a new tool collage for every engagement.

For many client projects, that repeatable architecture starts in n8n. The visual workflow should describe the business process: intake, extraction, review, generation, delivery, and reporting. The processing nodes should not become a pile of unrelated HTTP calls, credentials, and format mappers. The verified Iteration Layer n8n node exists for that reason: agencies can wire document and image workflows visually while keeping the processing surface consistent.

The Runtime View

A workflow runtime is the controlled layer where content-processing steps become one repeatable system.

It does not mean a visual builder has to own the whole business process. It does not mean every client workflow should move into a heavyweight enterprise platform. For many agency projects, the useful runtime is simpler: one processing surface for the parts that touch documents, images, spreadsheets, websites, and generated files.

The runtime view asks different questions than a model evaluation:

This is why the workflow layer is more defensible than the model layer for many business processes. Models improve and change. The client still needs the same contract: files enter through a known path, content is processed under known boundaries, uncertainty is visible, and outputs are created from data the workflow is allowed to use.

What Sovereign Workflows Need in Practice

For EU agencies, a credible sovereign workflow has a few concrete properties.

EU-hosted processing has to apply to the content-processing chain, not only one AI call. If extraction runs in Europe but generated PDFs are created by a US service, the workflow still has a cross-border output step. If the automation platform stores full execution payloads outside the EU, the workflow still has a data-flow problem.

Composability matters because every extra vendor is another processor review, credential set, billing model, and error surface. Extracting fields from a contract and generating a PDF summary should not require two unrelated integrations and a custom mapper between them. The fewer seams in the processing chain, the easier the workflow is to explain.

Structured uncertainty matters because AI output is not equally trustworthy across fields. A low-confidence IBAN, an ambiguous termination date, and a high-confidence invoice number should not follow the same path. Confidence scores, citations, and review rules turn vague “human in the loop” language into an actual operating model.

Predictable pricing matters because agencies quote projects before the final document mix is known. A workflow that extracts documents, transforms images, and generates reports should not require separate cost models for every operation. A shared credit pool is not just a billing feature; it is a way to quote client work without modeling several vendor invoices.

Agent-native access matters during discovery. MCP lets an agency explore documents, try schemas, generate draft outputs, and find edge cases quickly. But recurring delivery should still have a controlled handoff into REST, SDKs, n8n, or backend code that owns credentials, retries, review, and audit state.

None of this removes the need for legal review, contracts, access controls, or client-specific retention decisions. It gives the technical architecture a cleaner starting point.

The European Workflow Runtime We Are Building

This is the company we are building: Iteration Layer as the European AI workflow runtime for business-critical content processing.

The first surface is practical. The APIs share one auth model, one credit pool, one API style, and one EU-hosted processing layer. An agency can extract structured fields from a document, convert a document to Markdown for review, transform images, generate client-ready PDFs or spreadsheets, and expose those operations through MCP during exploration or REST, SDKs, and n8n during production delivery.

That does not make every client workflow compliant by itself. The agency still owns client contracts, lawful-basis analysis, access control, storage, delivery, and review policy. But the processing layer becomes easier to reason about: fewer vendors, fewer retention policies, fewer billing systems, and fewer places where client data can unexpectedly persist.

This is the practical meaning of a European AI workflow runtime. Not a claim that one product replaces every part of the stack. Not a promise that sovereignty can be bought as a badge. A narrower, more useful idea: the content-processing steps inside AI workflows should be composable, EU-hosted, predictable, and audit-ready by default.

For agencies serving European clients, that changes the sales conversation. Instead of saying “we can connect a model to your documents,” you can say: the workflow has a known data path, a known review policy, a known processing surface, and generated outputs that come from approved data.

That is the difference between a demo and infrastructure.

Build the Workflow Map First

Before choosing the next model or tool, draw one client workflow end to end.

Start with the file entering the system. Follow it through extraction, review, generation, delivery, logs, retries, and reporting. Mark every processor, every retained artifact, every human handoff, and every generated output. Then ask where the workflow is harder to explain than it needs to be.

If the answer is too many vendors, too many payload copies, too much glue code, or too little visibility into uncertainty, the problem is not only the model. It is the runtime around the model.

Read the EU-hosted AI workflow data-flow guide for the detailed checklist, or start with Iteration Layer’s document and image workflow APIs if you want the processing surface to be smaller before the next client review.

Current AI coding systems are becoming extremely capable at:

• repository understanding
• prompt execution
• architecture reasoning
• code generation

But there is still a major missing layer:

Business Understanding

Most AI coding agents can understand:

• APIs
• frameworks
• file relationships
• implementation patterns

But they often fail to understand:

• why the product exists
• business constraints
• operational priorities
• monetization logic
• user workflow intent
• organizational semantics

This creates a gap between:

• implementation correctness
  and
• business alignment.

The Problem With Current AI Coding Workflows

Most systems operate like this:

User Prompt
↓
Repository Scan
↓
Code Understanding
↓
Planning
↓
Implementation

This approach works technically.

But it forces the AI to repeatedly:

• scan repositories,
• infer architecture,
• reconstruct context,
• guess business reasoning.

This increases:

• token usage,
• architectural drift,
• hallucinated implementation,
• inconsistent feature behavior.

The Missing Layer: Business Blueprint Context

I started exploring the idea of introducing a structured semantic context layer before implementation orchestration begins.

Instead of relying only on repository understanding, AI agents first read:

• business intent
• product priorities
• architecture philosophy
• monetization logic
• domain language
• operational constraints

before implementation planning starts.

I call this:

Business Blueprint Layer

Proposed Workflow

Jira Ticket / User Request
↓
Business Blueprint Understanding
↓
Domain Semantic Interpretation
↓
Technical Understanding
↓
Planning Agent
↓
Execution Agents
↓
Validation Agents
↓
Implementation

Example Repository Structure

/ai-context
    business-model.yml
    domain-language.yml
    architecture-intent.yml
    monetization-rules.yml
    feature-priorities.yml

Why This Could Matter

Code understanding alone is not enough for reliable AI-native software engineering.

Human engineering teams also rely on:

• PRDs
• business rules
• organizational memory
• operational context
• strategic priorities

AI systems may eventually require similar semantic operating context.

Potential advantages:

• reduced token usage
• better multi-agent coordination
• stronger implementation consistency
• business-aware planning
• improved long-term repository cognition

Future Direction

This could evolve into:

• semantic repository memory,
• organizational AI memory,
• business-aware orchestration systems,
• AI-native SDLC frameworks.

Final Thought

The future of AI software engineering may not depend only on larger context windows.

It may depend on whether AI systems can understand:

• why software exists,
• what business objectives it serves,
• and how implementation aligns with organizational intent.

GitHub Repository

https://github.com/uttesh/business-blueprint-aware-ai-agent-framework

Author

Uttesh Kumar T.H.

Nine AI features. One production SaaS. Zero hallucinated data in the user’s face.

That last part is harder than it sounds.

This is a full technical breakdown of how I designed, built, and shipped nine Claude Haiku features into CitizenApp — a GDPR-compliant citizen management platform. I’ll cover the architecture, the security decisions, the failure modes I had to defend against, and what I’d do differently.

Why Haiku, Not Sonnet or Opus

Every AI feature in CitizenApp uses claude-haiku-4-5. The reasoning was deliberate:

Cost. This is a multi-tenant SaaS. Each AI call deducts from the tenant’s credit balance. Haiku is significantly cheaper per token than Sonnet — which means I can offer meaningful AI functionality at the Free tier without destroying margins.

Speed. Most features are interactive — the user is waiting. Haiku’s latency is typically under 2 seconds for the prompt sizes I’m sending. Sonnet would double or triple that.

Sufficient capability. For structured tasks — SQL generation, data summarisation, duplicate record comparison — Haiku is good enough. I don’t need Opus-level reasoning. I need fast, cheap, reliable JSON out.

Consistent timeout budget. Every AI call has a 20-second timeout. Haiku almost always completes in under 5. That matters when you’re running on Render’s free tier.

The Credit System

Before the features themselves: every AI call in CitizenApp costs credits. This is enforced at the API layer, not the frontend.

async def deduct_credits(db: AsyncSession, tenant_id: int, amount: int = 1) -> None:
    tenant = await db.get(TenantModel, tenant_id)
    if tenant.ai_credits < amount:
        raise HTTPException(status_code=402, detail="Insufficient AI credits")
    tenant.ai_credits -= amount
    await db.commit()

Simple. No credits, no AI call. The 402 Payment Required response tells the frontend to show the upgrade prompt. Credits are deducted before the Claude API call — if the call fails, I refund them. This prevents users from draining credits on broken requests.

Stats queries cost 1 credit. Live DB queries cost 2. The pricing reflects actual Claude token consumption.

Feature 1: CSV Column Mapping

The problem: Users import citizen data from spreadsheets. The column headers are inconsistent — TC No, tc_no, Kimlik No, ID Number — all mean the same thing. Asking users to manually map every import is a UX failure.

The implementation:

async def ai_map_columns(headers: list[str]) -> dict:
    prompt = f"""You are mapping CSV column headers to a fixed schema.

Schema fields: tc_no, ad_soyad, dogum_tarihi, cinsiyet
Headers: {headers}

Return JSON only:
{{"tc_no": "header or null", "ad_soyad": "header or null", 
  "dogum_tarihi": "header or null", "cinsiyet": "header or null"}}"""

    response = await anthropic_client.messages.create(
        model="claude-haiku-4-5",
        max_tokens=200,
        messages=[{"role": "user", "content": prompt}]
    )
    return json.loads(response.content[0].text)

What I learned: Keep the schema description short and the output format rigid. Early versions asked Claude to “suggest the best mapping” — vague enough that it would sometimes return explanatory text instead of JSON. Specifying Return JSON only: with the exact structure eliminated this.

Failure mode handled: If json.loads throws, fall back to fuzzy string matching. AI is the first attempt, not the only one.

Feature 2: Natural Language Search

The problem: Users need to filter 50,000+ citizen records. SQL is not the interface.

The implementation:

ALLOWED_COLUMNS = {"ad_soyad", "dogum_tarihi", "cinsiyet", "created_at", "il", "ilce"}

async def nl_to_sql_filter(query: str, tenant_id: int) -> str:
    prompt = f"""Convert this natural language query to a PostgreSQL WHERE clause.

Table: vatandas
Available columns: {', '.join(ALLOWABLE_COLUMNS)}
tenant_id is always {tenant_id} — always include it.

Query: "{query}"

Return only the WHERE clause starting with 'WHERE'. No explanation."""

    response = await anthropic_client.messages.create(
        model="claude-haiku-4-5",
        max_tokens=300,
        messages=[{"role": "user", "content": prompt}]
    )

    clause = response.content[0].text.strip()
    validate_sql_clause(clause)  # raises on dangerous patterns
    return clause

The critical part — validate_sql_clause:

BLOCKED = ["drop", "delete", "update", "insert", "alter", "exec", 
           "--", ";", "union", "sleep", "pg_"]

def validate_sql_clause(clause: str) -> None:
    lower = clause.lower()
    if not lower.startswith("where"):
        raise ValueError("Invalid clause")
    for pattern in BLOCKED:
        if pattern in lower:
            raise ValueError(f"Blocked pattern: {pattern}")

Never trust LLM output with SQL. The allowed columns list is in the prompt — if Claude generates a column not in that list, SQLAlchemy will raise a column-not-found error before anything executes. Defense in depth.

Feature 3: Anomaly Detection

The problem: Bad data accumulates. Future birthdates, 1890-born citizens, missing gender on 40% of records. Users need to find it without writing reports.

The implementation: I run five deterministic checks in Python — no AI involved in detecting the anomalies:

def detect_anomalies(citizens: list[dict]) -> list[dict]:
    issues = []
    today = date.today()

    for c in citizens:
        if c["dogum_tarihi"] and c["dogum_tarihi"] > today:
            issues.append({"id": c["id"], "type": "future_dob", "severity": "high"})
        if c["dogum_tarihi"] and c["dogum_tarihi"].year < 1900:
            issues.append({"id": c["id"], "type": "implausible_dob", "severity": "medium"})
        if not c["cinsiyet"]:
            issues.append({"id": c["id"], "type": "missing_gender", "severity": "low"})

    return issues

Claude’s role is to summarise the results:

summary_prompt = f"""Summarise these data quality issues in 2-3 sentences for a non-technical admin:
{json.dumps(issue_counts)}
Be specific about numbers. Suggest the highest-priority fix first."""

This is the right division of labour. Python finds the issues deterministically. Claude explains them in plain language. AI never makes the binary “is this an anomaly” judgment — it just communicates results.

Feature 4: AI Daily Briefing

The simplest feature architecturally. Every morning, the admin dashboard can show a 3-4 sentence Claude-generated briefing:

stats = {
    "total_records": 12847,
    "missing_gender": 342,
    "missing_dob": 89,
    "potential_duplicates": 23,
    "created_last_7_days": 156
}

prompt = f"""You are a data assistant. Write a 3-4 sentence briefing for an admin 
about the current state of their citizen database. Be concise and actionable.

Stats: {json.dumps(stats)}"""

Lesson: Don’t send raw PII to the API. Stats are safe. Individual citizen records are not. I aggregate before sending.

Feature 5: AI Duplicate Merge

This was the most complex feature to get right.

The problem: The duplicate detection identifies potential duplicates by similarity score. But merging them requires judgment — which record has the correct spelling? Which birthdate is more likely accurate?

The implementation:

async def ai_merge_suggest(record_a: dict, record_b: dict) -> dict:
    # Mask TC no before sending to Claude
    safe_a = {k: v for k, v in record_a.items() if k != "tc_no"}
    safe_b = {k: v for k, v in record_b.items() if k != "tc_no"}

    prompt = f"""Compare these two citizen records and suggest the best merged version.

Record A (id={record_a['id']}): {json.dumps(safe_a)}
Record B (id={record_b['id']}): {json.dumps(safe_b)}

Return JSON:
{{
  "keep_id": <id of the record to keep as primary>,
  "merged": {{"ad_soyad": "...", "dogum_tarihi": "YYYY-MM-DD", "cinsiyet": "E/K"}},
  "confidence": "high|medium|low",
  "reasoning": "one sentence explanation"
}}"""

TC identity number (TC kimlik no) is always masked before sending to Claude. This is non-negotiable. It’s PII, it’s regulated, and it’s not needed for the merge decision. The keep_id in the response tells the backend which record to promote — Claude never sees or decides on the TC number.

Claude’s output is never applied automatically. It’s a suggestion displayed to the admin, who clicks “Apply” to confirm. The AI is an advisor, not an actor.

Feature 6: Natural Language Reports

The problem: Admins need custom data exports. “Give me all female citizens born between 1960 and 1970 in Ankara” is not a filter the UI can anticipate.

The implementation: A dedicated /reports page accepts a natural language query, sends it to Claude for SQL filter generation (same pattern as Feature 2), shows a preview table, then allows CSV/TSV export — all client-side using Blob and URL.createObjectURL.

The backend generates the filtered dataset. The download happens in the browser. No server-side file generation, no temp file cleanup, no storage costs.

Features 7 & 8: AI Chat — Stats and Live DB Query

The floating chat widget was the most technically interesting feature.

Two modes in one endpoint:

1. Stats mode — Claude answers questions from aggregate statistics only. “How many records are missing a birthdate?” The answer comes from pre-computed stats, not a live query.

2. DB query mode — For questions that can’t be answered from stats, Claude generates a SQL SELECT statement that the backend executes directly.

The DB query mode required careful safety engineering:

SAFE_QUERY_RULES = """
Generate a PostgreSQL SELECT query. Hard rules:
- Only query table: vatandas
- Never include column: tc_no  
- Always filter: WHERE tenant_id = {tenant_id}
- Always add: LIMIT 100
- No subqueries, no JOINs to other tables
- No aggregations that could expose cross-tenant data
"""

def validate_generated_query(sql: str, tenant_id: int) -> str:
    sql_lower = sql.lower().strip()

    assert sql_lower.startswith("select"), "Must be SELECT"
    assert "tc_no" not in sql_lower, "tc_no is blocked"
    assert f"tenant_id = {tenant_id}" in sql_lower, "tenant_id filter required"
    assert "limit" in sql_lower, "LIMIT required"

    # Extract and enforce limit
    limit_match = re.search(r"limits+(d+)", sql_lower)
    if limit_match and int(limit_match.group(1)) > 100:
        sql = re.sub(r"limits+d+", "LIMIT 100", sql, flags=re.IGNORECASE)

    return sql

The query executes with a 5-second statement timeout at the database level. If Claude generates something slow, it gets cancelled.

Query result display: Results are shown in a collapsible QueryBlock with the SQL visible above the data table. Users can see exactly what ran. Transparency matters when AI is touching your database.

Feature 9: AI Audit Trail Explainer

The audit log records 30+ event types — citizen_created, bulk_import, login_failed, 2fa_enabled, etc. Non-technical admins can’t interpret raw event streams.

async def explain_audit_events(events: list[dict]) -> str:
    # Strip internal IDs and technical fields
    safe_events = [
        {"type": e["event_type"], "user": e["user_email"], "time": e["created_at"]}
        for e in events[:20]  # Last 20 events only
    ]

    prompt = f"""Summarise this audit log in plain language for a non-technical admin.
Note any unusual patterns (multiple failed logins, bulk operations, permission changes).
2-4 sentences maximum.

Events: {json.dumps(safe_events)}"""

Cap at 20 events. Don’t send the full log. Keep the token budget predictable.

What I’d Do Differently

1. Add structured output from the start.

Anthropic’s tool use / structured output API is cleaner than prompt engineering Return JSON only. I retrofitted it on some features. It should have been the default.

2. Cache more aggressively.

The daily briefing doesn’t need to be generated every page load. A 6-hour Redis cache with background refresh would cut AI costs significantly. Currently it regenerates on every dashboard open.

3. Separate AI service layer.

All nine features call Claude via a thin wrapper in app/services/ai.py. This is good for centralised error handling and logging. What I should have added sooner: a proper prompt registry so prompts are versioned and testable independently of the endpoint logic.

4. Test AI outputs, not just AI calls.

My test suite mocks the Anthropic client. That’s necessary but insufficient — it doesn’t catch prompt regressions. A small set of golden-output integration tests against real Claude (run weekly, not on every CI run) would give me confidence that prompt changes don’t silently break feature behaviour.

The Result

Nine features, all in production, all credit-metered, all with safety validation on AI outputs. The platform handles real data for real users.

The engineering pattern that made this possible: AI generates, Python validates, humans confirm. The LLM is never the last line of defence.

Building AI features into your product? Let’s talk about what that looks like.

HashiCorp built an MCP server for writing Terraform. I built one for reviewing it.

A few weeks ago HashiCorp shipped terraform-mcp-server. It’s an official MCP server that lets a model lean on the Terraform Registry: search providers, pull module docs, manage HCP Terraform workspaces. The shape is “help the model author IaC.” That’s a genuinely useful tool and a clear signal that Terraform-via-MCP is now a category, not a curiosity.

But it doesn’t help with the part of Terraform I spend the most time stressed about: reviewing somebody else’s plan.

terraform plan outputs are long. Real production plans run into the thousands of lines. The risky changes (an IAM grant going *, a security group opening to 0.0.0.0/0, an RDS instance being replaced) hide between a hundred routine attribute updates. Code review tools don’t help because the danger isn’t in the HCL diff, it’s in the planned actions.

So I built tf-review-mcp. It’s an MCP server scoped to one job: parse terraform show -json output and surface what a human reviewer actually cares about, structured for an LLM to quote and reason about.

What it does

Two tools:

• review_plan(plan_json_path) returns a structured summary: action counts, high-blast-radius resource changes, stateful destroys, and diff-aware public-exposure findings.
• suggest_review_comments(plan_json_path) returns a list of {address, severity, comment} objects ready to drop into a PR review.

The server flags three things:

High-risk resource types (warn). A conservative built-in list across AWS, GCP, and Azure: IAM, KMS, RDS, security groups, S3, EKS, GKE, Cloud SQL, GCS, Cloud DNS, GCE firewalls, Key Vault. Easy to extend in source.

Stateful destroys (blocker). When a stateful resource like aws_db_instance, google_sql_database_instance, or google_compute_instance is scheduled for delete or replace. The GCE case matters more than people realize: a replace on a Compute Engine VM with local SSDs nukes both the boot disk and any local-SSD attachments. Silent data loss if a reviewer misses it.

Public exposure changes (blocker). Diff-aware. The server compares before and after on every google_compute_firewall change and fires when source_ranges newly contains 0.0.0.0/0 or ::/0. That single check has caught more dumb mistakes for me than any static analyzer.

What it looks like

Given a plan that deletes a Cloud SQL instance, replaces a GCE VM, and widens a firewall to the public internet, the server returns:

{
  "counts": {"create": 1, "update": 3, "replace": 1, "delete": 1},
  "stateful_destroys": [
    {"address": "google_compute_instance.op_geth", ...},
    {"address": "google_sql_database_instance.indexer", ...}
  ],
  "public_exposure_changes": [
    {"address": "google_compute_firewall.rpc_public",
     "finding": "source_ranges now includes 0.0.0.0/0 (public exposure)"}
  ],
  "notes": [
    "2 stateful resource(s) scheduled for destroy/replace. Verify backups and migration plan before applying.",
    "1 firewall change(s) widen public exposure. Confirm intent before applying."
  ]
}

Asked to summarize, Claude reads this and produces:

Blocker-severity items (3)

• google_compute_instance.op_geth: Delete/recreate of a stateful compute instance. Confirm backup, migration, and rollback plan before merging.
• google_sql_database_instance.indexer: Cloud SQL instance is being deleted. Confirm backup, migration, and rollback plan before merging.
• google_compute_firewall.rpc_public: source_ranges now includes 0.0.0.0/0 (public exposure). Confirm this is intentional and matches firewall policy.

That’s a PR review comment I’d actually merge.

Why MCP, not a CLI

The same parser could be a CLI. The reason MCP matters is the conversational shape. When I’m reviewing a plan, I want to ask follow-up questions: “is the SQL delete a replace or a hard destroy?”, “what changed about that firewall?”, “draft me a PR comment for the IAM grant.” The model can pull the right tool, narrow on the right resource, and write something useful, because the underlying tool returns data, not prose. Lower hallucination surface. Higher signal per token.

Most community Terraform-MCP experiments wrap the CLI (“run terraform plan for me”). That’s the wrong abstraction for review. You don’t want the model running plan; you want it reasoning about a plan that already ran.

Architecture and deployment

The parser is in review.py as pure functions with no MCP imports: plan JSON in, ReviewSummary out. The MCP wrapper is in server.py, about a hundred lines. The split means the parser can be unit-tested, dropped into CI, or audited without touching the transport.

Deployment is local stdio. Always. The MCP client launches the server as a child process. Plan JSON never leaves your laptop. No auth, no shared state, no network listener.

Plan JSON contains IAM relationships, account IDs, security group rules, and resource counts. Hosted “send us your plan” services are a recon goldmine waiting to happen. The architecture should make leakage impossible by default. A self-hosted HTTP variant for CI is a v2 idea, with auth and a path allowlist, not before.

Why this is differentiated

HashiCorp’s official server covers Registry lookup and HCP workspace management. Helpful for writing.

This one covers plan review. Helpful for reviewing.

Both ship as MCP servers. Both can be installed in the same client. The model picks the right tool per task. They’re complementary by design, not competitive.

I haven’t found another MCP server scoped specifically to plan review with LLM-friendly structured output, as of writing. If one exists, I want to know.

What’s next

• estimate_cost_delta wrapping Infracost.
• check_policy wrapping Conftest, so teams can bring their own Rego.
• Configurable HIGH_RISK_TYPES via a YAML file so each team can codify its own blast-radius rules.
• More diff-aware checks: aws_security_group ingress widening, IAM * grants, google_storage_bucket force_destroy toggles.

The repo lives here: github.com/sanjeevkkansal/tf-review-mcp. It’s MIT-licensed, v0.2, and very much open to PRs, especially if you have a war story about a plan that should have been caught.

Sanjeev Kumar is an infrastructure engineer working on platform tooling, AI-assisted ops, and infra that doesn’t wake people up at 3am.

In 2026, the gap between AI agent demos and AI agent deployments is the most expensive gap in enterprise technology. We’ve watched organizations spin up promising pilots, hit a wall somewhere between 10 and 50 concurrent tasks, and quietly shelve the project. According to McKinsey’s The State of AI in the Enterprise 2024, organizations are moving beyond pilots into production deployments, but successful implementations require clear governance frameworks and integration with existing business processes. Most teams skip both. That’s where things break.

This isn’t a theoretical problem. We built our first Autonomous SDR on a flat 3-agent architecture: research, scoring, and writing all reporting to a single orchestrator. It worked on 5 leads. At 50, the scorer sat idle waiting on research that had nothing to do with scoring. Splitting into discrete agents with explicit handoff contracts between them cut end-to-end processing time and made each component independently testable. We learned the hard way that implicit data passing doesn’t hold up when volume increases. Every pipeline we’ve built since uses explicit inter-agent schemas for exactly that reason.

Here are the five failure modes we see most often, and what separates the deployments that survive from the ones that don’t.

Failure Mode 1: Flat Architectures That Can’t Distribute Work

The first mistake is treating an agent system like a single smart function. Teams wire a reasoning model to a set of tools, give it a task, and call it an agent. This works in demos. It breaks when tasks have independent sub-components that don’t need to wait on each other.

The fix isn’t complexity for its own sake. It’s identifying which parts of a workflow are genuinely sequential and which can run in parallel. In our SDR build, research and lead enrichment could run concurrently. Scoring depended on research output. Writing depended on scoring. Once we mapped those dependencies explicitly, the architecture became obvious. The orchestrator’s job shrank to routing and handoff validation, not doing everything itself.

If you’re building multi-step pipelines in n8n or a similar orchestration tool, this dependency mapping should happen before you write a single node. Draw the data flow first.

Failure Mode 2: No Governance Model Before Deployment

Governance sounds like a compliance checkbox. In practice, it’s the set of rules that determines what an agent is allowed to do, what it must escalate, and who owns the output. Without it, agents make decisions that no one authorized and that no one can audit after the fact.

McKinsey’s 2024 research is direct on this point: governance frameworks and integration with existing business processes are what separate successful production deployments from failed ones. The organizations getting this right aren’t building governance after deployment. They’re defining it as part of the system design, before a single API call goes live.

Concretely, this means: defining which actions require human approval, logging every decision with enough context to reconstruct why it was made, and setting hard limits on what the system can modify without confirmation. These aren’t optional features. They’re the difference between a system your legal and security teams will approve and one they’ll shut down.

Failure Mode 3: Routing Every Task Through a Reasoning Model

This one is expensive and slow. A reasoning model is the right tool for ambiguous, multi-step decisions. It is the wrong tool for classification, formatting, or any task with a deterministic answer given structured input.

We’ve seen pipelines where every step, including simple data transformations, routes through a large LLM. The latency compounds. The cost compounds. And the output quality doesn’t improve because the task didn’t need that level of reasoning to begin with. A classification model or a rules-based node handles most of those steps faster and more consistently.

The honest tradeoff here: tiered routing adds architectural complexity. You need to define clear criteria for which tasks go where, and you need to test those criteria against real inputs. That’s real engineering work. For smaller deployments with low task volume, a single reasoning layer may be simpler to maintain even if it’s less efficient. The optimization is worth it when volume justifies the overhead.

Failure Mode 4: Security as an Afterthought

Agents that can read, write, and send on behalf of users are a different security surface than traditional software. They act. That means the attack surface includes not just the system itself but every downstream action the system can take.

Prompt injection is the most immediate concern: an adversarial input that redirects the agent’s behavior. Data exfiltration through tool calls is the second. Most enterprise security reviews weren’t designed with agentic systems in mind, which means teams are often deploying systems that haven’t been evaluated against the right threat model.

We cover the specific patterns we use for access scoping and input validation in our analysis of enterprise tool security. The short version: agents should operate with the minimum permissions required for their specific task, and every external input should be treated as untrusted until validated.

Failure Mode 5: No Observability Until Something Breaks

An agent system without observability is a black box. You know what went in and what came out. You don’t know why a particular decision was made, which step introduced an error, or whether the system is degrading gradually over time.

This matters more for agents than for traditional software because agent behavior is probabilistic. The same input can produce different outputs across runs. Without logging at the decision level, not just the input/output level, you can’t distinguish a one-off anomaly from a systematic failure pattern.

The minimum viable observability setup logs: the input to each agent component, the reasoning or classification output, the action taken, and the result. That’s four data points per step. For a 5-step pipeline, that’s 20 log entries per run. It feels like overhead until the first time you need to debug a failure that happened 3,000 runs ago.

For teams building these pipelines in n8n, the ForgeWorkflows blueprint catalog includes systems with observability hooks built into the architecture, so you’re not retrofitting logging after the fact.

What the Winning Deployments Have in Common

The organizations getting enterprise agent deployments right share three traits. They define governance before they write code. They design for failure, not just for the happy path. And they treat the agent architecture as a system to be maintained, not a project to be shipped.

The conference circuit in 2026, including CrewAI’s presence at Snowflake Summit, is full of impressive demos. Demos optimize for the happy path with clean inputs and cooperative conditions. Production systems face dirty data, adversarial inputs, and edge cases that no demo ever shows. The gap between those two environments is where most deployments fail.

If you’re evaluating where your organization sits on this spectrum, the distinction between AI tools and agentic systems is a useful starting point. The architectural decisions are different, and conflating the two leads to the exact failure modes described above.

What We’d Do Differently

Map inter-agent dependencies before choosing a framework. We spent two weeks refactoring the Autonomous SDR because we chose the orchestration pattern before we understood the data dependencies. The dependency map should come first. The framework choice follows from it, not the other way around.

Run a security review against an agentic threat model, not a traditional one. Standard application security reviews miss the action surface that agents introduce. We’d bring in a reviewer specifically familiar with prompt injection and tool-call abuse before any system touches production data, even in a limited pilot.

Build observability into the first prototype, not the second. Every time we’ve said “we’ll add logging later,” later has meant debugging a failure with no data. The cost of adding structured logging to a prototype is low. The cost of reconstructing what happened in a production failure without it is high.