DEV Community: ABINJITH TK

Google I/O 2026: The Entire Stack Is Now Built for Agents — An Indie Dev's Honest Take

ABINJITH TK — Sun, 24 May 2026 12:33:26 +0000

93 Agents. One OS. Twelve Hours. Under $1,000.

I need to tell you something before we get into the announcements.

For months, I've been building an app — a kind of AI operating system where specialized agents each own a domain. A coding agent. A design agent. A research agent. Each one has real programming functions as its tools. They don't just answer questions — they do things. And the core idea? Put them in a shared space where they collaborate, challenge each other, and make better decisions together than any single agent could alone.

Then Google I/O 2026 happened.

I sat through the keynote, the developer keynote, the Firebase session, the Flutter session, the AI deep-dive — and kept seeing my own architecture reflected back at me. Multi-agent parallelism. Specialized sub-agents spawning on demand. Agents triggering backend functions. Agents building UI in real time.

It wasn't a "they stole my idea" moment. It was a "the entire industry is converging on this pattern" moment. And that's way more interesting. 😅

Let me walk you through what Google actually shipped, why it matters, and the one thing I think they're still missing.

Google Didn't Ship Features. They Shipped an Architecture.

Here's what most coverage will miss: the individual announcements aren't the story. The connection between them is.

Google rebuilt every layer of their platform around one assumption — agents are the new primary users of software infrastructure. Not humans clicking buttons. Agents making API calls, triggering functions, rendering UI, and executing transactions.

Once you see it, you can't unsee it.

The Foundation: Models That Execute, Not Just Respond

Three model drops. One common thread: they're built for doing.

Gemini Omni — a multimodal family that takes any input and produces any output. It understands physics. It edits video through conversation. It reasons about the real world spatially. The first variant, Omni Flash, shipped the same day.

Gemini 3.5 Flash — frontier-class, 4x faster than comparable models, aggressively cost-optimized. Why does speed matter this much? Because when an agent makes 200 API calls to complete one task, latency compounds. Fast and cheap isn't a nice-to-have. It's the difference between agents being viable and agents being a toy.

Gemma 4 — open-source under Apache 2, 100 million downloads in month one. Runs offline on mobile. Optimized for reasoning and agentic workflows. This is the model that keeps working when your connection drops.

And underneath all of it: 8th-gen TPUs split into dedicated training (TPU 8) and inference (TPU 8i) chips, deployed across a million+ units globally. They're not just building models for agents. They're building silicon for agents.

The Dev Layer: Anti-Gravity 2.0 Is Not an IDE

This is where I started taking notes furiously.

Google Anti-Gravity 2.0 isn't a code editor with AI bolted on. It's a standalone desktop application — a mission-control hub where multiple agents work on your project simultaneously.

One agent writes frontend code. Another generates design assets. A third reviews architecture decisions. They don't step on each other because the system manages git branching automatically.

The headline demo: 93 autonomous sub-agents built a functioning operating system in 12 hours for under $1,000 in API credits.

Let that sink in. Not $1,000 per agent. $1,000 total. For an OS. 💀

Now — is that OS production-ready? Almost certainly not. 🙃 But the economics are the point. The cost floor for complex software just dropped through the floor.

What makes Anti-Gravity genuinely different:

Dynamic sub-agents — your primary agent spawns temporary specialists (QA, data science, security audit) when it needs them, then dismisses them
Cron scheduling — agents on autopilot. Scan PRs every morning. Monitor cloud health hourly. Run regression tests at midnight.
Markdown orchestration — define multi-agent workflows in .md files. No pipeline code. No YAML hell.
Managed agents via API — one API call spins up an isolated agent with its own secure Linux sandbox
Enterprise mapping — connects directly to corporate Google Cloud projects under existing compliance

The Gemini CLI got folded into the Anti-Gravity CLI, so terminal-native developers get the same backend without leaving their workflow.

This is the pattern I've been building. Specialized agents, real tools, parallel execution. Seeing it at Google scale tells me the architecture works. 😳👍

The Backend: Firebase Now Serves Agents as First-Class Citizens

This one flew under the radar, but it might be the most important infrastructure shift for anyone building agent-powered apps.

Firebase is no longer just "a backend for mobile apps." It's now explicitly a backend for autonomous agents.

Agent-Triggered Cloud Functions — functions fire when an agent does something, not just when a human taps a button. Your agent completes a research task? That triggers a function to store results, notify the user, and queue the next step.

Delegated Authorization — Firebase Auth now handles agent identity. An AI acts on your behalf with explicit, scoped permissions. This is the plumbing that makes "hey Gemini, book me a flight" actually work without giving the agent your entire Google account.

Hybrid Inference — models run locally on-device (expanding to Gemma 4), falling back to cloud only when needed. This isn't just about cost. It's privacy architecture. Your personal data stays on your device unless it absolutely has to leave.

Security That Actually Thinks About Agents

Google shipped three security features that tell me they've thought hard about the attack surface:

Template-Only Mode — Firebase AI Logic only executes prompt templates stored on your server. If a malicious client tries to inject custom prompts? Ignored. Completely.

