Mert

Gartner’s prediction isn’t about bad models. It’s about a missing infrastructure layer.

Gartner predicts that more than 40% of agentic AI projects will be cancelled by 2027. The reason given: cost, weak ROI, and poor governance.
Most teams hear “poor governance” and reach for a framework. They write policies. They set up review committees. They document acceptable outputs. They file compliance reports.
None of this prevents the failure mode that’s actually killing projects.

The Failure Mode Nobody Talks About
Here’s what a typical agentic AI failure looks like in production:
The pipeline runs. The output looks reasonable. No exceptions are thrown. No alerts fire.
Three steps earlier, an agent received state that didn’t meet the conditions for that step. It ran anyway. It produced output that looked plausible but was built on invalid foundations. Two steps later, another agent acted on that output. By the time the final result surfaces, the error is untraceable.
This isn’t a governance failure in the policy sense. The policies existed. The model was aligned. The guardrails were in place.
It’s an enforcement failure. Nobody checked whether the state was valid before the agent got control.

What Governance Frameworks Actually Cover
Most AI governance frameworks operate at two levels:
Design-time governance: policies about what the system is allowed to do, data handling requirements, human oversight requirements, documentation standards.
Output-time governance: guardrails on what the model returns, content filtering, output validation.
Both are necessary. Neither is sufficient.
There’s a third level that frameworks consistently miss: runtime enforcement at stage boundaries — checking whether the state entering each agent step is valid, and whether the action the agent is about to take is permitted given current runtime context.
Design-time governance says: “agents should not process data from restricted jurisdictions.”
Output-time governance says: “flag outputs that reference restricted jurisdictions.”
Runtime enforcement says: “before this agent runs, verify that jurisdiction is not restricted. If it is — block the action, preserve state, write an audit entry.”
The first two are policy. The third is enforcement. Policy without enforcement is documentation.

Why Projects Get Cancelled
The 40% cancellation rate isn’t happening because organizations lack policies. Most organizations that reach the agentic AI stage have governance policies in place.
Projects get cancelled for three concrete reasons:

1. Failures are invisible until they’re catastrophic.
   Agent pipelines fail silently. Shared mutable state passes through multiple LLM calls, and each call can degrade that state in ways that look like normal output. By the time the failure is visible, it has propagated through the system. Reconstruction is expensive or impossible.
2. Replay without idempotency is dangerous.
   When a pipeline fails mid-run, teams face a choice: restart from the beginning and risk re-executing side effects (duplicate API calls, double charges, repeated writes), or investigate manually. Neither is acceptable at scale.
3. Audit trails don’t prove enforcement.
   Regulators and compliance teams increasingly ask not just “what did the system do” but “can you prove the system was constrained before it acted.” Logging outputs answers the first question. It doesn’t answer the second.

The Missing Layer
The infrastructure that would prevent these failures exists in traditional software. It just hasn’t been applied to agent pipelines.
Pre-conditions: before an agent step runs, verify that the state meets required conditions. If it doesn’t — reject the step, preserve state, write a structured failure event with full context.
Policy gates: before the LLM call, evaluate whether the action is permitted given current runtime context. Not after the output — before the call. If jurisdiction is restricted, the model never runs. No tokens consumed. No side effects.
Checkpoints: after each stage completes, write the state to a checkpoint. If the pipeline fails mid-run, replay from the last checkpoint. Steps already completed are skipped via idempotency keys — no double execution.
Structured audit trail: not just logs of what the model returned, but records of what conditions were true when each step ran, which policies evaluated, and whether they passed or failed.

What This Looks Like in Practice
A pipeline with enforcement built in behaves differently when something goes wrong:

[intake] ✓ pre: observation_present
[intake] ✓ post: normalized
[taxonomy] ✓ pre: normalized
[taxonomy] ✕ post: species_identified → ContractViolation
→ state preserved at failure point
→ DLQ entry written
stage: taxonomy
predicate: species_identified
context: { ...full state snapshot... }
→ replay available from: taxonomy
The failure is caught at the exact point it occurs. The state is preserved. The audit entry contains everything needed for diagnosis. Replay from the failure point doesn’t re-execute completed steps.
Compare this to the standard failure mode: exception in production, stack trace in logs, restart from the beginning, hope the side effects don’t cause problems.

Governance Frameworks Are Necessary But Not Sufficient
This isn’t an argument against governance frameworks. EU AI Act compliance, internal audit requirements, responsible AI policies — all of these matter and all of them are necessary.
The argument is that governance frameworks operate at the wrong layer to prevent the failure mode that’s causing the 40% cancellation rate.
Policy documents don’t run before agent steps. Review committees don’t evaluate runtime state. Compliance reports don’t prevent invalid state from entering a pipeline.
The teams that will not be in the 40% aren’t the ones with the most comprehensive governance policies. They’re the ones that built enforcement into the pipeline itself — pre-conditions, policy gates, checkpoints, structured audit trails — as first-class primitives, not afterthoughts.
Governance tells you what’s allowed.
Enforcement ensures only what’s allowed actually happens.
The gap between those two things is where the 40% lives.

If you’re building agentic AI pipelines and thinking about the enforcement layer, DEED is a runtime contract engine for Python agent pipelines: pre/post conditions, policy gates, checkpoint/replay. Zero dependencies. Python 3.10+.
github.com/Deadly-Reiter/deed · pip install deed-runtime

