DEV Community: Deepak Nailwal

Circuit: why AI agents need a circuit breaker before they touch production

Deepak Nailwal — Sat, 15 Aug 2026 15:02:38 +0000

Most AI-agent demos follow the same script: give the agent a plain-English instruction, watch it call an API, done. It's a satisfying demo. It's also not the hard part.

The hard part is what happens next. What happens when the agent is wrong? What happens when it's asked — accidentally or on purpose — to do something dangerous, like issuing a refund or deleting a record? What happens when the network drops halfway through a payment and the same request gets retried?

That's the gap I built Circuit to close.

What Circuit actually does

Circuit is a safety layer that sits between an AI agent and the real-world actions it takes through Swytchcode, which handles the actual API execution — auth, retries, schema validation — across more than 2,000 supported services.

Before any action runs, Circuit puts it through four checks:

1) Risk classification. Every action gets tagged LOW, MEDIUM, HIGH, or BLOCKED based on what it does. Reading a list of repos is LOW risk. Issuing a refund is HIGH risk. Deleting a production database is BLOCKED outright, no matter what.
2) Human confirmation. HIGH-risk actions stop and wait. The agent has to show me exactly what it's about to do — service, action, parameters — before I type "yes."
3) Idempotency protection. If the same action is requested twice (say, because a retry fired after a timeout), Circuit recognizes it and returns the cached result instead of executing it again. No double refunds.
4) A permanent audit trail. Every action, allowed or blocked, gets logged with a timestamp and reasoning — so there's always a record of what an agent actually did and why.

The whole thing lives in a single Python file, with a free fallback parser so it can be tested without any API keys at all.

Proving it against a real API, not a simulation

It's easy to build a safety layer that only ever talks to a mock. I wanted proof it worked against something real, so I connected it to the GitHub API through Swytchcode's CLI pipeline — swytchcode get to pull the integration, swytchcode auth connect for OAuth, then swytchcode exec to actually run the call.

The result: a real GitHub issue, created live, with a 201 status code straight from GitHub's API. Not mocked, not simulated — a genuine HTTP round trip triggered by a natural-language instruction, filtered through Circuit's risk checks the whole way.

What actually broke along the way

None of this worked on the first try, and the failures were more instructive than the successes:

Sandbox vs. production mode. New Swytchcode projects default to a sandbox environment that points at localhost instead of the real API. Nothing fails loudly — it just quietly never leaves your machine — until you flip "mode": "sandbox" to "mode": "production" in tooling.json.
Workspace mismatches. Authenticating a provider happens per-workspace. Create a new project directory and you can end up in a fresh, unauthenticated workspace even though the same account already has GitHub connected elsewhere. swytchcode auth workspace to list and switch fixed it.
Windows encoding quirks. The Swytchcode CLI logs status with emoji (🔐) to stderr. Python's subprocess module on Windows defaults to cp1252, which can't decode them, and throws an unrelated-looking UnicodeDecodeError. Forcing UTF-8 decoding with errors="replace" on every subprocess call fixed it for good.
PowerShell quoting. Inline JSON bodies with --body '{"key":"value"}' get mangled by PowerShell's quoting rules. Writing the body to a temp JSON file and passing --body payload.json instead is the reliable path on Windows.

Every one of these was silent or confusing at first — the kind of thing that erodes trust in an agent fast if you don't build in visibility. That's part of why Circuit prints exactly what command it ran, the exit code, and the raw output whenever a real call fails, instead of swallowing the error.

Why this matters more than another API demo

Anyone can wire an agent to one API and call it a project. The interesting question is what happens when that agent is wrong, or asked to do something irreversible, or the network hiccups at the worst possible moment. Those are the conditions real production systems live in, and they're exactly what most agent demos skip.

Circuit doesn't skip them. It's a small, reusable pattern — risk classification, confirmation, idempotency, audit — that works the same way whether the underlying action is a GitHub issue, a Slack message, or a Stripe refund, because it sits on top of Swytchcode's uniform execution layer rather than hand-rolling integration code per service.

Code: https://github.com/deepaknailwal/circuit-agent

Gemini Intelligence Is Not Just an AI Feature — It's a Platform Shift (And Developers Should Be Worried)