Authentication-Mode — every Gemini API call requires a valid Firebase token. No token, no execution. Period.

App Check Replay Protection — one-time tokens prevent attackers from replaying valid requests to drain your AI quota.

These aren't afterthoughts bolted on after a security review. They shipped alongside the agent features. That's a good sign.

The Frontend: UI That Builds Itself

Two threads here, both wild.

Flutter Agents

Agentic Hot Reload — AI coding agents can discover your running Flutter app, connect to it, and hot-reload changes as they write code. You watch your app transform in real time while the agent works.

GenUI + A2UI Protocol — instead of returning text, AI composes actual interactive Flutter widgets on the fly. They're exploring interpreted bytecode delivery — your app's UI evolves without an app store update.

Oh, and Flutter now powers the 2026 Toyota RAV4 infotainment system. Not a demo. Not a concept car. A mass-market production vehicle. That's a credibility milestone.

Canonical (the Ubuntu company) officially took over as lead maintainer for Flutter Desktop across Linux, Windows, and macOS. The "will Flutter desktop survive?" question is answered.

The Web Gets Agent-Aware

WebMCP — a proposed standard where websites declare tools and capabilities directly to browser-based agents. Think of it like robots.txt for the agent era. Instead of telling crawlers what to avoid, you tell agents what they can do.

Origin trials in Chrome 149. If this gets adoption, it rewrites how agents interact with the entire web.

Chrome DevTools for Agents — a new "Agentic Browsing" category in Lighthouse. Agents self-audit accessibility, validate discovery maps, catch errors, and deploy their own fixes. The browser becomes the agent's workspace.

The Consumer Layer: Agents in the Wild

Gemini Spark — a 24/7 personal agent running on dedicated cloud VMs. It works while you sleep. Close your laptop, the agent keeps going.

Agentic Commerce — three building blocks for agents that buy things:

Universal Commerce Protocol (UCP) — an open standard backed by Amazon, Meta, and Microsoft for agent-to-merchant communication
Agent Payments Protocol (AP2) — secure payment tracking with strict guardrails
Universal Cart — cross-merchant intelligence that catches compatibility errors (mismatched PC parts) and tracks price drops

Amazon and Microsoft signing onto UCP is the real signal. This isn't Google going solo. It's an industry bet.

Audio Glasses — launching Fall 2026 with Samsung, Qualcomm, Warby Parker, and Gentle Monster. Gemini whispers in your ear. Orders your coffee through DoorDash. No screen. No phone. Just voice. 👀✨

What I Think Is Still Missing (And Why It Matters)

Here's my genuine take — the part that goes beyond reporting.

Google showed agents working in parallel. That's powerful. But parallel isn't the same as collaborative.

What I mean: Anti-Gravity has one agent on frontend, another on design, another on architecture. They work simultaneously. Great. But are they talking to each other? Are they debating tradeoffs? Is the architecture agent pushing back when the frontend agent makes a decision that creates tech debt?

The pattern I keep coming back to — and the one I've been building toward — is agent deliberation. A group conversation where specialized agents don't just execute in their lane, but actively challenge each other.

Picture it: a coding agent proposes an implementation. A QA agent immediately flags three edge cases. A design agent says the UX flow doesn't work. An architecture agent weighs in on system-wide implications. They go back and forth. They converge on a decision that's better than any single agent would produce alone.

This isn't parallel execution. It's peer review at machine speed.

Google has all the pieces — the models are fast enough, the sandboxing works, the infrastructure scales. But the "agents arguing productively in a room" pattern? I haven't seen anyone ship that at scale yet.

I think that's the next frontier. And I think whoever cracks it — whether it's Google, an open-source project, or an indie dev working late at night 😢 — unlocks a step-change in output quality that parallel execution alone can't match.

The Honest Concerns

I'm excited. I'm not blind.

Lock-in is the business model. Anti-Gravity + Firebase + Gemini API + Cloud Run + TPUs. Once you build on this stack, leaving is expensive. Google knows exactly what they're doing. 🙂‍↔️

The 93-agent OS is a headline, not a benchmark. We don't know what "functioning" means. Can it handle edge cases? Run real applications? The economics are compelling, but the quality bar is undefined.

Agent commerce trust doesn't exist yet. People barely trust chatbots to summarize a Wikipedia article correctly. Handing them a credit card is a different conversation. 😬 UCP and AP2 are technically sound. Consumer trust is years behind the technology.

Security is necessary but not sufficient. Template-Only Mode is clever. But the attack surface of agents with autonomous backend access is enormous. What about prompt injection through data they process? What about agents that need dynamic prompting by design? The tension between capability and safety isn't resolved — it's just acknowledged.

So What Does This All Mean?

Google I/O 2026 told one story across six hours of content: agents are becoming the primary consumers of software infrastructure.

Every layer got rebuilt:

Models optimized for speed and tool use
Developer tools that treat agents as builders
Backends that authenticate and authorize agent actions
Frontends that declare capabilities to agents
Consumer products where agents act autonomously
Hardware that puts agents in your ear