I wrote a longer post on my blog about why I started Lucky S Software right now: I Didn’t Launch a Software Studio. I Took a Position.. That version has the reasoning together with the personal side of the decision.

This is the short version. Ten reasons, one sentence each, no founder story.

1. So much is shifting at once — AI, robotics, biotech, new interfaces — that the real question isn’t what gets built, it’s who ends up with the advantage when the dust settles, and that’s not a question I wanted to answer from the sidelines.
2. I have the technical background to stay comfortably employed for years, and that’s exactly the trap a lot of capable people are walking into right now — mistaking delay for safety.
3. Most software companies updated their vocabulary but not their structure, so “we use AI” usually still means too many meetings, split accountability, and human-heavy workflows that just mention AI more often.
4. In a slow market, a title feels like protection; in a fast one, it traps you, and the better move is building enough agency to reposition when you need to.
5. “We’re building a SaaS” no longer carries automatic credibility, which is healthy news, because the better question — is this actually defensible, or just easier to launch than it used to be — is finally being asked first.
6. Thousands of real businesses are running on outdated systems that were never economically worth rebuilding, and AI-assisted development quietly changed that math: work that used to take months now fits into weeks.
7. One operator with enough range and the right tools can now ship what used to take a small team — not as elegantly, but often well enough to make the old org chart look slow and expensive.
8. Big software companies built their economics around headcount, so staying competitive now requires them to shrink, while a new studio starts small on purpose — one model has to unwind itself, the other never built the problem.
9. AI workflows, memory, and agents are eating the context-switching overhead that used to force teams to grow, so the number of people needed to maintain meaningful software output is dropping.
10. Most people can already feel the change but don’t want to admit what it implies, so they wait — and waiting for emotional certainty is usually just a polite way of being late.
    ## Closing

A leaner, sharper kind of software company is being built right now, and the longer I watched, the clearer it got that watching was the expensive choice.

If any of this landed, the full essay — including why I personally chose to take a position instead of wait — is on luckys.dev.

Every developer has a collection of bookmarks. JSON formatters, Base64 encoders, hash generators, regex testers – the list goes on. We visit these sites multiple times a day, copy-paste our data, get the result, and move on.
But have you ever stopped to think about what’s actually happening behind the scenes?
The Problem with Most Developer Tools
Last month, I was debugging an API response. I needed to format some JSON quickly. I opened a popular online formatter, pasted my data, and… was greeted with a full-screen ad. After closing it, I found the tool. But wait – there was another popup asking me to sign up for “premium features.”
This pattern repeats across dozens of developer tool websites:

• Intrusive ads that slow down your workflow
• Signup walls for basic functionality
• Tracking scripts that follow you around the web
• Inconsistent UIs that make you relearn the interface each time
  The Real Cost
  Let’s do some quick math. If you use 5 different tool websites daily, and each one wastes 30 seconds on ads and navigation, that’s:
• 2.5 minutes per day
• 12.5 minutes per week
• ~10 hours per year
  That’s more than a full workday lost to tool-switching overhead.
  Why I Built My Own
  I decided to build a single platform with all the tools I use regularly. The requirements were simple:
• No ads
• No signup
• No tracking
• Consistent interface
• Fast loading
  The result was a collection of 90+ developer tools, all running client-side in the browser.
  Technical Decisions
  Vue.js 3 + TypeScript: I chose Vue because of its reactivity system and TypeScript support. The Composition API makes it easy to organize tool logic.
  Vite Build Tool: Fast hot module replacement during development, optimized production builds.
  Cloudflare Pages: Free hosting with global CDN. The site loads in under 1 second worldwide.
  Client-side Processing: All tools run in the browser. No data is sent to any server. This was non-negotiable for privacy.
  The SEO Challenge
  Building the tools was the easy part. Making them discoverable was harder.
  Developer tool sites face a unique SEO challenge: each tool is essentially a separate product with its own search intent. “JSON formatter” and “hash generator” are completely different queries, but they’re on the same website.
  Solution: Each tool gets its own page with:
• Unique title and meta description
• Dedicated H1 heading
• Tool-specific structured data (JSON-LD)
• Internal links to related tools
  Results After 3 Months
• 93 tool pages indexed by Google
• 500+ daily organic visitors
• Top 10 rankings for long-tail keywords
• Zero ad revenue (intentional)
  Lessons Learned
• Free tools attract users, but content keeps them – Tools alone don’t build loyalty. Tutorials and guides do.
• SEO for tool sites is different – Each tool needs its own SEO strategy, not just the homepage.
• Performance matters more than features – A fast, simple tool beats a slow, feature-rich one every time.
• Open source builds trust – Making the code available on GitHub builds credibility.
  Try It Yourself
  The tools are available at agentsaitools.com. No signup, no ads, no tracking. Just tools that work.
  What developer tools do you use daily? I’d love to hear about your workflow in the comments.

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

My 6-year-old asks me four hundred questions a day — about clouds, his shadow, whether ants have birthdays. I love it, but I can’t always stop what I’m doing, and the usual fallbacks (Google, YouTube, a generic chatbot) are either too dense, too distracting, or too unsafe to hand a small child. Curio Kid is the app I built so my son can keep asking — and actually get warm, kid-friendly answers — without me worrying about what he sees next.

