DEV Community: Vikas Sahani

Google Just Made MCP Enterprise-Grade at Cloud NEXT '26 - Here's What That Means for Android Developers

Vikas Sahani — Thu, 23 Apr 2026 08:02:48 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

Google Just Made MCP Enterprise-Grade at Cloud NEXT '26 — Here's What That Means for Android Developers Who Already Use It

Google Cloud NEXT '26 dropped one announcement that most developer write-ups buried under the TPU 8 headlines and the $750M partner fund:

Apigee MCP is now Generally Available.

Any standard API can now be exposed as a discoverable, governed MCP tool — no local server infrastructure required. Combined with ADK v1.0 stable and the A2A protocol hitting production at 150 organisations, Google has just made the Model Context Protocol a first-class enterprise primitive.

For Android developers, this is worth stopping to think about carefully — because the MCP ecosystem already exists at the community layer, and Google just validated the entire pattern from the top down.

I know this because I built AndroJack MCP — a community MCP server that gives AI coding assistants live, verified Android knowledge. Let me show you what Google's announcement actually changes, what it doesn't, and what the Android developer workflow looks like when both layers work together.

The Problem That Started Everything

Here's a number from the 2025 Stack Overflow Developer Survey that should make every Android dev uncomfortable:

35% of all Stack Overflow visits in 2025 were triggered by developers debugging AI-generated code.

Trust in AI coding tools collapsed from 40% to 29% in a single year — despite usage climbing to 84%.

The gap is structural. AI models predict tokens. They were trained on a snapshot of the world. They have no mechanism to know that Navigation 3 went stable in November 2025 after seven years of Nav2. They don't know that Android 16 mandates edge-to-edge enforcement, or that ContextualFlowRow was deprecated in Compose 1.8, or that ACCESS_LOCAL_NETWORK is now a required permission for any app targeting Android 17 API 37 that connects to local IPs.

The result is not bad code. It is confidently bad code. Code that compiles. Code that runs. Code that fails at Play Store review or corrupts your architecture before you notice.

This is the exact problem MCP was designed to solve — connecting AI to live, authoritative data sources rather than having models rely on frozen training snapshots.

What Google Announced at Cloud NEXT '26

The headlining story was the full rebrand: Vertex AI is now the Gemini Enterprise Agent Platform. But under that umbrella, three things matter specifically for the MCP conversation:

1. Apigee MCP — Generally Available

Google's API management platform, Apigee, can now transform any managed API into a discoverable MCP tool. No local MCP server. No custom infrastructure. Just an OpenAPI specification, and your entire enterprise API catalog becomes agent-accessible — with existing governance, security controls, and audit logs intact.

The practical meaning: a company can expose its internal HR APIs, its CRM data, its ERP endpoints — all as MCP tools — through a single managed gateway, and have AI agents consume them safely.

2. ADK v1.0 Stable — Across Four Languages

Google's Agent Development Kit hit v1.0 with stateful multi-step agent support, enhanced debugging tooling, and native Vertex AI Agent Engine integration. ADK now has native A2A protocol support built in — which means agents built with ADK can hand tasks off to agents built in LangGraph, CrewAI, or any other A2A-compatible framework without custom glue code.

3. A2A Protocol in Production at 150 Organisations

Agent-to-Agent communication — where a Salesforce agent can hand a task to a Google agent, which queries a ServiceNow agent, all without any of the three systems understanding each other's internal architecture — is no longer experimental. It is in production.

The Layer Distinction Nobody Is Talking About

Here is the thing Google's announcement does not change: domain-specific MCP tooling.

Apigee MCP solves the enterprise API connectivity problem. It is extraordinary at that. But it cannot tell your AI assistant that:

NavController.navigate(route: String) was removed in Navigation 3 and you need NavDisplay instead
The ACCESS_LOCAL_NETWORK permission is mandatory for Android 17 apps that connect to local IPs
TestCoroutineDispatcher was removed from coroutines-test 1.8+ and will silently break your CI
Material 3 Expressive components shipped at Google I/O 2025 with specific token requirements
The Compose BOM you're targeting has deprecated ContextualFlowRow and your code will break on the next BOM bump

No enterprise API catalog ships this knowledge. It lives in official Android documentation, in release notes, in migration guides — and it changes every month as Compose ships a new BOM, as Android versions progress through beta, as Google Play policy updates.

This is the layer AndroJack MCP operates at.

What AndroJack Actually Does — A Real Workflow

Let me make this concrete. Here is what happens when an Android developer asks Claude (or Cursor, or any MCP-compatible AI) to write a feature using Navigation 3 — without an Android-grounded MCP server:

Developer: "Add a bottom nav with three screens in my Compose app"

AI: Here's how to set it up with NavController and NavHost...

  val navController = rememberNavController()
  NavHost(navController, startDestination = "home") {
    composable("home") { HomeScreen() }
    composable("search") { SearchScreen() }
    composable("profile") { ProfileScreen() }
  }

This code is architecturally dead. Navigation 3 replaced this pattern entirely. The back stack is now a plain Kotlin list. NavDisplay replaces NavController. An Atomic Robot case study documented two LLMs — Gemini and Claude, both with internet access — generating the wrong Navigation 3 API even when explicitly asked about it, because they defaulted to the Nav2 patterns that dominate their training data.

With AndroJack MCP active, the AI must call android_navigation3_guide before generating any navigation code. It retrieves the live Navigation 3 documentation and generates:

// Navigation 3 — correct pattern (stable since Nov 2025)
@Composable
fun AppNavigation() {
  val backStack = rememberNavBackStack(Home)

  NavDisplay(
    backStack = backStack,
    entryDecorators = listOf(
      rememberSceneSetupNavEntryDecorator()
    )
  ) { entry ->
    when (entry.key) {
      is Home -> HomeScreen()
      is Search -> SearchScreen()
      is Profile -> ProfileScreen()
    }
  }
}

That is not a style difference. It is the difference between an app that builds correctly today and one that requires an architectural rewrite.

The Android 17 / API 37 Case — Where This Gets Critical Right Now

This is the most time-sensitive thing in this article. Android 17 reached platform stability (Beta 3) on March 26, 2026. The API surface is locked. Developers need to finalize compatibility testing now.

AndroJack v1.7.0 ships android17-compliance.ts — a dedicated tool that covers the breaking changes most AI tools don't know exist yet:

Breaking Change 1: Static Final Field Reflection

// ❌ BREAKS on Android 17 — code AI still generates
val field = MyClass::class.java.getDeclaredField("CONSTANT")
field.isAccessible = true
field.set(null, "new_value") // IllegalAccessException on API 37+

// ✅ What AndroJack guides the AI to generate instead
class MyViewModel(
  private val config: String = BuildConfig.API_URL // injected, not reflected
) : ViewModel()

Breaking Change 2: ACCESS_LOCAL_NETWORK

// ❌ Missing permission — silent failure on Android 17 for LAN apps