As someone building multi-agent architecture independently, this week felt like validation. The patterns work. The economics are arriving. The infrastructure exists.

But the most interesting problem is still open: how do you get agents to think together, not just work side by side?

That's what I'm chasing. And after watching Google put the foundation in place, I'm more convinced than ever that collaborative agent reasoning — not just parallel execution — is where the real unlock lives.

The agentic era isn't coming. It showed up on May 19, 2026, wearing a Google badge. 🎫

Now the question is: what do we build on top of it?

Thuna (തുണ) — Offline AI Health Companion for Elderly, Powered by Gemma 4 E2B

ABINJITH TK — Sat, 23 May 2026 13:17:50 +0000

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

What I Built

Thuna (തുണ) is a voice-first AI health companion that runs 100% offline on Android, built for elderly people in rural India who can't read, can't type, and have no reliable internet.

My grandmother takes diabetes medication daily. One month, the pharmacy changed her tablet strength. She got confused and took double the dose for 30 days. She developed hypoglycemia. Nobody noticed until she started fainting.

My other grandmother has polio — she walks with a walker, lives with chronic pain, and can't access hospitals easily. She can't read English. She gets health advice from neighbors — often wrong, sometimes dangerous.

We live in Poothampara, a rural village in Kerala, India. Internet is limited and unreliable. These aren't edge cases — 240 million elderly people globally manage chronic conditions alone.

Thuna solves this with:

Voice-first Malayalam interaction — speak naturally, hear responses. No typing, no reading needed.
Medication safety — tracks exact dosages, detects 15 dangerous drug interactions, prevents overdoses with scheduled TTS reminders
Health monitoring — say "BP 140/90" or "ഷുഗർ 180" and it saves, tracks trends, alerts on danger
Prescription scanning — photograph a prescription, Gemma 4 vision extracts all medications
Companion personality — fights loneliness by talking about movies, cooking, family. Offers to call family members.
Family status sharing — one tap sends daily health update to family WhatsApp
Health report — structured summary for doctor/health worker visits
SOS emergency — one-tap call for help

Demo

APK Download: Google Drive

Code

AbinjithTK / Thuna

Offline AI Health Companion for the Elderly — Gemma 4 on-device via Cactus

Thuna (തുണ) — Your Health Companion

Offline AI health assistant for elderly people in remote areas, powered by Gemma 4 E2B on-device.

Quick Start

npm install
npx react-native run-android

Architecture

Voice/Text Input → IntentParser (deterministic) → AgentEngine (DB ops) → Gemma 4 E2B (response) → Malayalam TTS

IntentParser: Regex-based extraction for medications, vitals, conditions, lab results (100% reliable)
AgentEngine: Executes tools against WatermelonDB (save_vital, save_medication, schedule_reminder, etc.)
Gemma 4 E2B: Generates natural Malayalam responses only (not used for data extraction)
Cactus v1.7: On-device inference engine with zero-copy memory mapping

Tech Stack

Layer	Technology
LLM	Gemma 4 E2B INT4 via Cactus v1.7
STT	Cactus Whisper (Malayalam) + Android SpeechRecognizer
TTS	Android TextToSpeech (ml-IN)
Database	WatermelonDB + openEHR Flat JSON
Framework	React Native 0.82 (New Architecture)
Navigation	React Navigation 7 (tabs + stack)

Features

Voice-first Malayalam interaction
BP, sugar, SpO2, temperature, heart rate tracking with critical alerts
Medication…

View on GitHub

How I Used Gemma 4

Model: Gemma 4 E2B (2B effective parameters, INT4 quantization via Cactus v1.7)

Why E2B?

My grandmother's phone has 6GB RAM. The E2B INT4 model fits in ~1.5GB, runs inference in ~2 seconds, and works completely offline. In Poothampara, internet drops for hours. A cloud API would be useless. Gemma 4 E2B running on-device through Cactus means the app works every single time — no connectivity required.

What Gemma 4 does in Thuna:

Malayalam response generation — warm, conversational responses in the user's native language. The system prompt is entirely in Malayalam with explicit grammar rules and examples.
Multimodal prescription OCR — user photographs a prescription → Gemma 4 vision extracts medication names, dosages, frequencies → all saved with auto-reminders. One photo replaces 10 minutes of confused explanation.
Companion conversation — talks about anything (movies, cooking, memories). Detects loneliness and offers to call family. This is what makes it a companion, not just a health tool.
Context-aware responses — uses conversation history to give personalized, relevant answers.

What Gemma 4 does NOT do (intentionally):

Health data extraction (BP values, medication names, dosages) uses a deterministic regex parser — not the LLM. Why? My grandmother's overdose happened because of confusion. A regex will NEVER confuse "2mg twice daily" with "two 2mg tablets." For health-critical data, reliability beats flexibility. Gemma 4 handles the warmth; regex handles the precision.

Architecture:

Voice → Regex IntentParser (<1ms, 100% reliable) → AgentEngine (23 tools, DB ops) → Gemma 4 E2B (Malayalam response) → TTS

This hybrid approach gives us the best of both: instant reliable tool execution + warm natural conversation.

Technical highlights:

23 agent tools (save_vital, drug_interaction_check, schedule_reminder, prescription_ocr, compound_risk_alert, etc.)
WatermelonDB with openEHR standard for health records
Post-processing filter strips Hindi/Manglish from model output
In-app TTS reminder system that speaks Malayalam at scheduled times
Proactive health alerts (diabetes + high sugar + high BP = critical warning)
FHIR R4 cloud sync when internet is available (optional)

Built and tested with my actual grandmother in our village. When she said "ഷുഗർ ഗുളിക കഴിച്ചു" (took sugar tablet) and Thuna confirmed in Malayalam, she understood immediately. That's the moment I knew it worked.

Jems - Your life, brilliantly organized

ABINJITH TK — Sun, 29 Mar 2026 11:15:20 +0000

This is a submission for the Notion MCP Challenge

What I Built

Most AI assistants are a single chatbot trying to do everything. Jems flips that — it's a group chat of four specialist AI agents that collaborate in real time, and they use Notion as their shared workspace.

You send one message. All four agents see it, discuss it internally, and the most relevant one responds — like a WhatsApp group, except your friends are AI experts who never forget and always coordinate.

The agents:

🟢 Noor — The Orchestrator. Your main point of contact. Routes messages, synthesizes responses, handles real-time voice streaming. Reads your Notion workspace for context — meeting notes, project docs, personal wiki — to ground every response in your actual life.

🟡 Kai — The Planner. Owns your schedule, tasks, and reminders. When you say "plan my week," Kai creates structured task entries directly in your Notion Tasks database — with due dates, priorities, time estimates, and status tracking. Not a text dump — real, filterable, sortable database rows.

🩷 Sage — The Growth Coach. Tracks goals, monitors progress, nudges when things stall. Maintains a Goals dashboard in Notion with milestones, completion percentages, and weekly progress updates. Surfaces social briefings and peer accountability.

🟣 Echo — The Memory Keeper. Journals your thoughts, remembers what you said weeks ago, spots mood patterns. Creates rich Notion pages for journal entries with metadata tags — timestamps, mood indicators, topics — making your inner life searchable and reflective.

The magic is shared context. When Kai creates a task, Echo remembers it. When Sage updates a goal, Kai adjusts the plan. And all of it is visible as structured data in Notion — full transparency into how your AI team thinks and acts.

The Spatial UI

This isn't a chat app — it's an operating system. Five screens connected by a floating glassmorphism dock:

Route	Screen	Agent	What Happens in Notion
`/hub`	Command Hub	Noor	Reads Notion context for grounded responses
`/schedule`	Planner	Kai	Creates/updates tasks and reminders in Notion DBs
`/journal`	Infinite Board	Echo	Writes journal entries as rich Notion pages
`/lounge`	Social Room	Sage	Tracks goals and progress in Notion dashboards
`/ecosystem`	Connections	—	Manage Notion MCP connection with guided setup

Pure white aesthetic. Glassmorphism. 3D clay-style agent spheres with kawaii faces. No dark mode. No clutter. Just flow.

Architecture

┌──────────────────────────────────────────────────────────┐
│                    📱 Flutter App                         │
│          Spatial UI · Glassmorphism · 3D Spheres          │
│                                                           │
│   /hub      /schedule     /journal     /lounge            │
│   Noor       Kai           Echo         Sage              │
│                                                           │
│   /ecosystem → MCP Connections (Notion setup UI)          │
└────────────────────┬─────────────────────────────────────┘
                     │ WebSocket bidi-streaming
                     │ (real-time voice + text)
                     ▼
┌──────────────────────────────────────────────────────────┐
│               ☁️ FastAPI on Cloud Run                     │
│            Google ADK Multi-Agent Runtime                  │
│                                                           │
│   🟢 Noor ←→ 🟡 Kai ←→ 🩷 Sage ←→ 🟣 Echo              │
│          (Live Bidi Agent Loop — Group Chat)               │
│                                                           │
│   Gemini 2.5 Flash (voice) + Pro (reasoning + tools)      │
│                                                           │
│   Tools: Firestore · Google Search · MCP · A2A            │
│   Infra: Terraform · 7 Cloud Scheduler cron jobs          │
└────────────────────┬─────────────────────────────────────┘
                     │ MCP (Model Context Protocol)
                     ▼
┌──────────────────────────────────────────────────────────┐
│               📓 Notion Workspace                         │
│                                                           │
│   📋 Tasks DB       → Kai writes/reads/updates tasks      │
│   🎯 Goals DB       → Sage tracks milestones + progress   │
│   📔 Journal Pages  → Echo creates rich entries           │
│   📡 Agent Log      → All agents log their activity       │
│   📄 Context Pages  → Noor reads for grounded responses   │
└──────────────────────────────────────────────────────────┘

Tech Stack