What I Built

Curio Kid is a kid-safe Android app where a child asks anything — by typing, snapping a photo, attaching an image, or just talking — and gets a warm, age-appropriate answer from Luna, an AI tutor powered by Gemma 4. Answers are short on purpose: 2–5 sentences, an everyday analogy (Lego, swings, fruit), and a follow-up question to keep the curiosity loop running.

Designing it for my own kid forced some opinionated choices:

• He can’t reliably read or type yet, but he can talk and point a camera. Voice and camera are first-class inputs, not afterthoughts.
• He will absolutely test the safety rails. Kids ask wild things (“what happens if I drink poison?”, “why do people fight in wars?”) — Luna has to handle them gracefully every single time.
• I want to know what he’s curious about, not spy on him. Hence the Curiosity Digest — a daily themed summary, not a chat log.

What makes it more than “yet another chatbot wrapper”:

• Multimodal input — text, gallery image, live camera, on-device speech-to-text.
• Safety as a hard requirement — locked-down system prompt + Gemini safety thresholds pinned to LOW_AND_ABOVE across harassment, hate, sexually explicit, and dangerous content; unsafe topics get a fixed redirect to “a trusted adult.”
• Parent Dashboard — PIN-gated, with a one-tap Curiosity Digest: themes, highlights with quotes, dinner-table conversation starters, and an “anything to flag?” section.
• Privacy-first — API key + PIN in EncryptedSharedPreferences (AES-256); question history in a local Room DB, excluded from cloud backup; the only network call is to the model endpoint with the user’s own key.
• Three interchangeable Gemma 4 back-ends — not every family phone can host a multi-gigabyte model on-device, so Google AI Studio (default, free tier, multimodal), OpenRouter, and a scaffolded on-device path are all swappable from Settings.
• Output cleaning — Gemma 4 sometimes thinks out loud (“Final Polish:”, “Let me revise…”); a post-processor strips those leaks so the child only sees the final answer.

Demo

https://raw.githubusercontent.com/sann3/curio-kid/main/demo/Home.png
https://raw.githubusercontent.com/sann3/curio-kid/main/demo/1i.png
https://raw.githubusercontent.com/sann3/curio-kid/main/demo/2i.png
https://raw.githubusercontent.com/sann3/curio-kid/main/demo/3i.png
https://raw.githubusercontent.com/sann3/curio-kid/main/demo/4i.png
https://raw.githubusercontent.com/sann3/curio-kid/main/demo/5i.png
https://raw.githubusercontent.com/sann3/curio-kid/main/demo/6i.png

https://raw.githubusercontent.com/sann3/curio-kid/main/demo/final.mp4

Code

GitHub: github.com/sann3/curio-kid.

How I Used Gemma 4

Curio Kid exposes two Gemma 4 variants in the model picker, and the choice is intentional.

gemma-4-26b-a4b-it — 26B Mixture-of-Experts (default)

The daily driver. A kid-facing chat app needs three things at once: multimodal, fast first-token latency, and smart enough to teach. MoE hits all three — only a slice of experts fires per token, so latency feels ~4B-class while depth stays 26B-class. In practice:

• A child holding up a beetle to the camera gets an answer in a couple of seconds, not ten.
• Streaming starts almost instantly, so chat bubbles fill in live (and incidentally dodge the Gemini SDK’s hard-coded 80s socket timeout — Curio Kid uses generateContentStream for exactly this reason).
• The 256K context window means the whole day’s history fits into a single Curiosity Digest call — no RAG, no summarisation tricks.
• Same model handles “Why is the sky blue?” and a photo of a moth.

Dense is overkill for “explain photosynthesis in three sentences”; E2B/E4B don’t yet match 31B-class reasoning on the harder “why” questions kids love. MoE is the right middle.

gemma-4-31b-it — 31B Dense (optional “thinker” mode)

For genuinely hard questions (“Why do mirrors flip left-and-right but not up-and-down?”). Slower and pricier per call, but noticeably better on multi-step or counterintuitive reasoning. Same persona, same safety, same UI — just a heavier brain when the curiosity warrants it.

Why not E2B / E4B by default?

On-device is fully wired up via MediaPipe LLM Inference — Settings → On-device downloads a vision-capable Gemma 4 .task (resumable, sha256-checked, metered-network aware) and runs it through a process-wide LlmInference singleton with addImage for the camera path. But cloud stays the default because:

1. Not every phone can run Gemma 4 locally. Multi-GB models need RAM and storage the hand-me-down tablet a kid actually uses doesn’t have. Gating first launch behind “Pixel 8 Pro + 1.6 GB cellular download” defeats the point.
2. Quality > offline for a six-year-old. Being told “the moon is made of cheese” by an under-cooked tiny model is worse than waiting two seconds over Wi-Fi.

So Google AI Studio is the zero-friction default, OpenRouter is the alt-cloud, and on-device is one Settings tap away for capable phones — same LlmBackend interface, same prompts, same cleaner.

Where Gemma 4 actually does the work