// ✅ AndroidManifest.xml — now required for API 37+ LAN access
<uses-permission android:name="android.permission.ACCESS_LOCAL_NETWORK" />

// ✅ Runtime check before local network operations
if (Build.VERSION.SDK_INT >= 37) {
  val granted = ContextCompat.checkSelfPermission(
    context, "android.permission.ACCESS_LOCAL_NETWORK"
  ) == PackageManager.PERMISSION_GRANTED
  if (!granted) {
    launcher.launch("android.permission.ACCESS_LOCAL_NETWORK")
    return
  }
}

Breaking Change 3: SMS OTP — 3-Hour Delay

Apps targeting Android 17 will experience a mandatory 3-hour delay in programmatic SMS OTP reading. Any fintech or auth flow that relied on instant OTP reading needs to be redesigned before targeting API 37.

None of these are in any LLM's training data. Android 17 is too recent. AndroJack's validator catches violations in generated code and returns structured reports with exact line references and fixes before the AI returns code to the developer.

The On-Device AI Angle — Where Google's Cloud NEXT Announcement Directly Connects

Here is where Cloud NEXT '26 and AndroJack converge on something genuinely new.

Google's announcements this week pushed hard on the Gemini Enterprise Agent Platform as the cloud-side layer for agentic AI. But Android has been building the device-side layer simultaneously. Android 16 shipped AICore — a system-level service that manages on-device LLMs. ML Kit Gen AI API lets apps access Gemini Nano through a standard interface.

The architectural pattern that emerges when you combine both:

// Domain layer — the AI assistant doesn't know if this is on-device or cloud
interface AiTextRepository {
  suspend fun summarize(text: String): Result<String>
  fun isAvailable(): Flow<Boolean>
}

// On-device implementation — Gemini Nano via AICore (zero latency, offline, free)
class OnDeviceAiRepository(
  private val generativeModel: GenerativeModel
) : AiTextRepository {
  override suspend fun summarize(text: String): Result<String> = runCatching {
    val response = generativeModel.generateContent("Summarize: $text")
    response.text ?: throw IllegalStateException("No response from on-device model")
  }
  override fun isAvailable(): Flow<Boolean> = flow {
    emit(GenerativeModel.isAvailable())
  }
}

// Cloud fallback — Firebase Vertex AI (Gemini Enterprise layer)
class CloudAiRepository(
  private val vertexAi: FirebaseVertexAI
) : AiTextRepository {
  override suspend fun summarize(text: String): Result<String> = runCatching {
    val model = vertexAi.generativeModel("gemini-3-flash")
    val response = model.generateContent("Summarize: $text")
    response.text ?: throw IllegalStateException("No response from cloud model")
  }
  override fun isAvailable(): Flow<Boolean> = flowOf(true)
}

// Factory — selects the right backend at runtime
class AiRepositoryFactory @Inject constructor(
  @ApplicationContext private val context: Context,
  private val cloudRepository: CloudAiRepository
) {
  suspend fun create(): AiTextRepository {
    return if (GenerativeModel.isAvailable(context)) {
      OnDeviceAiRepository(GenerativeModel.getInstance(context))
    } else {
      cloudRepository // Graceful fallback to Gemini Enterprise cloud
    }
  }
}

This pattern — repository interface, on-device primary, cloud fallback — is what AndroJack's android_on_device_ai_guide tool surfaces for every developer asking how to add AI to their Android app. The on-device layer gives you zero latency, full privacy, zero API cost. The cloud layer (now powered by Google's Gemini Enterprise Agent Platform announced at Cloud NEXT '26) gives you capability overflow for complex tasks.

An AI assistant without AndroJack would generate a direct Vertex AI call and skip the on-device option entirely — missing a major architecture decision. With AndroJack, the AI is grounded in the full picture.

The Bigger Picture: Community MCP and Enterprise MCP Are Not Competing

This is the genuine insight from Cloud NEXT '26 for anyone building in the MCP ecosystem.

Google's managed MCP via Apigee solves breadth — giving enterprise agents access to any API with governance at scale. Community-built MCP servers like AndroJack solve depth — giving AI assistants expert-level, domain-specific knowledge that no API catalog will ever codify.

They operate at different layers of the same stack:

┌─────────────────────────────────────────────────────┐
│              Your AI Coding Assistant               │
├─────────────────────────────────────────────────────┤
│  Community MCP Layer (Domain Depth)                 │
│  └── AndroJack: 22 tools, 31 rules                 │
│      Navigation 3 · Compose BOM · Android 17        │
│      ML Kit · Wear OS · XR · Play Policy            │
├─────────────────────────────────────────────────────┤
│  Enterprise MCP Layer (API Breadth)                 │
│  └── Apigee MCP GA (Cloud NEXT '26)                │
│      Internal APIs · CRM · HR · ERP data           │
├─────────────────────────────────────────────────────┤
│  Agent Orchestration                                │
│  └── A2A Protocol + ADK v1.0 (Cloud NEXT '26)      │
└─────────────────────────────────────────────────────┘

The A2A protocol announcement makes this even more interesting. When agents can hand off tasks to each other, a coding agent grounded by AndroJack (community MCP) could hand a documentation or data lookup task to a Google-managed agent running on Apigee (enterprise MCP) — and neither needs to understand the other's internal structure.

That is not science fiction. It is the architecture Google described as live in production this week at Cloud NEXT '26.

How to Get Started With Both Layers Today

Install AndroJack MCP in 30 Seconds

# In Claude Desktop, Cursor, VS Code, or Windsurf
npx -y androjack-mcp@1.7.1

Or one-click install from the README.

What you get immediately:

22 Android-specific tools across Kotlin, Compose, Navigation 3, Gradle, ML Kit, Wear OS, XR, Play Policy
31 validation rules that check AI-generated code before it reaches you
Android 17 / API 37 compliance checker (new in v1.7.0) — relevant right now for compatibility testing
Level 3 loop-back validation: AI generates code → validator checks it → AI fixes violations → you get clean code

Connect to Google's Managed MCP (via Vertex AI Agent Builder)

Google's Cloud Console now lets you connect Apigee-managed MCP endpoints directly to agents in Vertex AI Agent Builder. If your team has internal APIs that Android code needs to interact with — analytics endpoints, content APIs, internal feature flag services — this is the path.

What I'm Building Next — and Why Cloud NEXT '26 Accelerates It

AndroJack is currently on npm, VS Code Marketplace, MCP Registry (io.github.VIKAS9793/androjack), and the Anthropic Connectors Directory. The next phase is deeper integration with the Google Antigravity IDE — which AndroJack already supports via config — and exploring what an A2A-aware Android coding agent looks like when AndroJack's domain tooling is one node in a larger agent graph.

The ADK v1.0 stable release from Cloud NEXT '26 makes that significantly more tractable. Stateful multi-step agent support and native A2A — that's the substrate for a coding workflow where:

An orchestrator agent receives a feature request
It hands the Android-specific parts to a coding agent grounded by AndroJack
The coding agent validates its output via AndroJack's Level 3 loop-back validator
It hands the infrastructure/API parts to a Gemini Enterprise agent with Apigee MCP access
A2A coordinates the handoff without custom integration code

That is the workflow that makes AI coding assistants actually trustworthy for professional Android development.

The Takeaway

Google Cloud NEXT '26 did not just ship enterprise features. It validated the architectural pattern that the MCP community has been building from the bottom up for the past year.

Managed MCP (Apigee) + Community MCP (AndroJack and others) + A2A orchestration (ADK v1.0) = a complete stack where AI coding agents are grounded in both enterprise data and domain expertise simultaneously.

For Android developers: you do not have to wait for this stack to exist. The community layer is live today. Install AndroJack, and your AI assistant immediately knows about Android 17, Navigation 3, the Compose BOM, on-device AI with Gemini Nano, Play Store policy, Wear OS and XR — grounded in official documentation, not training data frozen six months ago.

The managed enterprise layer that Cloud NEXT '26 delivered is the piece that makes this viable at org scale.

Both matter. Both are now real.

AndroJack MCP is open source on GitHub: github.com/VIKAS9793/AndroJack-mcp

Install: npx -y androjack-mcp@1.7.1

Works with: Claude Desktop · Cursor · VS Code · Windsurf · JetBrains · Google Antigravity · AWS Kiro

Google Stitch 2.0: Senior-Level UI in Seconds, But Editing Still Breaks

Vikas Sahani — Wed, 22 Apr 2026 14:25:13 +0000

Google Stitch 2.0 can generate production-quality UI in seconds.

But the moment you try to refine a single component, the system starts to break.

This post is a hands-on evaluation of Stitch while building a real product flow, focusing on where it excels and where it fails under practical usage.

TL;DR

UI generation quality is exceptionally high (near senior-level output)
Iteration speed with Gemini 3 Flash is extremely fast
DESIGN.md improves consistency across outputs
Component-level editing is unreliable
Agent can become unresponsive with no feedback

Conclusion: Strong for generation, weak for controlled refinement

Demo Video

Context

This evaluation was done while building a real product flow for an AI-powered agriculture application.

The workflow included:

Prompt → UI generation
Multi-screen navigation
Component-level edits using "Edit with AI"
Export pipeline testing

What Works Well

High-quality UI generation

Using Gemini 3.1 Pro ("Thinking" mode), Stitch produces layouts with:

Strong visual hierarchy
Clean spacing and alignment
Coherent component structuring

The output often matches what a mid-to-senior designer would produce as a first iteration.

Fast iteration loop

With Gemini 3 Flash:

Multiple UI variations are generated within seconds
Exploration cost is significantly reduced

This compresses early-stage design cycles into a single interaction loop.

Accurate instruction-to-design translation

Compared to earlier versions:

Prompts are interpreted more consistently
Layout intent is preserved
Component grouping is largely correct

DESIGN.md improves consistency

Defining design rules such as:

Colors
Typography
Component constraints

results in more consistent outputs across iterations.

Export layer is well structured

Available outputs include:

AI Studio
Figma
Code export

This creates a clear bridge between design and implementation.

Where It Breaks

Case Study: Scan Button Component

While refining a floating "Scan Crop" button, the following behavior was observed.

Intended behavior

Default state: circular icon button
First interaction: expands into pill with "Scan" label
Second interaction: triggers scan action

Step 1: Edit with AI

Result:

Button collapsed into circular form (expected)
Scan icon was removed (unexpected)

This resulted in a visually ambiguous control with no clear affordance.

Step 2: Targeted correction

Instruction:

"Add scan icon while keeping all other properties unchanged"

Result:

No visible update
No feedback
No error signal

Step 3: Repeated attempts

Same instruction issued multiple times
No change observed

Outcome

Edit pipeline became unresponsive
Component could not be refined further
Required abandoning the edit flow

Analysis

This behavior indicates a system-level limitation rather than a simple generation error.

Weak component-level editing

The system struggles with scoped modifications such as:

Modify one attribute while preserving structure

Lack of deterministic control

Edits are:

Non-reliable
Not precisely applied

Agent state inconsistency

The system appears unable to:

Maintain prior edit context
Apply incremental changes

Silent failure

There is no:

Error feedback
Retry mechanism
Recovery guidance

The system simply stops responding.

Why This Matters

This directly impacts practical usability:

Reduces trust in iterative refinement
Forces regeneration instead of controlled editing
Slows down later-stage prototyping

Stitch is strong in generation, but unreliable in refinement.

Missing Capabilities

For production-level workflows, the following are required:

Deterministic edit mode

Apply scoped, predictable changes.

Component locking

Preserve structure while editing specific attributes.

Feedback system

Provide clear signals when edits fail.

Visual diff

Show before and after changes.

Retry mechanism

Automatically handle failed edits.

Strategic Observation

Stitch 2.0 has largely solved the generation problem.

The remaining challenge is control.

Final Assessment

Strengths:

High-quality UI generation
Fast iteration
Strong direction toward AI-native design workflows

Limitations:

Fragile editing
Lack of deterministic control
Agent reliability issues

Conclusion

Stitch is already a highly capable prototyping system.

However, until component-level editing becomes reliable, it cannot replace traditional design workflows for production use.

For now:

Use it for rapid generation
Avoid relying on it for precise refinement

I Analyzed 3 Months of Google Antigravity IDE Failures - Here's What's Actually Breaking

Vikas Sahani — Sat, 11 Apr 2026 12:22:05 +0000

A personal story, data-backed research, and a product proposal for workflow continuity in agentic AI IDEs.

I want to start with what impressed me — because I was genuinely impressed.

When I first started using Google Antigravity IDE, I kept stopping mid-session just to watch it work.

The agent would read my codebase, build a mental model of the architecture, open the browser, verify UI behavior, and iterate on failures — all without me typing a single line of code. Gemini 3.1 Pro handling a cross-file dependency refactor that would have taken me the better part of an afternoon. In fifteen minutes. Autonomously.

The underlying models are legitimately exceptional. The benchmark numbers aren't marketing — the reasoning quality in actual use reflects them.

I was hooked. I started using Antigravity for real work.

That's when I started hitting walls.

The First Wall

About 40 minutes into a complex debugging session, mid-agent-execution:

Agent terminated due to error.

No warning. No checkpoint. Files left in a partially edited, non-compiling state.

Then the popup: 167-hour lockout. Seven days.

I dug into what happened. The agent had entered an error-correction loop — retrying a failing verification step repeatedly — and burned through the Weekly Baseline Cap before I'd realized anything was wrong.

I started reading community forums to understand if this was just me.

It wasn't.

What the Community Data Shows

Across Google AI Developer Forum threads, r/GoogleAntigravityIDE, r/google_antigravity, and developer blogs, a clear pattern emerged.

I aggregated these into proxy metrics (these are directional estimates from community discourse, not official telemetry):

Metric	Estimated Range	What It Means
Task Completion Rate (TCR)	45–52%	Most agentic workflows fail before completion
Quota Interruption Rate (QIR)	68–75%	Majority of deep sessions end in forced termination
User Intervention Rate (UIR)	82–88%	True autonomy is rarely sustained
Workaround Adoption Rate (WAR)	35–42%	Users built their own continuity systems

The benchmark capability of the models: ~80% on SWE-bench Verified.
The real-world Task Completion Rate in the IDE: ~48%.

That ~32% gap is the product problem.

The 7 System Failures Behind the Gap

After mapping the failure patterns, I identified seven root causes — and they compound:

1. Mid-Workflow Termination

The quota enforcement is a binary hard cutoff. No warning threshold. No graceful wind-down. No checkpoint. When the limit is reached, execution stops immediately, leaving files in broken states.

2. Cross-Model Contagion

All models share a single quota pool. Exhausting Claude Opus (via a planning loop) instantly removes access to Gemini Flash — even for trivial, low-cost operations. A localized problem becomes a total platform outage.

3. No Predictive Awareness

The system doesn't estimate task cost before execution. The first signal of a problem is the hard stop — after the damage is done.

4. No Session State Continuity

When interrupted, all accumulated agent context is lost. Recovery requires full codebase re-ingestion, which itself costs quota. You burn resources recovering from the problem that burned your resources.

5. Thinking Token Opacity

Advanced models generate thousands of internal "thinking" tokens as part of their reasoning process. These consume quota at full rate but are invisible in the UI. Opus can burn quota ~4x faster than Gemini models. Users discover this only after the lockout.

6. UI / Backend State Desync

The interface shows quota available. The backend is already blocking execution. The trust contract between the UI and the system is broken.

7. Infinite Agent Loops

The Reason-Act-Verify loop has no failure threshold. An unresolvable error triggers infinite retries that can burn the entire weekly baseline cap in minutes. This is the most common trigger for the 167-hour lockout.

The Most Telling Signal: What Users Are Doing to Survive

The behavioral adaptations I found in the community are the most valuable product insight in this entire analysis.

Manual model routing: Users independently discovered the Opus-for-planning, Flash-for-execution pattern. They're doing this manually, 3–4 times per session.

Quota self-rationing: Power users stop work voluntarily at ~40% usage to preserve enough quota for the rest of the week.

.antigravityignore files: Users manually exclude node_modules, dist, build, .next from indexing because background indexing burns quota on every file save — before any intentional work begins.

Manual context handoff: Using /handoff commands and third-party mcp-shared-memory extensions to dump agent context to plain text files just to survive crashes.

When 35–42% of power users are building their own continuity systems, the product is failing to deliver on its core value proposition.

Every workaround is a user-validated product requirement.

The Proposal: Continuity Engine

I drafted a system-level product proposal to address this. Not a collection of feature patches — a single missing layer that manages the space between hard compute limits and user workflow expectations.

Feature 1: Intelligent Task-Based Model Routing

Auto-assign models based on task complexity. Users are already doing this manually — productize it.

Localized edit / regex / formatting → Gemini Flash
Single-file refactor / unit tests   → Claude Sonnet  
Architecture / cross-file analysis  → Gemini Pro
Complex debugging / root cause      → Claude Opus

Show the routing decision transparently. Allow instant override.

Feature 2: Quota-Aware Predictive Execution (Pre-Flight Checks)

Before the agent touches the filesystem, estimate token cost. Compare against remaining sprint quota and weekly cap.

Cost within budget → proceed silently
Cost at 70–90% of remaining → warn, offer task splitting
Cost exceeds remaining → hard stop with alternatives, not silent failure

Feature 3: Fiduciary Circuit Breakers

If the Verify phase fails 3 consecutive times: hard abort. Save state. Require human intervention.

Configurable: max_verify_failures, thought_token_ceiling, loop_detection_window.

This prevents the single most destructive failure mode — the infinite loop lockout.

Feature 4: Session State Continuity (Handoff)

Continuously serialize agent working memory to a compressed local artifact:

Active architectural decisions
Parsed file context (indexed, not verbatim)
Execution plan progress

On interruption: rehydrate from checkpoint into a new session. Target: 12% of original re-ingestion cost.

Feature 5: Decoupled Quota Pools

Separate quota buckets for High-Reasoning (Opus/Pro) and High-Velocity (Flash) models. Background indexing gets its own isolated pool.

Exhausting Pool A degrades capability — it doesn't trigger total lockout.

The Honest Trade-offs

I'm not going to pretend this is a complete fix.

Compute cost reality: The lockouts exist because inference at 1M tokens is extraordinarily expensive. Even at $200/month, unbounded agentic loops on premium models may be commercially unsustainable. The Continuity Engine works within limits — it doesn't remove them.

Hallucination cascade: Serialized session state compounds errors across sessions. A subtle wrong assumption in session 1 becomes unchallenged ground truth in session 5. Human review gates are mandatory.

Competitive defection: If daily friction of using Antigravity outweighs the benefit, the market migrates to Claude Code or Cursor. The Continuity Engine buys time — but doesn't fix the underlying trust damage from repeated lockouts.

Full Case Study

I've documented all of this in a public GitHub repository:

7 system failure mode analyses
Full user evidence taxonomy (sourced quotes from community)
Complete Continuity Engine specification (5 features, implementation priority, north star metric)
Honest risk and trade-off assessment

🔗 https://github.com/VIKAS9793/antigravity-continuity-engine

Have you hit quota walls in Antigravity? What patterns have you found? I'd especially like to hear from developers who've found effective strategies for sustained agentic work.

⚠️ Disclaimer: This is an independent product case study developed from personal usage of Google Antigravity IDE and analysis of publicly available community data. Not affiliated with, endorsed by, or representative of Google or any related organization. All metrics are proxy estimates derived from community discourse and are not official platform telemetry.

Author: Vikas Sahani | GitHub | LinkedIn | vikassahani17@gmail.com

I Built an MCP Server to Stop AI from Hallucinating Android Code — Here's What Happened

Vikas Sahani — Mon, 02 Mar 2026 15:51:20 +0000

description: "AI tools are fast. But in the Android ecosystem, fast + wrong = wasted hours. I built AndroJack MCP to force AI assistants to verify official docs before writing a single line of code."
tags: android, mcp, ai, kotlin
cover_image: https://androjack-web.netlify.app/og-image.png

canonical_url: https://androjack-web.netlify.app

Confidence is the most dangerous trait in an AI coding assistant.

It Started With a Healthcare App That Kept Breaking

While developing a complex, offline-first healthcare application, I found myself stuck in a relentless correction loop.

My AI assistants — Cursor, Claude, Windsurf — were exceptionally fast at generating code. But they were consistently generating the wrong code.

❌ Suggested Navigation 2 patterns for a Navigation 3 project
❌ Hallucinated Gradle coordinates that did not exist on Maven
❌ Used APIs removed from the Android platform years ago
❌ Generated AsyncTask — removed in API 33
❌ Generated TestCoroutineDispatcher — removed from coroutines-test 1.8+
❌ Generated ContextualFlowRow — deprecated in Compose 1.8
❌ Added android:screenOrientation="portrait" — illegal on ≥600dp under Android 16

Every session started with promise and ended with me on developer.android.com manually verifying what the AI should have checked itself.

This was not a failure of the models. It was a failure of grounding.

The Trust Crisis Is Real

I started researching the scale of this problem and found I wasn't alone.

The 2025 Stack Overflow Developer Survey (49,000 developers) confirmed a worrying trend:

84%  of developers use AI tools
29%  trust AI output accuracy  (down from 40% the year before)
35%  of Stack Overflow visits are now triggered by debugging AI-generated code

The structural flaw is simple: AI models predict tokens based on stale training data.

In the Android ecosystem — where Jetpack Compose, Navigation, and Material 3 evolve faster than model weights are retrained — memory is a liability, not an asset.

Passive prompts like agents.md or .cursorrules are not enough. They control how an AI responds. They cannot control what the AI actually knows.

What I Built: AndroJack MCP

I built AndroJack to bridge this gap.

It is an open-source Model Context Protocol (MCP) server that gives your AI assistant a live, physical connection to official Android and Kotlin documentation.

Instead of predicting from stale training memory, the AI is forced to fetch evidence before writing a single line.

VIKAS9793 / AndroJack-mcp

AndroJack: AI that actually knows Android. Real-time dependency tracking, modern architectures, and zero hallucinations.

AndroJack — The Jack of All Android Trades

An MCP server that equips your AI coding assistant with live, verified Android knowledge — so it builds from official sources, not from memory.

Also works with: Windsurf · VS Code Copilot · Google Antigravity · JetBrains AI — see Manual Config below ↓

VS Code distribution: Also live on the VS Code Marketplace as AndroJack MCP for VS Code.

PM / APM docs: Product strategy, JTBD, personas, roadmap, user stories, competitive analysis, and GTM materials live under product-management/README.md.

🔥 The Crisis That Created This Tool

In 2025, the Stack Overflow Developer Survey asked…

View on GitHub

🌐 Website → androjack-web.netlify.app
📦 npm → npmjs.com/package/androjack-mcp

See It in Action

How It Works: 21 Specialized Grounding Tools

AndroJack equips your AI assistant with a complete verification toolset:

Tool	Purpose
`android_official_search`	Live search across developer.android.com + kotlinlang.org
`gradle_dependency_checker`	Real-time version lookup from Google Maven + Maven Central
`android_component_status`	Is this API stable, deprecated, or removed?
`architecture_reference`	Official MVVM, UDF, modularization patterns
`android_api_level_check`	API availability by minSdk level
`kotlin_best_practices`	Idiomatic coroutines, Flow, Compose patterns
`material3_expressive`	Full M3 Expressive reference (GA on Android 16)
`android_navigation3_guide`	Navigation 3 (stable Nov 2025) — stops Nav2 hallucinations
`android_api36_compliance`	Android 16 / Play Store August 2026 mandate checker
`android_code_validator`	Loop-back gate — validates every code block before delivery
`android_kmp_guide`	Kotlin Multiplatform patterns
`android_wearos_guide`	Wear OS 5 + M3 Expressive for Wear
`android_xr_guide`	Android XR SDK (DP3, Dec 2025)
`android_ondevice_ai`	AICore + ML Kit Gen AI patterns
`android_large_screen_guide`	Adaptive layouts, WindowSizeClass, foldables
`android_testing_guide`	Unit, Compose UI, Hilt testing patterns
`android_build_and_publish`	R8, signing, Baseline Profiles, Play publishing
`android_scalability_guide`	Paging 3, offline-first, modularization
`android_permission_advisor`	Runtime permissions + ActivityResultContracts
`android_play_policy_advisor`	Play Store policy (October 2025 changes)
`android_debugger`	Stacktrace diagnosis grounded in official sources

The Grounding Gate: Two Levels of Enforcement

Level 1 — The Suggestion

Tools are available. The AI can use them when it feels uncertain.
Helpful, but still leaves room for overconfidence.

Level 2 — The Guarantee ⭐

Using the androjack_grounding_gate system prompt, you mandate a Verify-Before-Write loop. Every task type is mapped to a required tool call:

Before ANY Android or Kotlin code:

1. SEARCH      → android_official_search
2. VALIDATE    → android_component_status  (every API class)
3. ARCHITECTURE → architecture_reference
4. DEPENDENCIES → gradle_dependency_checker (every library)
5. API LEVEL   → android_api_level_check
6. PATTERNS    → kotlin_best_practices
7. DEBUG       → android_debugger          (for stacktraces)
8. VALIDATE OUTPUT → android_code_validator (every code block)

No code reaches the user without passing through the gate.

The Loop-Back Validator (Level 3)

android_code_validator is the final safety net — a 24-rule validation engine that inspects every code block before it reaches the user:

Verdict: PASS / WARN / FAIL

Catches:
❌ AsyncTask              → removed API 33
❌ TestCoroutineDispatcher → removed coroutines-test 1.8+
❌ ContextualFlowRow      → deprecated Compose 1.8
❌ GlobalScope.launch     → coroutine leak
❌ NavController in new code → use Navigation 3
❌ screenOrientation lock → illegal Android 16 / ≥600dp
❌ runBlocking on UI thread → ANR risk
❌ kapt in new code       → use ksp

If verdict is FAIL — the AI fixes all violations and re-runs before the user ever sees the output.

Get Started in 60 Seconds

Install into any MCP-capable IDE with a single command:

npx androjack-mcp@1.6.4 install

The interactive installer auto-detects your IDEs and writes the config:

✔ System scan complete.

IDE Detection Results:
◉  Claude Desktop     detected, not configured
◉  Cursor             detected, not configured
○  Windsurf           not found
◉  VS Code (Copilot)  detected, not configured
◉  Google Antigravity detected, not configured

◆  AndroJack MCP  Installer
◆  Select installation mode:
   ▸ Auto-install to all detected IDEs  [Recommended]
     Pick specific IDEs
     Show manual config snippet

Manual Config (if you prefer)

Claude Desktop / Cursor / Windsurf / JetBrains:

{
  "mcpServers": {
    "androjack": {
      "command": "npx",
      "args": ["-y", "androjack-mcp@1.6.4"]
    }
  }
}

VS Code (/.vscode/mcp.json):

{
  "servers": {
    "androjack": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "androjack-mcp@1.6.4"]
    }
  }
}