Layer	Technology
Frontend	Flutter · Custom spatial design system · Glassmorphism · 3D agent spheres
Backend	FastAPI on Google Cloud Run · Google ADK multi-agent orchestration
AI Models	Gemini 2.5 Flash (voice + streaming) · Gemini 2.5 Pro (reasoning + tools)
Data	Firestore (users, tasks, goals, reminders, journal, messages, connections)
Storage	Google Cloud Storage (proof uploads, memory files)
Auth	Firebase Auth (JWT tokens) · Per-request ID token verification
Protocols	MCP (Notion + extensible tools) · A2A (agent-to-agent social) · WebSocket bidi-streaming
Infra	Terraform-managed · Artifact Registry · Secret Manager · 7 Cloud Scheduler cron jobs
Payments	RevenueCat (subscriptions)
Notion	Notion MCP Server — agents read/write databases and pages in real time

Video Demo

Demo flow:

User opens Jems → Noor greets with a morning briefing pulled from Notion context
User says "Plan my week around the marathon" → message enters the agent loop
Kai creates structured tasks in the Notion Tasks DB (visible in real time)
Echo logs a journal entry about the marathon goal as a Notion page
Sage checks goal alignment and updates the Goals dashboard in Notion
Noor synthesizes everything into one response — streamed live over WebSocket
User swipes to /ecosystem → Notion MCP connection shown as active with guided setup UI

Find the code and MVP apk here

AbinjithTK / Jems

The codebase spans three layers. Here's how they connect through Notion MCP:

1. Flutter App — MCP Connection Management

Users connect Notion from the Ecosystem screen (/ecosystem). The MCP connections page provides a native UI for managing servers, with Notion getting a dedicated guided setup flow:

// mcp_connections_page.dart — Notion-specific token setup
if (isNotion) ...[
  Container(
    padding: const EdgeInsets.all(12),
    decoration: BoxDecoration(
      color: SpatialColors.surfaceSubtle,
      borderRadius: BorderRadius.circular(12),
    ),
    child: Column(
      crossAxisAlignment: CrossAxisAlignment.start,
      children: [
        Text('Quick steps:'),
        Text(
          '1. Go to notion.so/profile/integrations\n'
          '2. Click "New integration"\n'
          '3. Give it a name and select a workspace\n'
          '4. Copy the Internal Integration Secret\n'
          '5. Share pages/databases with the integration',
        ),
      ],
    ),
  ),
],

The token is stored securely via the backend and immediately activates the Notion MCP toolset for all four agents:

// mcp_provider.dart — Token management
Future<bool> updateToken(String serverId, String token) async {
  await _api.post('/api/mcp/servers/$serverId/token', body: {'token': token});
  await load(); // Refresh server list — agents now have Notion access
  return true;
}

2. Backend — Agent Loop with MCP Tool Access

The backend runs on FastAPI with Google ADK orchestrating four Gemini-powered agents in a live bidi-streaming loop. Each agent has access to MCP tools — including Notion — through ADK's tool framework:

# Agent tool call flow (simplified)
# When Kai decides to create a task, it calls the Notion MCP tool:

# 1. User says "Plan my week"
# 2. Message enters the agent loop via WebSocket
# 3. Noor routes to Kai (scheduling topic detected)
# 4. Kai calls create_page via Notion MCP:

await mcp_client.call_tool(
    server="notion",
    tool="create_page",
    arguments={
        "parent": {"database_id": user_tasks_db_id},
        "properties": {
            "Name": {"title": [{"text": {"content": "Morning run — marathon prep"}}]},
            "Due Date": {"date": {"start": "2026-03-31"}},
            "Priority": {"select": {"name": "High"}},
            "Status": {"select": {"name": "Not started"}},
            "Agent": {"select": {"name": "Kai"}},
        }
    }
)

The WebSocket service streams responses token-by-token back to the Flutter app, with agent attribution so the UI knows which sphere to animate:

// ws_chat_service.dart — Real-time bidi streaming
case 'event':
  final text = msg['text'] as String?;
  final author = msg['author'] as String?;
  if (author != null && author.isNotEmpty) {
    _streamingAuthor = author; // UI animates the correct agent sphere
  }
  if (text != null && text.isNotEmpty) {
    _streamBuffer += text; // Token-by-token streaming
    notifyListeners();
  }

3. Infrastructure — Proactive Agents via Cloud Scheduler

Seven Terraform-managed cron jobs trigger agents to proactively read from and write to Notion — even when the user isn't in the app:

# deploy/main.tf — 7 proactive agent jobs
locals {
  scheduler_jobs = {
    morning_briefing     = { schedule = "0 7 * * *"   }  # Kai reads Notion tasks, briefs user
    evening_journal      = { schedule = "0 21 * * *"  }  # Echo writes daily journal to Notion
    reminder_check       = { schedule = "*/5 * * * *" }  # Check due reminders
    plan_review          = { schedule = "0 18 * * *"  }  # Sage reviews goals in Notion
    smart_suggestions    = { schedule = "0 10,15 * * *"}  # Proactive suggestions
    memory_consolidation = { schedule = "0 3 * * *"   }  # Echo consolidates memory patterns
    goal_nudge           = { schedule = "0 12 * * *"  }  # Sage nudges stalled goals
  }
}

This means your Notion workspace stays alive — agents update it on schedule, not just when you're chatting.

How I Used Notion MCP