Deepak Nailwal — Tue, 19 May 2026 16:51:31 +0000

devchallenge,#googleiochallenge,#gemini,#android

The Announcement That Changed How I Think About Android Development

I've been building Android apps for 4 years. I've survived the transition from Java to Kotlin, from imperative UI to Jetpack Compose, from REST to GraphQL. But what Google announced at I/O 2026 feels different — and not entirely in a good way.

Gemini Intelligence is not a chatbot update. It's not a new API endpoint you can optionally call. Google is embedding Gemini directly into Android 17 at the OS layer — not inside a single app, but across the entire system.

The demo said it all: Gemini found a university syllabus in Gmail, identified required textbooks, and auto-added them to a shopping cart — across three different apps, with zero developer involvement.

Let that sink in.

What Actually Got Announced (The Technical Reality)

Here's what's real and shipping:

Gemini Intelligence on Android 17 — On-device agentic AI that works proactively across apps
Create My Widget — Users describe a widget in plain language; Gemini builds it on the fly
Gemini in Chrome (Android) — Summarization, cross-tab research, direct integration with Gmail + Calendar + Keep
Firebase Agent-Native Pivot — Firebase is repositioning as an agent-first backend platform
Android Studio Gemini Tooling — Deeper AI-assisted coding, not just autocomplete
Android XR Glasses — With Samsung, Warby Parker, Gentle Monster — live navigation, translation, in-lens display
Googlebooks — Chrome OS is dead. "Aluminum OS" (Android 17 desktop) is the future, launching via Acer, ASUS, Dell, HP, Lenovo this fall

My Honest Take: The Power — and the Problem

The Power

For users, this is genuinely impressive. The grocery list demo, the background spin class booking, the Gboard Rambler — these are real-life problems being solved at the OS level.

For developers, Firebase going "agent-native" is a big opportunity. If you're building apps that coordinate complex multi-step workflows, Firebase agents could eliminate a lot of boilerplate orchestration code you'd otherwise write yourself.

The Problem No One Is Talking About

When AI works across your app without you doing anything — who is responsible when it goes wrong?

Right now, Gemini can read your app's content and act on it as part of a larger cross-app flow. Your app didn't call any API. You didn't write any agent code. But Gemini is using your UI, your data, and representing actions to the user as if your app is involved.

As a developer, I have questions:

What are the data exposure boundaries?
What happens when Gemini misreads context from my app?
How do I opt out — or opt in — to being part of these agent flows?

Google's I/O sessions still don't have clear answers on Firebase agent pricing at scale or data guarantees for enterprise apps plugged into Gemini Intelligence. Until those answers arrive, shipping production apps that depend on this feels premature.

What I'm Actually Going to Try First

The Create My Widget API is my immediate next experiment. The idea of users describing their home screen widget in plain text and getting a working result is a UX paradigm shift — and if it exposes hooks for developers to define widget templates or constrain outputs, there's a real customization opportunity here.

I'm also watching the Flutter + Gemini session from May 20 closely, because the cross-platform implications of OS-layer AI on a Dart-compiled UI stack are... non-trivial.

The Bottom Line

Google I/O 2026 isn't saying "here's a cool AI tool for your app." It's saying "AI is now the OS, and your app lives inside it."

That's either the most exciting thing you've heard all year, or it's keeping you up at night. For me, it's both.

The platform is shifting beneath our feet — and as developers, the worst thing we can do is treat Gemini Intelligence as just another library to add to build.gradle.

What feature from I/O 2026 are you most excited — or most nervous — about? Drop it in the comments. 👇

Tags: #googleiochallenge #devchallenge #gemini #android

Business idea in this AI era ??

Deepak Nailwal — Thu, 05 Mar 2026 15:54:49 +0000

As we are living in this era of artificial intelligence and we are viewing that how ai is rapidly taking away most of jobs.
We had seen how Chat-gpt became a part of our daily life, we had seen how bots and agents became a part of profesionals life in the past years.

but now this year and nexts are the era of agentic ai which is more powerful than chatgpt ,claude ,gemini and many more chat bots.

so if we want that ai would not replace we have to work on agentic ai......