What's New in v1.6.4

This release addresses three areas discovered during the first real-world adoption wave:

🔴 CLI Routing Fix (Critical)

The install wizard was unreachable across all invocations — every subcommand fell through silently to the stdio server instead.

# All of these incorrectly started the server in v1.6.1:
npx androjack-mcp install
npx androjack-mcp --help
npx androjack-mcp --version

# All fixed in v1.6.4 ✅

Root cause: index.ts entry point never read process.argv before defaulting to server start. The install and serve handlers existed as separate entry points but were never routed to.

🟡 IDE Detection UX Improvement

Kiro and JetBrains/Android Studio now surface a clearer status when installed but MCP is not yet configured — instead of silently showing not found.

Before: AWS Kiro  not found
After:  AWS Kiro  detected (MCP not yet configured — launch IDE once to initialize)

🟢 Security Hardening

Updated @modelcontextprotocol/sdk to latest
Resolved all npm audit findings
Improved exception handling across tool handlers
Added input validation checks on all tool entry points
Improved dependency hygiene

Security score: 10.0 / 10.0 on MCP Marketplace scanner — zero known CVEs, verified package integrity.

Early Traction (First Launch Cycle)

AndroJack was distributed across four developer channels simultaneously:

📦 npm Registry          → 240 weekly downloads
🧩 VS Code Marketplace   → 59 installs
🔍 MCP Registries        → 115K+ discovery exposure
📊 Registry Ranking      → Top 300 MCP tools, upward movement