Notion MCP isn't a bolt-on feature in Jems — it's the external workspace layer that makes the multi-agent architecture tangible. Here's exactly what it unlocks:

Agents write structured data, not text dumps

When you tell Jems "plan my week," the message enters the four-agent loop. Kai generates a plan and writes each task as a database row in your Notion Tasks DB — with typed properties for due date, priority, time estimate, status, and which agent created it. This is real structured data you can filter, sort, group, and view in Notion's native UI. It's not a markdown blob pasted into a page.

Agents read your workspace for context

When Noor needs to answer a question, it queries your Notion workspace via MCP — searching pages, reading database entries, pulling context from your meeting notes, project docs, or personal wiki. Your Notion workspace becomes a knowledge base that makes every agent response smarter and more grounded in your actual life.

Bidirectional — changes flow both ways

Update a task status in Notion? The agents see it next time they check. Agents create a journal entry? It appears as a rich Notion page you can edit, share, or embed anywhere. Notion isn't a write-only destination — it's a living collaboration surface between you and your AI team.

Multi-agent coordination is visible in Notion

This is the most powerful pattern. When you say "I've been stressed about the marathon":

Kai checks your training schedule in the Notion Tasks DB
Sage reviews your fitness goal progress in the Goals DB
Echo recalls that journal entry about knee pain from last week
Noor synthesizes it all into one thoughtful response

Each agent's contribution is logged in Notion — you can see exactly what your AI team considered, what tools they called, and what data they used. Full transparency.

Proactive agents keep Notion alive

The 7 Cloud Scheduler cron jobs mean agents don't wait for you to open the app. Every morning, Kai reads your Notion tasks and prepares a briefing. Every evening, Echo writes a journal summary. Every noon, Sage checks if your goals are stalling. Your Notion workspace evolves on its own — like having a team that works while you sleep.

MCP as a first-class, user-facing feature

In the Ecosystem screen (/ecosystem), users manage their MCP connections with a native Flutter UI. Notion has a dedicated setup flow with step-by-step instructions for creating an integration and sharing pages. Add your token, and all four agents immediately gain workspace access. The MCP protocol means this isn't a hardcoded Notion integration — it's a standard that works with any MCP-compatible server. Users can add GitHub, Calendar, or any other MCP server the same way.

What this creates

The combination of multi-agent AI + Notion MCP + proactive scheduling creates something that doesn't exist yet: an AI operating system that lives inside your real workspace. Your agents don't operate in a silo — they operate in Notion, alongside your real documents, real projects, and real life. You get the intelligence of four specialist AIs with the transparency and control of Notion.

That's not a chatbot. That's a team.

We built an OS for your life — and it actually gets you.

ABINJITH TK — Mon, 16 Mar 2026 21:17:10 +0000

You don't need another to-do app. You don't need another journal you'll abandon in two weeks. And you definitely don't need another "AI assistant" that forgets who you are every time you close the tab.

We built Jumns because we were tired of duct-taping 14 apps together just to keep our lives on track.

So what is it?

Jumns is a personal AI operating system. Four AI agents — we call them jems — that actually know your life. Your goals, your habits, your patterns. You talk to them like you'd talk to a friend, and they handle the rest.

🟢 Noor is your main jem. She lives in the Hub — a group chat where you just say what's on your mind. "I need to get back in shape and stop forgetting to call my mom." You don't pick who to talk to. Noor figures out the intent and routes it.

🟡 Kai is the planner. He takes that message and builds your gym blocks, sets a weekly "Call Mom" reminder, and lays out your week — not as a boring list, but as actual time-blocked priorities. Some tasks even ask for proof. A gym selfie. A check-in. Not because we're your boss — because three months from now, you'll want the receipts.

🟣 Echo is the journal jem. Everything you do quietly becomes your journal. Voice notes, photos, random 2am thoughts, sticky notes. Echo organizes it all into a beautiful masonry grid without you lifting a finger. No tagging. No sorting. It just happens.

🩷 Sage handles your social layer. Not a feed. Not a scroll trap. Just summarized updates from the people you actually care about — pulled from what they've chosen to share from their own journals. Tap in, see specifics, or just ask Sage what your friend's been up to lately.

The vibe?

Pure white spatial UI. Glassmorphism. Soft 3D agent spheres with kawaii faces that glow and pulse. A

🚀 From Bugs to Breakthroughs: My Full-Stack Journey with JetBrains & Junie

ABINJITH TK — Tue, 03 Feb 2026 18:04:40 +0000