1. The chat. Multimodal (image + history + question) → kid-friendly paragraph. The system prompt is strict (2–5 sentences, analogies, ≤2 emojis, one follow-up, no markdown) and Gemma 4 follows it remarkably well.
2. Safety reasoning. Instead of a blocklist, Luna reasons about whether a topic is age-appropriate and produces a fixed redirect line — Gemma 4 is instruction-faithful enough to honour a “ONLY reply with this exact sentence” clause while still engaging naturally with the 99% of fine questions.
3. The Curiosity Digest. Day’s transcript → structured markdown summary (themes / highlights / conversation starters / flags) in one shot — long-context + structured-output, no orchestration framework.

Bits I had to engineer around Gemma 4’s quirks

• Chain-of-thought leakage. Gemma 4 occasionally emits “Final Polish:” / “Self-Correction:” / “Let me rewrite…” before its real answer. cleanLunaReply (LunaAI.kt) detects anchors, drops planning paragraphs, and strips markdown emphasis — without nuking legit phrases like “Let me think of a fun example!”.
• MAX_TOKENS stops. The Gemini SDK throws ResponseStoppedException instead of returning partial text; I catch it on both one-shot and streaming paths and surface what already arrived.
• 80s socket timeout. Hard-coded in the Kotlin SDK with no RequestOptions override. Streaming resets the read timer per chunk, so slow first-byte doesn’t kill the request.
• Friendly errors. One friendlyError() mapper turns every 4xx/5xx/safety/quota/network failure into one short, kid-readable sentence (“Wow, so many questions today! Let’s wait a minute and try again.”), while logging the raw exception to a debug ring buffer.

Gemma 4 unlocked something I couldn’t have shipped a year ago: a multimodal, instruction-faithful, locally-routable model smart enough to teach a six-year-old about black holes, safe enough to hand to that six-year-old, and efficient enough to be the default tier of a free app.

Thanks to the DEV team and Google for the challenge!

Hello Dev Community! 👋

This is officially Day 2 of my web development journey (as part of my MERN stack goal). After successfully laying down the foundational skeleton yesterday, today was about refinement and expansion.

🧠 Key Learnings From Day 2

1. The Trap of Absolute Image Paths

Yesterday, I added my first image, but I used an Absolute Path (pointing directly to a specific folder on my computer’s drive). A fellow developer politely pointed out that while this works for me, it will fail for everyone else once the site is deployed.

I learned about Relative Paths, which define the image’s location relative to the HTML file. It makes the codebase portable.

My Fix Today:
I took control of my asset organization! I moved the image into a dedicated assets folder within my project structure and updated my <img> tag:

html
<img src="D:My Code BaseQuaid e Azam.jpg" alt="Quaid">

<img src="assets/Quaid e Azam.jpg" alt="Quaid">

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

Google I/O 2026 Made the Search Box Feel Like an Agent Layer

A few weeks ago, after Google Cloud NEXT ’26, I wrote that the agentic shift was already rewriting how we build software.

At Google I/O 2026, that same idea clicked again — but from a different angle. This time, it was not mainly about cloud infrastructure, enterprise workflows, or multi-agent orchestration platforms. It was not only about a new Gemini model, a redesigned app, or another polished demo of AI doing something impressive on stage.

It was the search box.

That sounds almost too simple, but I think that is exactly why it matters. For more than 25 years, the Google search box has been one of the most stable interfaces in computing: type a few words, get a list of links, open pages, and do the work yourself.

At I/O 2026, that familiar box started to look like something else.

Not just an input field. Not just a gateway to links. But a place where users can express intent, attach context, generate interfaces, start agents, monitor information, and continue tasks over time.

Google Cloud NEXT made agents feel like infrastructure.

Google I/O made them feel like the interface.

And honestly, that might be the bigger shift.

From Agent Infrastructure to Everyday Interface

What stood out to me at Google Cloud NEXT was that AI was no longer presented as just a smarter API call. It was becoming a layer that could operate across tools, keep context, coordinate work, and continue over time. As a developer, that changed how I looked at software.

Instead of thinking only in endpoints, requests, and responses, we suddenly had to think about responsibilities, permissions, state, handoffs, and behavior. The system was no longer just reacting to input. It was starting to act, coordinate, and evolve.

But at NEXT, that shift still felt mostly like something happening inside platforms: cloud tools, enterprise workflows, agent orchestration systems, internal automation, and developer environments.

Google I/O 2026 made that same idea feel much closer to everyday users.

Search, Gemini, Gmail, Chrome, Android, AI Studio, developer tools, and even the browser itself are becoming surfaces where agentic behavior can show up. That is a different kind of shift, because it moves agents from the backend of software into the place where people already begin their digital lives.

If Search can start tasks, generate custom interfaces, monitor information, reason over personal context, and connect into tools, then Search is no longer just a page of results.

It starts to look like a task layer.

The Search Box Is No Longer Just a Search Box

For a long time, the search box trained us to compress what we wanted into keywords.

We did not write full thoughts. We did not attach messy context. We did not explain our situation in detail. We learned to search in fragments:

• best laptop 2026
• weather Berlin
• React form validation
• cheap flights Tokyo
• coffee machine red eco friendly

That was the rhythm of search. You compressed your intent into the shortest useful phrase, Google returned links, and then you did the real work yourself.

The new direction feels different.

The search box is becoming more like a command surface: a place where a user can bring a longer question, a document, an image, a video, a browser tab, or a more complex goal. Instead of only returning links, the system can answer, visualize, summarize, compare, generate a custom UI, or hand work off to an agent.