Conversion signal: The VS Code Marketplace showed a 163% conversion rate — meaning more installs happened directly from IDEs than from Marketplace page visits. This indicates community-driven word-of-mouth distribution, not search-driven discovery.

The Negative Constraints (What It Refuses to Generate)

One of the most useful features is what AndroJack prevents. These are hard prohibitions enforced at the system prompt level — the AI cannot generate these without explicit user override:

Universal (all targets):

AsyncTask — crashes on API 33+
TestCoroutineDispatcher — breaks CI on coroutines-test 1.8+
GlobalScope.launch / GlobalScope.async — coroutine leaks
ContextualFlowRow / ContextualFlowColumn — deprecated Compose 1.8
startActivityForResult() — use registerForActivityResult()
IntentService — deprecated API 30
runBlocking {} on UI/main thread — ANR

New Compose projects:

NavController / NavHost — use Navigation 3
MutableLiveData — use MutableStateFlow
kapt — use ksp

targetSdk ≥ 36 (Android 16 / Play Store August 2026 mandate):

android:screenOrientation="portrait" — illegal on ≥600dp
android:resizeableActivity="false" — illegal on ≥600dp

Why MCP Is the Right Architecture for This

MCP (Model Context Protocol) — open-sourced by Anthropic in late 2024 — gives AI assistants a standardized way to call external tools and retrieve live data during a conversation.