The dream of "autonomous development" has always felt just out of reach—until I paired JetBrains’ world-class IDEs with Junie, their AI-powered programmer. This is the story of how we tackled a complex, multi-layered bug in our "Rift Rewind" project, and why this duo is changing the game for developers.
🔍 The Challenge: A Silent Failure across Continents
Our project, a Riot Games match aggregator, was working perfectly for North American players. But when we tried to fetch data for the legendary "Hide on bush#KR1" (Faker) in Korea, the system returned nothing but silence.
The problem wasn't just a simple typo. It was a classic "Full-Stack Puzzle":
1.
Backend: Hardcoded regional routing (everything sent to americas.api).
2.
API Logic: Missing mappings for Asia and Europe.
3.
Frontend: A UI that collected regions but forgot to tell the backend about them.
In a traditional setup, fixing this would mean jumping between three files, manually tracing data flow, and likely breaking a test or two along the way.
🤖 The Solution: Junie’s "Inside-Out" Approach
Instead of just asking for a snippet of code, I gave Junie the high-level issue. Using the JetBrains Toolset, Junie didn't just guess—it explored:
•
Project Awareness: Junie used search_project to find every instance of the Riot API URL.
•
The Surgical Fix: It modified the Python backend (fetch_api.py) to handle regional mapping, updated the Lambda handlers, and then—crucially—bridged the gap to the Next.js frontend (page.tsx) to ensure the region parameter was passed correctly.
•
Safety First: Because Junie operates with a mandatory planning phase, I could see the proposed changes before a single line was written.
The result? "Hide on bush#KR1" was live, the routing was dynamic, and the code was cleaner than we found it.
✨ The "Aha!" Moment: The JetBrains Synergy
What makes this experience unique isn't just the AI—it’s the integration.
•
Context is King: Junie lives inside the IDE. It knows my folder structure, my naming conventions, and my dependencies.
•
Autonomous but Accountable: I didn't have to copy-paste code. Junie performed atomic renames and multi-file edits while I supervised, acting as the "Architect" while Junie acted as the "Lead Developer."
🛠️ Looking Ahead: The "Skill Booster" Revolution
While the experience was transformative, our journey highlighted the next frontier: Multi-MCP (Model Context Protocol) Support.
Imagine Junie being able to connect to an AWS MCP for infrastructure, a Database MCP for schema validation, and a Custom Documentation MCP all at once. Coding without these "Skill Boosters" feels like working with one hand tied behind your back.
Expanding this connectivity will turn Junie from a "Code Assistant" into a "Domain Expert" for any stack.
🏆 Conclusion: The Future is Here
Working with JetBrains and Junie on this project proved that the barrier between "Idea" and "Implementation" is finally dissolving. We aren't just writing code anymore; we are orchestrating solutions.
If you haven't tried building a full-stack feature with Junie yet, you’re missing out on the most thoughtful, concise, and powerful development experience available today.

[Boost]

ABINJITH TK — Wed, 03 Dec 2025 10:07:13 +0000

Building NecroOS: A Horror-Themed Windows 95 Simulator with Kiro AI

ABINJITH TK ・ Dec 3

#kiro #kiroween #kiroweenhackathon

Building NecroOS: A Horror-Themed Windows 95 Simulator with Kiro AI

ABINJITH TK — Wed, 03 Dec 2025 03:25:45 +0000

Building NecroOS: A Horror-Themed Windows 95 Simulator with Kiro AI

The Challenge: Creating Nostalgia with a Twist

When I set out to build NecroOS for the Kiro hackathon, I wanted to create something that blended nostalgia with horror—a browser-based Windows 95 simulator that progressively becomes more unsettling as users interact with it. The scope was ambitious: draggable windows, multiple applications, glitch effects, audio management, and a "haunt level" system that orchestrates the descent into digital madness.

The twist? I'd be building it with Kiro, an AI-powered IDE assistant that promised to accelerate development while maintaining code quality.

What is NecroOS?

NecroOS is a fully functional Windows 95 desktop environment that runs in your browser. It features:

Authentic retro UI using the react95 component library
Multiple applications: Notepad, Minesweeper, Portfolio Manager, Terminal, and some... darker surprises
Progressive horror mechanics through a haunt level system
Visual effects: CRT monitor simulation, glitch effects, and screen distortions
Audio atmosphere: Ambient sounds and effects that intensify with interaction
Corrupted Clippy: Everyone's favorite assistant, but something's very wrong

The technical stack includes React 19, TypeScript with strict mode, Zustand for state management, and Vite for blazing-fast development.

The Kiro Experience: From Skeptic to Believer

Starting with Structure

My first interaction with Kiro set the tone for the entire project. Instead of diving straight into code, I used Kiro's spec system to formalize my requirements and design. This turned out to be a game-changer.

I created a spec document outlining:

Acceptance criteria for each feature
Correctness properties that needed to be maintained
Implementation tasks broken down into manageable chunks

Kiro helped me iterate on these specs, catching edge cases I hadn't considered. For example, when designing the window management system, Kiro suggested properties like "windows should never overlap the taskbar" and "minimized windows should restore to their previous position"—details that would have caused bugs later.

Property-Based Testing: The Secret Weapon

One of Kiro's most impressive capabilities was its understanding of property-based testing with fast-check. Rather than writing dozens of individual test cases, Kiro helped me define properties that should always hold true.

For the window manager:

fc.assert(
  fc.property(
    fc.array(windowArbitrary, { minLength: 1, maxLength: 10 }),
    (windows) => {
      // Property: focused window should always have highest z-index
      const focusedWindow = windows.find(w => w.isFocused);
      if (focusedWindow) {
        expect(focusedWindow.zIndex).toBeGreaterThanOrEqual(
          Math.max(...windows.map(w => w.zIndex))
        );
      }
    }
  ),
  { numRuns: 100 }
);