That is subtle, but huge.

Because once the interface can understand long-running intent, accept different kinds of context, generate interactive results, and let agents continue work over time, it becomes less like a search engine and more like a lightweight operating layer above the web.

Not an operating system in the classic sense.

But an operating layer for intent.

The user expresses what they want, and the system figures out what information, tools, apps, or agents are needed to move forward.

Source: Google — “What’s New in Search”

What stood out to me in that Search session was not only the AI answer layer. It was the way Search is being redesigned around longer questions, richer context, follow-up behavior, generated interfaces, and tasks that can continue beyond a single query.

That is the part that makes it feel less like a search feature and more like an agent interface.

This Did Not Start in 2026

What makes this shift even more interesting is that it did not come out of nowhere.

Back in 2023, Google introduced the Search Generative Experience. At that point, the idea was still relatively easy to understand: AI could summarize answers directly inside Search and let users ask follow-up questions. That was already a major change, but it still felt like search with an AI layer on top.

You typed a question. Google generated an answer. Links still sat nearby as supporting sources.

The risk was already visible back then: if Google starts summarizing more of the web directly, users may rely more on Google itself instead of visiting the sources behind the answer. It raised questions about publishers, source visibility, hallucinations, ads, and how much trust people should place in an AI-generated answer.

But in 2026, the direction feels bigger than summarization.

The search box is not just becoming a place where AI writes answers. It is becoming a place where users can bring files, images, videos, browser tabs, and long-running intent. That moves Search from answering questions toward operating on tasks.

And that changes the meaning of Search.

From Keywords to Intent

The old search box asked users to compress intent into keywords.

The new one asks them to express intent more fully — and then lets AI systems decide what should happen next.

That is a massive change in interface design. The user is no longer only searching for a page. They may be starting a workflow, asking for a comparison, generating a custom UI, creating a tracker, delegating a task, or asking an agent to keep watching something in the background.

That means the search box is no longer just an input field.

It becomes a boundary between human intent and machine action.

And boundaries like that need careful design.

This is where the shift becomes more serious. A search query used to be relatively low-risk. If the result was bad, you clicked something else. But once search becomes a place where agents can act, monitor, remember, and coordinate across tools, the design problem becomes much deeper.

The question is no longer only:

Did Search find the right information?

It becomes:

Did the system understand the intent correctly?

Did it use the right context?

Did it act within the right permissions?

Can the user understand what happened?

That is a very different product problem.

Developers Are Not Just Building Apps for Humans Anymore

This is where the developer impact gets interesting.

For a long time, we built software mainly for human users. We designed buttons, forms, APIs, pages, dashboards, onboarding flows, and settings screens. Even when we built APIs, we usually imagined another deterministic system calling them.

In an agentic environment, that changes.

We also need to build software that agents can understand and operate reliably. That means the structure of software matters in a new way. An app is no longer only judged by how it looks to a human. It may also be judged by how clearly it exposes actions, state, permissions, and consequences to an AI system trying to help the user.

Can an agent understand what actions are possible?

Can it tell the difference between previewing an action and executing it?

Can it call the right tool safely?

Can it recover if something goes wrong?

Can it explain what it did?

Can it respect permissions?

Can it operate without accidentally crossing a boundary?

This is not only a UX problem.

It is an architecture problem.

WebMCP Feels Like a Signal

One announcement that stood out to me was WebMCP.

The idea of exposing structured tools on the web so browser-based agents can execute tasks more reliably feels like a clear signal of where things are going. The web was built for humans clicking around, reading pages, filling forms, and interpreting visual layouts.

Agents can technically click around too, but that is fragile.

They can misread layouts, click the wrong thing, hallucinate state, or fail when the UI changes. A human can often recover from a confusing interface. An agent might confidently do the wrong thing.

Structured tools change that. They give agents a more reliable way to interact with web apps, and that means developers may need to think about a new layer of web compatibility.

Not just:

• Does this page work in Chrome?
• Does it pass accessibility checks?
• Is it responsive?

But also:

• Can an agent understand this?
• Are actions clearly exposed?
• Are permissions explicit?
• Can the system explain what happened?
• Can dangerous actions be separated from harmless ones?

That could become a real design constraint.

And honestly, it probably should.

AI Studio and Antigravity Show the Other Side

The developer tooling side is just as important.

Google’s announcements around AI Studio, Antigravity, managed agents, Android CLI, and Chrome DevTools for agents point to a future where agents are not only using software. They are helping build it.

That creates a strange loop.

Agents help developers build apps. Those apps expose tools and structured interfaces. Other agents then use those apps. Over time, the developer is no longer just building a product for a person sitting in front of a screen.

They are building part of an agent ecosystem.

That means good software design becomes more than clean code and nice UI. It becomes about making systems legible, controllable, observable, and safe for both humans and agents.

This also changes what “developer experience” means. It is not only about documentation, SDKs, and nice error messages anymore. It may also be about whether an agent can understand your system well enough to extend it, debug it, test it, or operate it safely.

The Old Problems Did Not Go Away

This is where my thinking connects back to my previous post.

The same problems are still there.

Context is still the bottleneck. Memory still changes the nature of the system. Governance is still not optional. Debugging is still becoming more about decisions than code.

But at I/O, those problems moved closer to the user.