This is precisely what grounding requires:

Without MCP:
User prompt → Model predicts from training memory → Code output

With AndroJack MCP:
User prompt → Model calls android_official_search
           → Model calls gradle_dependency_checker
           → Model calls android_component_status
           → Model calls android_code_validator
           → Verified code output

The AI becomes an evidence-based engineer, not a pattern predictor.

What's Coming Next

v1.7.0 — Expanded IDE detection (process-level detection, not config-directory-only)
Community tool contributions — PR-based tool additions
HTTP transport mode — for team-shared MCP instances (already in serve subcommand)

Try It

npx androjack-mcp@1.6.4 install

🌐 androjack-web.netlify.app
💻 github.com/VIKAS9793/androjack-mcp
📦 npmjs.com/package/androjack-mcp

If you're an Android developer using AI-assisted workflows, I'd genuinely love your feedback — especially on which hallucinations you're hitting most often. Every real-world bug report shapes the next iteration.

"You are an evidence-based Android engineer, not a pattern predictor. Your value is not in knowing Android — it is in verifying Android before writing a line."

— AndroJack Grounding Gate system prompt

Exploring Google's Agentic Interoperability Stack: A Practical Guide

Vikas Sahani — Fri, 16 Jan 2026 15:04:46 +0000

Exploring Google's Agentic Interoperability Stack: A Practical Guide

What you'll learn: How Google's interconnected agent tooling components work together, what problems they solve, and what becomes possible when you combine them.

🎥 Watch the Visual Walkthrough

What Is This Stack?

Google has released several agent-related tools and protocols that, when combined, form an ecosystem-like experience for building AI agents:

ADK (Agent Development Kit) - Framework for building agents
Google MCP Servers - Connections to Google services
A2A (Agent-to-Agent Protocol) - How agents communicate
A2UI (Agent-to-UI) - How agents generate interfaces
UCP (Universal Commerce Protocol) - How agents handle commerce

Important: This isn't a single product called "Google Agentic Ecosystem." These are separate components that work well together.

The Core Problem

Before: Building an AI agent that could search flights, check loyalty points, and complete checkout required:

Custom integrations for each service
Manual UI coding for each interaction
No way to delegate tasks to other agents
Complex payment authorization flows

After: With this stack, agents can:

Use standardized connections (MCP)
Generate UIs declaratively (A2UI)
Delegate to specialized agents (A2A)
Handle commerce flows (UCP)

The Five Components Explained

1. ADK (Agent Development Kit)

What it does: Provides the foundation for building multi-agent systems.

Simple Example:

from google.adk import Agent

# Create a specialized agent
travel_agent = Agent(
    name="TravelPlanner",
    model="gemini-2.5-flash",
    tools=[search_flights, book_hotels],
    instruction="Help users plan trips efficiently."
)

What becomes possible:

Build agents that orchestrate multiple sub-agents
Manage conversation state across interactions
Integrate with external tools and APIs
Handle errors and fallbacks gracefully

📚 Learn more about ADK

2. Google MCP Servers

What it does: Provides standardized connections to Google services using the Model Context Protocol (MCP).

Available Connections:

Google Maps (geocoding, directions, places)
BigQuery (data analysis)
Google Cloud Engine (VM management)
Firebase (real-time database)
Analytics (metrics, reporting)
...and many more

Key Insight: MCP is an open standard created by Anthropic. Google provides official server implementations, so agents can connect to Google services using a standardized protocol.

What becomes possible:

Agents can discover and use Google services automatically
No need to write custom API integrations
Works with any MCP-compatible agent framework

📚 Learn more about Google MCP Servers

3. A2A (Agent-to-Agent Protocol)

What it does: Enables agents from different vendors to communicate and delegate tasks.

Example Flow:

Travel Agent → (A2A) → Loyalty Agent → (A2A) → Payment Agent

What becomes possible:

A Google-built agent can delegate to a Microsoft-built agent
Agents can discover each other's capabilities
Tasks can be delegated with full context
Security is built-in (OAuth, IAM)

Real-World Scenario: Your travel agent (built with ADK) can delegate loyalty point checking to your company's existing Salesforce agent, without you having to rebuild that functionality.

📚 Learn more about A2A

4. A2UI (Agent-to-UI)

What it does: Lets agents generate native UIs declaratively instead of just returning text.

Before (text-only):

Agent: "I found 3 flights. Option 1: $450, Delta, 5h 30m..."

After (interactive UI):

{
  "type": "comparison_table",
  "columns": ["Airline", "Price", "Duration"],
  "rows": [
    {"airline": "Delta", "price": "$450", "duration": "5h 30m"},
    {"airline": "United", "price": "$480", "duration": "5h 15m"}
  ],
  "actions": [{"label": "Book Now", "handler": "book_flight"}]
}