Kiro generated these property tests for nearly every component, catching edge cases that traditional unit tests would have missed. The glitch system, audio management, and haunt level orchestration all benefited from this approach.

Steering Rules: Teaching Kiro My Preferences

Early on, I discovered Kiro's steering system—markdown files that provide context and conventions for the entire project. I created three steering documents:

tech.md: Defined the technology stack, common commands, and TypeScript configuration
structure.md: Outlined directory organization, naming conventions, and import patterns
product.md: Described the core concept and key features

Once these were in place, Kiro consistently generated code that matched my project's conventions. No more explaining "use Zustand for state" or "place tests alongside components" in every prompt. Kiro just knew.

The Flow: Rapid Iteration Without Sacrificing Quality

The development rhythm with Kiro was unlike anything I'd experienced:

Define the feature in natural language
Kiro generates implementation with proper TypeScript types, error handling, and tests
Review and refine using Kiro's diagnostic tools
Move to the next feature

For the haunting orchestrator—a complex service that manages progressive horror effects—Kiro generated:

The core service class with proper TypeScript interfaces
Unit tests covering all methods
Property-based tests for state transitions
Error boundary integration
Performance optimizations

All in a single iteration. What would have taken me hours of careful coding and testing happened in minutes.

Real-World Example: The Glitch System

The glitch system was one of the most complex features. It needed to:

Apply visual distortions to windows based on haunt level
Coordinate with audio effects
Handle performance constraints
Provide smooth animations
Work across different browsers

I described the requirements to Kiro, and it generated:

export const GlitchableWindow: React.FC<GlitchableWindowProps> = ({
  children,
  windowId,
  intensity = 0,
}) => {
  const glitchLevel = useStore((state) => state.glitchLevel);
  const effectiveIntensity = Math.min(intensity + glitchLevel * 0.1, 1);

  // Kiro added proper memoization for performance
  const glitchStyle = useMemo(() => ({
    filter: `hue-rotate(${effectiveIntensity * 180}deg) 
             contrast(${1 + effectiveIntensity * 0.5})`,
    animation: effectiveIntensity > 0.5 
      ? `glitch ${2 - effectiveIntensity}s infinite` 
      : 'none',
  }), [effectiveIntensity]);

  return (
    <div className="glitchable-window" style={glitchStyle}>
      {children}
    </div>
  );
};

Complete with property tests verifying that intensity values always stayed within bounds and that performance remained smooth even with multiple glitching windows.

Debugging with Context

When I encountered a bug where audio wouldn't play in certain browsers, I used Kiro's context system to share the error. Kiro immediately:

Identified it as an autoplay policy issue
Generated a robust audio service with user interaction detection
Added fallback mechanisms
Created comprehensive error handling
Wrote tests covering the edge cases

The fix was production-ready, not a quick hack.

The Results: Quality at Speed

After two weeks of development with Kiro, NecroOS includes:

15+ React components, each with unit and property-based tests
95%+ test coverage across the codebase
Zero TypeScript errors in strict mode
Comprehensive error handling with graceful degradation
Performance optimizations for smooth 60fps animations
Cross-browser compatibility with proper fallbacks

The codebase is maintainable, well-documented, and follows consistent patterns throughout. This isn't just a hackathon project—it's production-quality code.

What I Learned

Kiro Excels At:

Structured development: The spec system keeps complex projects organized
Property-based testing: Catches edge cases traditional tests miss
Consistency: Steering rules ensure uniform code across the project
Context awareness: Kiro understands the entire project, not just individual files
Best practices: Generated code follows modern patterns and conventions

The Human Touch Still Matters:

Creative direction: Kiro implements, but you define the vision
Architecture decisions: High-level structure benefits from human insight
User experience: Kiro can't feel the horror atmosphere—that's on you
Final polish: The subtle touches that make it special

Tips for Using Kiro Effectively

Start with specs: Invest time in requirements and design documents
Create steering rules early: Teach Kiro your preferences upfront
Embrace property-based testing: Let Kiro generate comprehensive test suites
Use context liberally: Share errors, file structures, and related code
Iterate in conversation: Kiro learns from your feedback

The Verdict

Building NecroOS with Kiro transformed my development process. I shipped a complex, well-tested application in a fraction of the time it would have taken solo, without sacrificing code quality. The combination of AI assistance and human creativity is powerful—Kiro handles the tedious implementation details while I focus on the experience and architecture.

If you're skeptical about AI-assisted development, I get it. I was too. But Kiro isn't trying to replace developers—it's amplifying what we can build. And for a solo developer tackling an ambitious project, that amplification is the difference between "maybe someday" and "shipped today."

Try NecroOS if you dare: [(https://main.d3o8c3ri5rcch8.amplifyapp.com/)]
Check out the code: [(https://github.com/AbinjithTK/necroOS)]

Built with Kiro. Haunted by design. 👻

kiro #hackathon #react #typescript #horror #webdev #ai