If a cloud agent makes a wrong decision in a controlled enterprise workflow, that is already serious. But if a personal agent acts across Gmail, Calendar, Search, shopping, documents, browser tabs, and third-party tools, the trust problem becomes much more personal.

The question is no longer only:

Can the model do the task?

The question becomes:

Should it?

With which data?

Under which permissions?

With what audit trail?

And how does the user stay in control?

That is the part I think developers should pay close attention to. The more agentic systems become, the less useful it is to think only in terms of prompts and outputs. The real challenge moves into the surrounding system: context, permissions, memory, identity, traces, and recovery.

The Trust Layer Becomes the Real Platform

This is probably my biggest takeaway from Google I/O 2026.

The next platform layer is not just the model.

It is not just the agent runtime.

It is trust.

Identity, permissions, memory boundaries, audit logs, sandboxing, confirmation flows, data minimization, and clear user control will matter more and more. Because the more useful agents become, the more dangerous vague authority becomes.

A chatbot that gives a bad answer is annoying.

An agent that takes the wrong action is a different problem.

And an always-on agent with access to personal context, tools, files, money, and communication channels is not something we can treat like a normal app feature.

That needs a different level of design.

It also needs a different level of humility. Autonomy is not automatically good. More access is not automatically better. A system that can do more is only useful if the user can understand it, constrain it, correct it, and trust it.

Where Most Teams Are Still Thinking Too Small

A lot of teams still treat AI as something they add to an existing product.

A chat window. A summarization button. A smarter search field. A content generator. Those things are useful, but they are not the full shift.

The bigger change is that software itself is becoming more agentic.

It acts over time. It coordinates tools. It remembers. It makes decisions. It generates interfaces. It can be delegated tasks. It can operate across products.

That means the UI is no longer the whole product. Sometimes the product is the behavior behind the UI. Sometimes the user may never touch the UI directly at all.

This is where I think many teams will underestimate the change. They will ask, “Where should we add AI?”

But the better question might be:

What parts of our system are safe, structured, and understandable enough for an agent to operate?

That question leads to very different design decisions.

What Developers Should Pay Attention To

After I/O, I think developers should pay attention to a few things.

First, make your systems understandable to agents. If agents are going to operate software, vague interfaces and hidden side effects become a bigger problem.

Second, treat permissions as product design, not just security configuration. Users need to understand what an agent can do, not only what data it can read.

Third, build for observability. If an agent acts, there should be a trace of what it saw, what it decided, what tool it used, and what happened after.

Fourth, think carefully about memory. Memory makes agents useful, but it also makes systems harder to debug and harder to trust if it is not transparent.

And finally, do not confuse autonomy with usefulness. The best agent is not always the one that does the most. Sometimes the best agent is the one that knows when to ask, when to stop, and when to hand control back to the human.

Final Thought

Google I/O 2026 did not just show better AI features.

It showed a different interface model.

Not software that waits for clicks, but software that understands intent, coordinates tools, generates interfaces, and keeps working over time.

At NEXT, agents looked like infrastructure.

At I/O, they started looking like the interface.

That is a big deal.

Because the future may not be:

AI inside every app.

It may be:

Agents operating across every app.

And if that is where things are going, developers have a new responsibility. We are not just designing screens anymore. We are designing behavior, trust, and control in systems that can act.

Misconfiguration isn’t a personnel failing. It’s a structural property of platforms that PERMIT unsafe constructs. Google, Spotify, Netflix, and Shopify solved this by removing the unsafe constructs from the developer surface entirely. 95-99% reduction in misconfiguration incidents. Most organizations can’t build that platform. Here’s the alternative — and why the two approaches are complementary, not competing.

Google’s internal infrastructure doesn’t have publicly exposed storage buckets. Not because Google engineers are more careful. Because the construct “public bucket” doesn’t exist in their developer surface. A Google engineer deploying an internal service writes a one-line service declaration. The platform synthesizes everything — network policy, RBAC, TLS certificates, monitoring, secrets management. The developer never sees the configuration knobs that would produce a misconfiguration.

The misconfiguration doesn’t happen because it CAN’T happen. The unsafe construct isn’t guarded against. It’s ABSENT.

This is the upstream approach to misconfiguration — and it’s been independently adopted by Google, Spotify (Backstage + Golden Paths), Shopify (Polaris), and Netflix (Paved Road + Spinnaker). Each reports 95-99% reductions in misconfiguration incidents.

Most organizations can’t build this. Here’s why — and what to do instead.

The reframe: misconfiguration is structural, not personal

The industry frames misconfiguration as a KNOWLEDGE problem:

"The engineer didn't know the right configuration"
    → Fix: more training
    → Fix: better documentation  
    → Fix: security champions
    → Fix: mandatory reviews

Each fix addresses the engineer. Each assumes the PERSON is the variable. Train them better. Document more clearly. Review more thoroughly.

The structural reframe:

"The platform PERMITS the unsafe configuration"
    → Fix: remove the unsafe configuration from the platform's vocabulary

This fix addresses the PLATFORM, not the engineer. The engineer’s knowledge doesn’t matter because the unsafe construct doesn’t exist in the surface they interact with. A developer who doesn’t know that publicly exposed storage is dangerous can’t create it — not because they learned it’s dangerous, but because the option literally isn’t available.

Three implications:

Personnel interventions don’t work at scale. Training addresses one engineer at a time. The next hire resets to baseline. Turnover regenerates the problem. The structural property persists regardless of who’s on the team.

Process interventions are insufficient. Code reviews catch SOME misconfigurations. The reviewer must notice the unsafe construct among hundreds of lines of IaC. The review is human-speed; deployments are machine-speed. The process can’t keep pace.

Structural interventions work. Redesign the developer surface so unsafe constructs are unexpressible. The misconfigurations disappear because they have no expressive form. Not hard to create. IMPOSSIBLE to express.

What the upstream platform looks like

A developer using the upstream platform:

Developer writes:     "Deploy service: order-processor, tier: production"

Platform synthesizes:
    ✓ Namespace with correct labels + Pod Security Admission
    ✓ NetworkPolicy: default-deny + exact required egress
    ✓ RBAC: least-privilege ServiceAccount derived from tier
    ✓ SPIFFE identity automatically issued and mounted
    ✓ Secrets from Vault with automatic rotation
    ✓ OpenTelemetry auto-injected
    ✓ Immutable root filesystem, read-only containers, drop-all capabilities

The developer’s input: one line. The platform’s output: a complete, production-ready, secure-by-construction service. The developer never sees NetworkPolicy YAML. Never writes RBAC rules. Never configures TLS. Never manages secrets.

The platform’s vocabulary is BOUNDED to pre-approved safe forms (golden templates). The developer can’t request a public endpoint without going through an explicit, reviewed approval path. The unsafe construct isn’t in the default vocabulary.

Four architectural properties:

The fourth property is the most distinctive: physically impossible to deploy publicly exposed storage or an overpermissive role because those constructs DON’T EXIST in the allowed schema.

Who has built this — and what they achieved

Four independent organizations. Same pattern. Same results. The convergence is empirical evidence the approach works.

Why most organizations can’t do this

Despite the evidence, most organizations do NOT build upstream platforms:

Building an Internal Developer Platform requires:
    ✗ A dedicated platform team (5-20+ engineers)
    ✗ Multi-year staffing commitment
    ✗ Deep integration with cloud vendor APIs
    ✗ Continuous maintenance as cloud features evolve
    ✗ Organizational authority to mandate platform adoption
    ✗ Budget for a system that doesn't ship customer features

The investment pays off AFTER years of operation. Most organizations need safety NOW with the team they HAVE. The upstream approach is available but not accessible.

This creates a structural gap: the approach that WORKS (upstream platform) is inaccessible to the organizations that NEED it most (teams without platform-engineering capacity).

The downstream alternative

The downstream approach addresses the gap. Instead of preventing unsafe constructs from being EXPRESSED, it catches them before they reach PRODUCTION:

Upstream (Internal Developer Platform):
    Developer intent → Platform synthesizes safe config → Production
    Unsafe constructs never expressible

Downstream (Invariant evaluation):
    Developer writes IaC → Evaluation catches unsafe state → Block before production
    Unsafe constructs expressible but caught before deploy

The upstream approach has HIGHER safety but HIGHER cost. The downstream approach has LOWER safety (bypassable, coverage-bounded) but DRAMATICALLY lower cost (adoptable by any team with CI/CD).

The choice matrix

Most organizations are in the SECOND row: no platform team, but mature CI/CD. The downstream approach is their accessible path to safety properties the upstream approach would provide if they could build it.

The THIRD row (hybrid) is increasingly common. Large organizations build upstream platforms for new services AND use downstream evaluation for legacy services that don’t yet flow through the platform. The two approaches are complementary — each covers what the other misses.

What the downstream approach catches that upstream can’t

Upstream platforms are powerful but bounded:

What upstream platforms miss:
    ✗ Legacy services not on the platform (migration takes years)
    ✗ Emergency bypass / break-glass operations
    ✗ Cloud provider API changes that introduce new unsafe defaults
    ✗ Platform template bugs (the template itself is misconfigured)
    ✗ Cross-service compound risks (the template is safe per-service; the combination isn't)

The downstream approach catches ALL of these — because it evaluates ACTUAL STATE (snapshots) against invariants (catalog), regardless of how the state was produced. A legacy service that never touched the platform? Evaluated. A break-glass console change? Caught in the next post-deploy snapshot. A template bug? The invariant catches what the template missed. A compound risk across services? Chain controls evaluate cross-asset conditions.

The downstream approach is the SAFETY NET under the upstream platform. Even organizations with full IDPs benefit from a downstream evaluation layer that catches what slips past the platform.

The convergence trajectory

The industry is moving toward upstream platforms:

As the trajectory progresses, the downstream approach’s role evolves:

Today: Primary safety mechanism for organizations without platforms (most organizations).

2030+: Complementary safety mechanism for organizations WITH platforms — catching legacy, bypass, template bugs, and compound risks the platform doesn’t cover.

The future role isn’t diminished. It’s SPECIALIZED. Even in a fully-platformed world, the downstream evaluation layer provides defense-in-depth that the platform alone can’t.

The honest comparison

The downstream approach does NOT claim upstream-level safety:

The downstream approach trades SAFETY CEILING for ACCESSIBILITY. The safety ceiling is lower (bypassable, coverage-bounded). The accessibility is incomparably higher (any team, any CI pipeline, any cloud provider, today).

For 90% of organizations — the ones that will never build a Google-scale IDP — the accessible option is the only option. And the accessible option with 2,650 invariants evaluated before every deploy is DRAMATICALLY safer than the current state of no evaluation at all.

For your organization

If you have a platform team: Build the upstream IDP. The evidence supports 95-99% reduction. Add downstream evaluation as defense-in-depth for legacy, bypass, and compound risks.

If you don’t have a platform team: Adopt downstream evaluation. Single binary in CI. 2,650 controls evaluating every deploy. Achievable this week, not next year.

If you’re building toward a platform: Start with downstream evaluation NOW while building the platform. The catalog you develop during downstream evaluation INFORMS the golden templates you’ll build for the platform. The two investments compound.

Google engineers can’t create publicly exposed storage buckets because the option doesn’t exist in their surface. Your engineers can — because your surface permits it. The upstream fix removes the option. The downstream fix catches it before production. Both work. One takes years and a platform team. The other takes a binary and an afternoon. Start with what you can do today.

The downstream alternative — 2,650 invariants evaluated against actual cloud state, catching what upstream platforms miss, accessible to any team with CI/CD — is Stave, an open-source Risk Reasoner. Single binary. No platform team required. Defense-in-depth for teams building toward upstream, primary safety for teams that aren’t. Try it: bash examples/demo-ai-security/run.sh

Data synchronization in GBase 8a isn’t just “primary‑standby replication.” Different business requirements — real‑time, disaster recovery, read/write splitting — lead to completely different technical paths. This article organizes three core approaches — mirror clusters, inter‑cluster sync, and replicated tables — into a practical decision framework for your gbase database.

The Three Sync Routes at a Glance

The key to choosing isn’t memorizing names — it’s clarifying what problem you’re solving. Want the standby cluster to serve queries in near real‑time? Look at mirror clusters first. Need periodic sync to a reporting or DR cluster? Inter‑cluster sync fits better. Just need dimension tables readable across all nodes? Replicated tables are enough.

Mirror Clusters: Real‑Time Active‑Standby and Read/Write Splitting

A mirror cluster aims to get data to the other side as quickly as possible so the standby can serve read traffic continuously — not just during failures. Think of it as table‑level real‑time mapping. It suits:

• Standby must be queryable shortly after writes on the primary
• Intra‑city active‑active or near‑real‑time read/write split
• Tolerates only very small data lag

If the two clusters aren’t in the same data center and the network is mediocre, forcing real‑time sync will cause constant instability. Cross‑region, bandwidth‑limited scenarios are often not the best fit.

Inter‑Cluster Sync: Incremental Distribution and Disaster Recovery

Inter‑cluster sync moves changes on a schedule, accepting minute‑level or even hour‑level delays. It excels at:

• Remote disaster recovery
• T+1 report queries
• One production cluster feeding multiple downstream clusters

A typical topology: production syncs hourly to a reporting cluster, daily to a DR cluster, and cascades to regional query clusters. It’s less demanding on the network than real‑time approaches and more cost‑effective in multi‑downstream, multi‑purpose environments.

Replicated Tables: Write‑Once‑Read‑Many Inside the Cluster

A replicated table keeps an identical copy on every node, spreading read pressure and reducing cross‑node costs during queries. It’s ideal for small tables, dimension tables, and lookup tables that are read frequently but updated infrequently.

Cross‑cluster sync solves “how data reaches another cluster.” Replicated tables solve “how to read more easily within the same cluster.” They operate at different levels.

Four Decision Dimensions

Before designing a sync strategy, answer these four questions:

In short: intra‑city near‑real‑time active‑active / read‑write split → mirror cluster; remote DR / T+1 reporting / multi‑downstream → inter‑cluster sync; hot table read optimization within a cluster → replicated tables.

Three Common Pitfalls

1. Over‑idealizing real‑time requirements — if clusters span data centers with average networks, real‑time sync will be fragile.
2. Treating sync as “automatic full‑database replication” — GBase 8a sync is mostly table‑level. Permissions, job chains, views, scripts, and application connections need separate planning.
3. Watching only “sync success” without verifying “sync usage” — data arriving is not enough. Check whether queries actually shifted to the target, whether the DR link can really switch over, and whether downstream clusters are truly being used.

Pre‑Launch Checklist

Strategy level: Confirm sync mode (real‑time/scheduled/incremental), granularity (table‑level), direction (one‑way/two‑way), downstream count, and network path.

Operational level: Continuously monitor sync lag, incremental backlog, downstream query latency, key‑table row‑count validation, and whether any critical tables are missing from the sync scope.

A simple daily check: compare row counts between source and target for key tables on the same date.

Recommended Rollout Sequence

1. Clarify the goal first: Remote DR → inter‑cluster sync. Intra‑city active‑active → mirror cluster. Report offloading → either works. Hot intra‑cluster tables → replicated tables.
2. Layer the objects: Separate core fact tables, report summary tables, and dimension/lookup tables. Decide which must be real‑time, which can be hourly, and which only need intra‑cluster replication.
3. Confirm windows and link conditions: sub‑second requirements? minute‑level tolerable? cross‑region? multiple downstream clusters?

GBase 8a data sync is a layered, well‑defined capability set. Not every sync needs to be real‑time — the key is reserving real‑time capacity for the places that truly need it in your gbase database.