What becomes possible:

Agents can present complex data visually
Users can interact with results (sort, filter, select)
UIs work across platforms (web, mobile, desktop)

📚 Learn more about A2UI

5. UCP (Universal Commerce Protocol)

What it does: Provides standardized primitives for agent-driven commerce.

Core Capabilities:

Product discovery
Cart management
Checkout flows
Payment authorization (with cryptographic proof)

Compatible with: Shopify, Stripe, PayPal, Adyen, Mastercard

What becomes possible:

Agents can handle end-to-end shopping experiences
Users maintain control over payment authorization
Works across different payment providers

📚 Learn more about UCP

How They Connect

The Stack (Bottom to Top)

Observability Layer - Logging, monitoring, debugging
Trust & Policy Layer - IAM, OAuth, consent management
A2A Inter-Agent Layer - Cross-vendor agent communication
MCP Tool Layer - Service integrations (Google MCP Servers)
Orchestration Layer - Multi-agent coordination (ADK)
UI Layer - Native UI generation (A2UI)

Commerce flows (UCP) work across all layers.

Use Case 1: Consumer Shopping Assistant

The Scenario

User: "I want a coffee machine under $200"

How the Stack Enables This

Step 1: Orchestration (ADK)

Main agent understands intent
Breaks down into sub-tasks

Step 2: Product Search (MCP)

Connects to e-commerce APIs
Searches across multiple retailers

Step 3: Loyalty Check (A2A)

Delegates to user's loyalty agent
Retrieves available discounts

Step 4: UI Presentation (A2UI)

Generates comparison table
Shows products with prices and discounts

Step 5: Checkout (UCP)

Handles cart and payment
Applies loyalty rewards
Confirms purchase

What This Unlocks

For users: Complete shopping in one conversation
For developers: Build once, works across retailers
For businesses: Integrate with existing loyalty systems

📚 Full walkthrough

Use Case 2: Enterprise Workflow Automation

The Scenario

Automating expense approval across multiple systems (Workday, Stripe, email)

Traditional Approach

Employee submits in Workday
Manager gets email, logs into Workday
Finance processes in Stripe
Manual coordination between systems

With the Stack

# Employee submits
expense_agent.submit(amount=450, category="travel")

# HR Agent validates (via A2A → Workday)
hr_agent.validate_expense(expense_id)

# Manager Agent approves (via A2A)
manager_agent.approve(expense_id)

# Payment Agent processes (via A2A → Stripe)
payment_agent.process_payment(expense_id)

# Confirmation sent
notification_agent.send_confirmation(employee_id)

What This Unlocks

For employees: Submit once, automatic routing
For managers: Approve from any interface
For IT: No custom integrations between systems

📚 Full walkthrough

Use Case 3: Developer CI/CD Pipeline

The Scenario

Automating code review, security scanning, testing, and deployment

The Flow

Developer commits → GitHub
Code Review Agent analyzes (via MCP → GitHub API)
Security Agent scans (via A2A)
Test Agent runs tests
Deploy Agent deploys (via MCP → Cloud Run)
Monitoring Agent tracks performance

What This Unlocks

For developers: Faster feedback loops
For security teams: Automated vulnerability detection
For ops: Consistent deployment process

📚 Full walkthrough

Comparing Approaches

Feature	Google Stack	Anthropic MCP	OpenAI Swarm
Multi-agent orchestration	✅ ADK	❌ No framework	✅ Swarm (OpenAI-only)
Agent-to-agent protocol	✅ A2A (vendor-neutral)	❌ Not included	❌ Proprietary
Native UI generation	✅ A2UI (cross-platform)	❌ Text-only	✅ MCP Apps (web-only)
Commerce primitives	✅ UCP	❌ Not included	❌ Not included
MCP Server Ecosystem	✅ Official Google servers	✅ Created MCP standard	✅ Compatible
Open Governance	✅ A2A/UCP (Linux Foundation)	✅ MCP (Linux Foundation)	❌ Proprietary

Production Considerations

Before deploying agents, consider:

Trust & Security

How will users consent to agent actions?
What audit logging is needed?
How are tool permissions managed?
How is payment authorization secured?

Safety & Governance

How to prevent hallucinations?
What guardrails are needed?
How to handle agent errors?
When should humans intervene?

User Experience

What happens if agents fail?
How to monitor latency?
How to show agent reasoning?
What fallback UX is needed?

📚 Full readiness checklist

Deployment Options

1. Fully Managed (Google Cloud)

Best for: Startups, rapid prototyping
Pros: Zero infrastructure management
Cons: Vendor lock-in

2. Hybrid (Multi-Cloud)

Best for: Enterprises with existing cloud investments
Pros: Flexibility, vendor neutrality
Cons: Complex orchestration

3. On-Premises

Best for: Regulated industries (healthcare, finance)
Pros: Full data control
Cons: Higher operational overhead

📚 Reference architecture

Getting Started

1. Explore the Documentation

📚 Complete knowledge base

2. Try Official Quickstarts

3. Join the Community

Key Takeaways

For Product Managers

Understand what's possible with agent interoperability
Explore use cases relevant to your domain
Consider how agents could improve user workflows

For Engineers

Learn how components work together
Experiment with official quickstarts
Build prototypes to test feasibility

For Executives

Evaluate strategic fit for your organization
Understand open standards vs. proprietary approaches
Consider vendor neutrality benefits

Sources

All information is sourced from official documentation:

ADK: Google Developers Blog (April 2025)
Google MCP Servers: Google Cloud Blog (Dec 2024)
A2A: Linux Foundation (June 2025)
A2UI: Google Developers Blog (Dec 2025)
UCP: Google Developers Blog (Jan 2026)

Author & Disclaimer

Author: Vikas Sahani

GitHub: @VIKAS9793

Repository: google-agentic-interop-stack

Disclaimer

This is an independent educational/research project. All third-party names, trademarks, protocols, documentation, and referenced materials belong to their respective owners. This project is not affiliated with or endorsed by Google, Anthropic, or other referenced organizations.

Last Updated: January 16, 2026

License: MIT

💬 Discussion

What use cases are you most excited about? How might you use these components in your projects? Share your thoughts in the comments! 👇

Product Titans Runner-up: Agentic AI for Hyper-Personalized Learning

Vikas Sahani — Thu, 15 Jan 2026 14:19:25 +0000

Runner-up Case Study: Agentic AI Learning Platform for India

Overview

This project was created as part of Product Titans: National Product Management Challenge, hosted on Unstop and organized by Book My Mentor.

I approached this as a real-world PM discovery case and built an end-to-end product case study for a Hyper-Personalized Learning & Skill Development Platform powered by Agentic AI, aligned to the needs and constraints of India’s learning and skilling ecosystem.

Result: Certificate of Excellence – Runner-up (Rank 2, Score 6.4)

Solo Team Name: North Star Hunter

Problem Statement

In India, learners don’t always struggle due to a lack of content. They struggle because learning is often not aligned to:

their current gaps
their pace
their language preferences
their desired outcomes (exam performance, job readiness)

This results in:

low retention
repeated learning cycles without progress
dependence on parallel systems such as offline coaching/tutoring

So the real product problem is not:

"Build another course platform."

It is:

Help learners achieve outcomes faster with clarity, guidance, and accountability.

Product Sense: Why AI (and why Agentic AI)?

This project intentionally avoids “AI for hype.”

The core question was:
Do we actually need AI here?

The evaluation led to a practical conclusion:

personalization is not only content-level (recommendation)
it requires diagnosis, planning, feedback loops, accountability, and adaptation
this is where agentic workflows can reduce friction and improve learning outcomes

Who This Helps (Personas)

I mapped key learner segments to ensure the platform works for real India-first contexts:

Tier-2 / Tier-3 value learners with budget constraints and limited time
Exam aspirants needing structured planning and gap identification
Working professionals seeking upskilling with outcome clarity
D2C power learners looking for optimized learning paths and progress tracking

Key Insights (Friction Points)

I analyzed the full journey from discovery to outcomes and identified recurring friction:

learners don’t know what to learn next
lack of structured feedback loops
low motivation and inconsistent habits
weak accountability mechanisms
mismatch between course completion and real outcomes

Proposed Solution (High-Level)

An agentic AI-powered learning platform that supports:

Skill gap diagnosis
Personalized learning plan generation
Daily/weekly accountability tracking
Adaptive feedback and course corrections
Outcome-based progress measurement (not vanity metrics)

Prioritization Framework

I used RICE prioritization to avoid feature overload and focus on what moves outcomes:

Reach
Impact
Confidence
Effort

This helped separate:

root causes (diagnosis, clarity, feedback loops) from
surface-level fixes (more videos, more quizzes)

Success Metrics (North Star + KPIs)

I avoided vanity usage metrics and designed a measurable success model.

North Star Metric

Verified Learner Outcome Rate

Supporting Metrics

activation rate (first meaningful learning action)
habit formation / weekly consistency
completion quality (not completion volume)
diagnostic-to-outcome conversion
retention linked to goal attainment

Responsible AI: Risks and Controls

Because this product is agentic AI-driven, I documented risks and governance controls:

explainability and transparency of recommendations
bias and unfair personalization risk
privacy and data protection principles
safe completion boundaries and human override
accountability (who owns decisions and how errors are handled)

The goal was to ensure AI improves outcomes without creating unsafe or misleading personalization.

Output Artifacts

This project includes:

problem framing and market gap analysis (India-first)
persona mapping
user journey mapping
RICE prioritization
North Star metric + KPI tree
experiment design and GTM sequencing
responsible AI risk analysis + mitigations

Learnings

This project was a major learning experience that strengthened my practical PM skills:

problem framing before solution
structured prioritization
measurable outcomes and experiment-first thinking
responsible AI and governance as core product design constraints

Disclaimer

This is an independent case study created for learning and evaluation purposes as part of the Product Titans challenge. It is not affiliated with or endorsed by any employer or platform beyond the official competition context.

"Krishi Rakshak: Lightweight EfficientNet-Based Crop Disease Classifier"

Vikas Sahani — Mon, 09 Jun 2025 09:06:23 +0000

🚀 Sharing my end-to-end ML project: Krishi Rakshak — a crop disease classifier built with efficientnet_b0 for smallholder farmers.

⚙️ Model Highlights:

90%+ accuracy on PlantVillage (38 classes)

Trained with AdamW, scheduler, early stopping

Used weighted loss to handle class imbalance

📊 Evaluation:

Manual metric validation + confusion matrix

Precision, recall, F1, per-class accuracy

🧩 Deployment:

PyTorch + Gradio UI, multilingual support

Designed for light, modular inference

🔗 GitHub: https://github.com/VIKAS9793/KrishiRakshak.git
📹 Demo: https://drive.google.com/file/d/1PDxYq5rOuCXZAldZlSd6Q3M5WIGXEtbJ/view?usp=drivesdk

Built independently from scratch — feedback welcome from ML/AgriTech community on optimization or scaling for noisy field data.

CustomerAI – An Open Source Toolkit to Detect & Mitigate Bias in Enterprise AI Systems

Vikas Sahani — Tue, 06 May 2025 08:23:32 +0000

TL;DR:
CustomerAI is an open-source prototype designed to identify and reduce bias in ML systems—especially in sectors like finance, healthcare, HR, and retail. It's cloud-ready, model-agnostic, and aimed at real-world, regulatory-compliant AI deployment.

Why I Built This

Bias in AI isn't just a theoretical problem—it's a real threat when ML systems influence financial approvals, medical treatments, hiring decisions, or product visibility. Yet, tools for practical bias detection in these contexts are limited, fragmented, or difficult to integrate.

CustomerAI is my attempt to close that gap—an open-source, developer-friendly fairness toolkit built with speed, clarity, and real-world use in mind.

Key Features

Bias Detection + Mitigation: With metrics, checks, and correction strategies

Framework-agnostic: Use with TensorFlow, PyTorch, Databricks, SageMaker

Cloud-Deployable: Run it on AWS, GCP, Azure with minimal setup

Regulatory Awareness: Built around NIST AI RMF and EU AI Act principles

Built Fast: Developed with AI assistants and prompt engineering in weeks

Use Cases

Finance: Fairness in credit scoring and loan approval

Healthcare: Balanced treatment predictions for diverse populations

Retail: Equitable product recommendations and pricing models

HR Tech: Debiasing hiring and screening algorithms

Architecture Overview

Core Components:

Data Preprocessing & Bias Audits

Fairness Metrics (e.g., Demographic Parity, Equal Opportunity)

Mitigation Strategies (reweighting, post-processing)

Cloud Deployment (via Docker/K8s scripts)

Getting Started

git clone https://github.com/VIKAS9793/CustomerAI_Project.git
cd CustomerAI_Project
pip install -r requirements.txt
jupyter notebook

Check out the usage examples in examples/ for how to evaluate fairness in your own datasets.

Roadmap

[ ] Web-based UI for bias reports

[ ] More fairness metrics & mitigation algorithms

[ ] CI/CD for cloud deployment

[ ] Integrations with monitoring tools like MLflow

Call for Contributors

This is an early prototype, and I’m actively looking for:

Feedback from ML engineers and researchers

Contributors to improve functionality, metrics, and documentation

Ideas for turning this into a reusable SDK or web service

GitHub & Feedback

Repo:
https://github.com/VIKAS9793/CustomerAI_Project.git

Drop a star if you find it useful!
Open an issue if you spot bugs or have ideas.
Pull Requests are very welcome!

Let's Connect

I’m especially interested in connecting with folks working in AI fairness, ML governance, or compliance tech. Share your thoughts in the comments—or reach out on GitHub.