DEV Community: Ashiha Mahesh Kumar

Nights Watch: Guarding AI Agents Beyond the Wall

Ashiha Mahesh Kumar — Sun, 26 Jul 2026 15:25:01 +0000

A technical write-up of a hackathon build for WeMakeDevs' "Agents of SigNoz." This post covers the architecture, the OpenTelemetry instrumentation, and two annotated trace walkthroughs — one clean run and one with deliberately injected drift — from github.com/ashihams/Nights-Watch.

1. Problem statement

Most AI agent safety discussion centers on adversarial failure: prompt injection, jailbreaks, tool poisoning. There is a second, quieter failure mode that gets far less attention: an agent that is not attacked at all, and simply drifts. Given a bounded task — "find and book a flight from SFO to LAX under $400" — an agent can, without any external interference, select a $1,200 option, add an unrequested hotel booking, or otherwise take an action that no longer matches what was approved. Nothing throws an exception. No policy is technically "broken" in the sense of hitting an error path. The system just quietly does more, or something different, than it was asked to do, and by the time this is noticed, an irreversible action (a non-refundable booking, in this case) may already have executed.

Nights Watch is a runtime resilience system built to catch this specific failure class. It does five things:

Tracks an agent's actual execution against its originally approved plan, step by step.
Scores each step against policy rules (0–100; higher means more severe deviation).
Produces a plain-language explanation of why a violation occurred, at the moment it's detected.
Pauses execution before an out-of-scope or irreversible action fires.
Rolls back to the last known-good checkpoint, re-plans, and resumes — either automatically or pending human approval, depending on severity.

The architectural claim this post is built around, and the reason it's relevant to a SigNoz-focused write-up specifically: the Policy Engine queries SigNoz synchronously, on the critical execution path, to help decide what happens next. SigNoz is not a passive sink for logs reviewed after the fact — a live query against it is part of the decision loop. That is a materially different integration pattern than "instrument the app, look at dashboards later," and it's the part of the build I think is worth documenting in detail.

2. System architecture

Nights Watch has four components, deliberately kept in a strict role separation:

Component	Role	Owns state?
n8n	Executor. Runs the actual agent workflow (search → select → confirm → book) as a visual workflow. Reports each step's result to the backend over webhook.	No
Nights Watch Backend (TypeScript, Fastify)	The decision layer. Contains the Policy Engine, Checkpoint Manager, and Recovery Engine.	Yes — execution state lives here
SigNoz	Observability backend. Ingests OpenTelemetry traces/metrics/logs from the backend; exposes a Query API and an MCP server for querying that data.	No — by design
React Dashboard	Live view over WebSocket: policy score timeline, checkpoint markers, explanation feed, recovery metrics, human-approval controls.	No

        React + TypeScript + Tailwind
           (Nights Watch Dashboard)
                     │
            REST  /  WebSocket
                     │
      Nights Watch Backend (TypeScript)
   ┌─────────────────┼──────────────────┐
   │                 │                  │
   ▼                 ▼                  ▼
Policy Engine   Checkpoint Manager   Recovery Engine
   │                 │                  │
   │        (owns execution state,      │
   │         backed by local store)     │
   │                 │                  │
   └─────────────────┼──────────────────┘
                     │
            OpenTelemetry SDK
                     │
                  SigNoz
                     ▲
                     │
          n8n Workflow Engine

n8n's role is intentionally narrow: it executes steps and reports outcomes. It makes no policy decisions and holds no execution state. That separation matters for the same reason it matters in any control-plane/data-plane split — the component that acts should not also be the component that judges, or you lose the ability to independently audit and override.

2.1 The data-source classification rule

The single design decision this whole project hangs on is a strict split between two categories of data, based on latency tolerance:

	Live context (blocks execution)	Observability context (informs, doesn't block)
Examples	current step, current checkpoint, current tool call, current spend	prior policy violations this run, recovery metrics, historical traces, budget trend
Source of truth	the Checkpoint Manager's own local store	SigNoz, via Query API or MCP
Latency tolerance	none — the agent loop is blocked on this	high — SigNoz can be slower without breaking anything

The rule that follows from this table: if a rollback decision ever depends on the result of a SigNoz query, that's a bug. Rollback state is reconstructed from the Checkpoint Manager's own store — never from SigNoz — precisely because a query against an external HTTP service is a latency and availability dependency you don't want in a path that's supposed to fire in milliseconds. SigNoz is where the Policy Engine goes to ask decision-support questions ("has this run already had a medium-severity violation?"), not decision-critical questions ("what state do I roll back to?").

This is also why the project uses two separate access patterns into SigNoz rather than one:

Direct Query API — used by the Policy Engine, on the critical path, for fast, typed, deterministic lookups. No LLM indirection here, because the Policy Engine runs on every single step and can't absorb the added latency or non-determinism an LLM-driven query would introduce.
SigNoz MCP server — used by the Explanation Layer, which only fires occasionally (on a violation). SigNoz's MCP server (signoz.io/docs/ai/signoz-mcp-server) exposes tools for querying metrics, traces, logs, alerts, and dashboards through natural language, with the MCP client (an LLM tool-calling loop, in this case) deciding what to ask for rather than the query being pre-specified. That's the right shape for "explain why this happened" — an LLM deciding what context is relevant — and the wrong shape for "should I roll back right now."

3. Instrumentation: what actually gets sent to SigNoz

The backend uses the OpenTelemetry SDK for Node.js. Every run produces one root span, run.execute, of kind Internal, with resource attributes standard to any Node.js OTel setup — service.name: "nights-watch", telemetry.sdk.name: "opentelemetry", telemetry.sdk.version: "1.30.1", process.runtime.name: "nodejs", process.runtime.version: "24.5.0" — plus process-level detail like process.command, process.owner, and host.name, which is standard OpenTelemetry Resource semantic convention data rather than anything custom.

Underneath the root span sit child spans for each checkpoint boundary: checkpoint.created, policy.evaluation, executor.step, and (on a recovery run) checkpoint.restored. A clean run produces 14 spans; a run that hits one recovery cycle produces 19.

The interesting instrumentation decision is how the content — the plan, the policy score, the recovery outcome — gets attached. Early versions of the instrumentation put this data directly on span attributes, which made the flame graph difficult to read and mixed "facts about the operation as a whole" with "things that happened at a specific moment." OpenTelemetry's own guidance on this draws exactly that distinction: attributes describe the operation as a whole and are best used for data known when the span starts, while an event should be used when the data represents a distinct, timestamped occurrence within the span's lifetime — something that could happen zero or more times (opentelemetry.io/docs/specs/semconv/general/events; opentelemetry.io/docs/concepts/signals/traces). A policy evaluation, a recovery start, and a run completion are all exactly that: discrete, timestamped things that happen during the life of a run.execute span, not properties of the span as a whole. So each is recorded as a span event on the root span, not a top-level attribute:

plan.ready — fired once, carries the full generated plan as a JSON attribute
run.recovery_started — fired when a violation triggers rollback; carries policy.score, severity, and the step that failed
run.resumed — fired after successful rollback; carries checkpoint.id, completedSteps, durationMs, and recovery.action
checkpoint.pre_irreversible — fired immediately before an irreversible step (e.g. book) executes
run.completed — fired at the end; carries policy.lastScore, recovery.count, the list of checkpoints, and steps

One caveat worth being upfront about: OpenTelemetry has an in-progress proposal to deprecate the span-events API in favor of log-based events correlated to the active span context (opentelemetry.io/blog/2026/deprecating-span-events). Existing data and span-event views are expected to keep working, and this is a forward-looking migration rather than something that affects a project built today — but it's a reasonable thing to track if you're instrumenting a similar system now and expect it to still be running in a year or two.

The plan.ready event's JSON payload is the single most load-bearing piece of data in the whole system, because it's what the Policy Engine diffs every actual step against:

{
  "goal": "Find and book a flight from SFO to LAX under $400",
  "maxBudget": 400,
  "currency": "USD",
  "origin": "SFO",
  "destination": "LAX",
  "steps": [
    { "id": "search", "order": 0, "description": "Search flights within budget",
      "expectedTool": "search_flights", "constraints": { "maxPrice": 400 } },
    { "id": "select", "order": 1, "description": "Select an in-budget flight option",
      "expectedTool": "select_flight", "constraints": { "maxPrice": 400 } },
    { "id": "confirm", "order": 2, "description": "Confirm passenger and itinerary details",
      "expectedTool": "confirm_details", "constraints": {} },
    { "id": "book", "order": 3, "description": "Book the confirmed flight",
      "expectedTool": "book_flight", "constraints": { "irreversible": true },
      "expectedTargets": ["flights"] }
  ]
}

Every field here is queryable structured data, not free text — which is what lets the Policy Engine's evaluation be a deterministic rule check (does expectedTool for this step match the tool actually invoked; does the actual value respect the step's constraints) rather than something fuzzier.

4. Trace walkthrough — clean run

The demo scenario is fixed: find and book a flight from SFO to LAX, budget capped at $400. On a clean run, the dashboard's Policy Score Timeline — driven by data streamed out of SigNoz over WebSocket — stays at 0 across all four checkpoints.

The corresponding SigNoz trace (run.execute, 4.2 s, 14 spans, 0 errors) shows the expected repeating pattern in the waterfall: checkpoint.created → executor.step → policy.evaluation, once per plan step.

Two details from the span's Overview tab are worth calling out specifically because they're standard OTel resource attributes doing real diagnostic work, not custom instrumentation: process.command (D:\project\SignozHack\backend\src\index.ts) and process.command_args, which together let you confirm — from inside the trace, without touching the terminal — exactly which build and entry point produced this run. That's the kind of detail that matters when you're debugging "why did staging behave differently from local" and don't want to rely on memory of what was deployed when.

By the closing run.completed event:

policy.lastScore: 0, recovery.count: 0 — the run never needed the Recovery Engine, because the Policy Engine never scored a step above the pause threshold. This is the boring, expected outcome. Section 5 breaks it on purpose.

5. Trace walkthrough — drift injection and recovery

The Control Room dashboard has a second entry point for exactly this: Start Run (Inject Drift), which perturbs the "select" step so it resolves to a $1,200 fare instead of staying under the $400 cap — a direct simulation of the silent-overreach scenario from Section 1.

The moment select_flight is invoked at $1,200, the Policy Engine's rule evaluation fires before the workflow is allowed to proceed to confirm. This is the live-query path from Section 2.1 doing its job: the backend is blocked, mid-execution, on this evaluation.

Note the three severity thresholds visible on the Policy Score Timeline's y-axis in these screenshots: Pause at 40, Rollback at 70, Hard-stop at 90. This run's violation scored 40 — a medium-severity pause that surfaces for human approval rather than triggering an automatic hard rollback, which is the intended behavior for a violation that's clearly wrong but not yet irreversible.

The corresponding SigNoz span event, run.recovery_started, records the identical numbers the dashboard is rendering:

policy.score: "40", severity: "medium", step: "select". This one-to-one correspondence between the dashboard and the raw trace data was a deliberate verification point during the build — the dashboard reads these values live off SigNoz via WebSocket, so there's no separate in-memory state that could silently drift out of sync with what's actually recorded in the trace.

Choosing Reject & Recover triggers the Recovery Engine, which reconstructs state from the Checkpoint Manager's own store (not from SigNoz — see Section 2.1) and re-plans from the last safe checkpoint:

recovery.action: "rollback_replan", completed in 13 milliseconds. That number is the direct payoff of the architectural split: because rollback reads from a local store rather than round-tripping to an external HTTP API, its speed is bounded by local I/O, not network latency or SigNoz query load. Once resumed, the agent re-executes select correctly, then confirm and book. The dashboard's Recovery Health panel updates accordingly:

And the full Policy Score Timeline for the run shows the shape of the whole incident in one chart — a spike to 40 at the second select attempt, then back to 0 for confirm and book:

The final run.completed event confirms the run finished with one recovery cycle and the original goal still met:

recovery.count: 1. The agent hit a real, scored violation and did not need a full restart or an unrecoverable failure state to get back on track.

6. Discussion

Three things stood out as genuinely non-obvious while building this, beyond what the architecture diagram alone communicates:

Deciding what SigNoz is and isn't allowed to gate was the actual hard design problem. It's tempting, especially with an MCP server available, to let a live query decide "should this rollback happen." An early prototype did something close to this, and the added latency plus the non-determinism of an LLM-mediated query made the pause-and-recover loop noticeably slower and occasionally inconsistent in repeated testing. The fix wasn't a performance optimization — it was a re-scoping of which questions SigNoz is allowed to answer on the critical path at all (Section 2.1's table).

Span events, not span attributes, are what kept the trace view legible. Once the plan JSON, policy scores, and recovery outcomes moved off top-level span attributes and onto discrete events on the root span, the flame graph stopped needing to be scrolled through wide attribute dumps to find the one relevant number for a given moment in the run.

A 13 ms and a 2 ms recovery time are not incidental — they're the metric that actually validates the architecture. If rollback took seconds instead of milliseconds, the "resilience" claim in the project's name would be weaker in practice than in the pitch. The number in the trace is the honest test of whether the live/observability split held up under an actual injected failure, not just in the design doc.

7. Summary

Nights Watch treats SigNoz as an active input to a runtime decision loop, not a passive record of what already happened: a fast, typed Query API path for the Policy Engine's every-step decisions, and the MCP server's natural-language querying for the occasional, non-blocking "explain this" case. The two traces above — one clean, one with an induced $1,200 drift and a 13 ms rollback — are the unedited output of that split working as designed.

Architecture and full workflow diagrams for the n8n executor layer are in progress and will follow in an update to this post.

Repository: github.com/ashihams/Nights-Watch
Event: WeMakeDevs — Agents of SigNoz Hackathon
References: OpenTelemetry — Traces · OpenTelemetry — Semantic Conventions for Events · SigNoz MCP Server docs

DueIt : Your To-Do List Doesn't Know You So I Gave Mine Three Brains

Ashiha Mahesh Kumar — Mon, 25 May 2026 07:36:53 +0000

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

What I Built

What I Built
DueIt is an adaptive task planning system powered by three Gemma 4 models. You create one task — and the system plans your entire path to the deadline, generates a Notion workspace, scrapes real resources, builds a visual workflow diagram, and replans automatically when you miss a day.
It solves two problems no to-do app has ever fixed:

Forgetting an assignment exists until the night before
Not having enough time because you started too late

Three Gemma 4 models power the system — each chosen for a specific reason:

31B Dense for deep reasoning — task planning, time estimation, Notion doc generation
2B for speed — morning replanning in under 2 seconds
26B MoE for multi-domain synthesis — Excalidraw workflow diagrams and analysis

Let me walk you through exactly what happens when you use DueIt.

You open the app and create a task.

Say you need to build a RAG chatbot. You type the title, pick "Work" as the category, set the deadline, and hit create.
Behind the scenes, Gemma 4 31B Dense starts reasoning. It reads the task, estimates that this will take around 55 hours across 5 phases, and generates a structured day-by-day schedule with specific microtasks for each day. It calculates pressure and risk scores based on your deadline proximity and workload.
When the plan lands, your home screen shows the task with every microtask you can expand and check off as you go.

Your calendar fills itself.
You didn't manually block time. You didn't drag anything. Gemma 31B distributed your microtasks across every day from now until the deadline as real time-blocked sessions — morning workout at 7, landing page mockup at 9, RAG chatbot work at 11:30.
Multiple tasks from different categories sit side by side on the same day. You open the calendar and know exactly what to work on, when, and for how long.

The dashboard tells you the truth.
Not motivational quotes. Not "you got this." The truth.
Your pressure is at 71% — deadlines are close and tasks are piling up. Your risk of missing a deadline is 51% — you're on the edge. Your streak is 7 days — you've been showing up.
The work rhythm chart shows how your productivity flows across the week. Tuesday and Wednesday are your peak days. Sunday drops off.

Scroll down and the AI productivity heatmap shows your entire month. Dark purple means you crushed it. Light means you barely touched anything. One glance and you see the pattern you didn't know you had.

Meanwhile, Notion builds your workspace.
While you were looking at the dashboard, DueIt auto-generated a complete Notion page for your task. No templates. No manual setup.
The page has a task overview with your deadline and time estimate. An expected output section. And a Progress Tracker — an inline database with every phase mapped out: Research, Design, Implementation, Testing, Review & Deploy. All set to "To Do."

Scroll down and every phase has detailed notes with specific microtasks. Phase 1 tells you to identify data sources, research RAG frameworks like LangChain and LlamaIndex, evaluate vector databases. Phase 2 tells you to collect sample documents, design the system architecture, define the chunking approach.
The workflow diagram link sits right there — click it and you're in Excalidraw.
And at the bottom, curated resources that TinyFish scraped from the web. Not generic Google results — real links: Pinecone docs on building RAG chatbots, Microsoft Learn guides, LangChain documentation, DEV Community tutorials.

Excalidraw shows you the visual map.
Gemma 4 26B MoE took the phases from your plan and generated a Mermaid flowchart. TinyFish rendered it in Excalidraw and started a live collaboration room.
Collect Source Documents → Chunk & Embed Data → Index Vector Store → Configure Retrieval Logic → Integrate LLM Prompting → Build Chat Interface.
Every task gets a unique workflow specific to its actual phases. Not a template — a diagram that matches what Gemma planned for this specific task.

Cursor reads the Notion page and starts building.
This is where planning becomes execution.
Cursor connects to your Notion workspace through MCP. It reads the Progress Tracker, understands the phases and their order. It reads the Notes section, understands the specific microtasks within each phase.
Then it starts working. It executes Phase 1 — generates actual project structure, files, and code corresponding to the research phase.
When it finishes, it updates the Notion Progress Tracker. Research phase: Done. Design, Implementation, Testing, Review & Deploy: still To Do. The status change syncs back to your Flutter app automatically.

The Excalidraw diagram updates too — the first box turns green. Planning and execution stay perfectly synchronized.

You skip a day. DueIt doesn't care.
Life happened. You didn't touch anything yesterday. Most apps would just show you a red overdue badge and guilt you into quitting.
DueIt does something different. The next time you open the app, Gemma 4 2B kicks in — in under 2 seconds it checks what you completed, identifies what you missed, and redistributes those microtasks across your remaining days. Your calendar updates. Your pressure meter rises. Your risk adjusts.
But your path to the deadline is still clear. The plan adapted to the real you, not the ideal you who never skips a day.

Figma Prototype

Click here to explore the prototype

Demo

Code

ashihams / due-it

AI-powered task planning app that automatically breaks tasks into actionable subtasks, adapts daily schedules, and recalculates workload based on missed tasks and approaching deadlines.

DueIt

An AI-powered adaptive task planning system that breaks tasks into microtasks, distributes them across your calendar, and replans automatically when life gets in the way.

DueIt uses three Gemma 4 models with intentional role separation, Notion integration for workspace generation, and TinyFish for web resource scraping and Excalidraw workflow diagrams.

Repository Layout


├─ due_it/                    # Flutter frontend
│  ├─ lib/
│  │   ├─ models/             # Task, AiSchedule, DueTask data models
│  │   ├─ providers/          # State management (Provider)
│  │   ├─ screens/            # Home, Calendar, Dashboard, Tasks, Auth, Settings, Profile
│  │   ├─ services/           # API calls, Firestore, Notion
│  │   ├─ theme/              # Colors, spacing, typography
│  │   └─ widgets/            # Reusable UI components
│  ├─ test/                   # Unit tests
│  └─ pubspec.yaml
├─ due_it_backend/            # FastAPI backend
│  ├─ main.py                 # API gateway, planning logic, scheduling algorithms
│  ├─ notion/                 # Notion integration package
│  │

…

View on GitHub

Architecture

Flutter app authenticates through Firebase and sends every request to FastAPI on Cloud Run
FastAPI is a thin router — validates tokens, then hands off to the right Gemma model based on task type
31B Dense handles planning and Notion doc generation. 2B handles morning replans. 26B MoE handles diagram synthesis
Every AI response passes through _validate_ai_plan() before touching Firestore
Notion workspace creation, TinyFish resource scraping, and Excalidraw diagram generation all fire simultaneously as BackgroundTasks
Firestore syncs everything back to Flutter in real time
Cursor connects to Notion through MCP, executes phases as code, and updates the progress tracker — closing the loop

Tech Stack

Frontend
├── Flutter (Dart)
├── Provider — state management
└── Firebase SDK — auth + real-time Firestore sync

Backend
├── FastAPI (Python) — API gateway
├── HTTPX — async HTTP client for OpenRouter
├── BackgroundTasks — parallel Notion/TinyFish/Excalidraw
└── Cloud Run — serverless deployment

AI Models (via OpenRouter)
├── Gemma 4 31B Dense  — planning, estimation, Notion docs
├── Gemma 4 2B         — morning replan, schedule adjustment
└── Gemma 4 26B MoE    — Excalidraw diagrams, Mermaid generation

Data
├── Cloud Firestore — users, tasks, schedules, metrics
└── Firebase Auth — email/password authentication

Integrations
├── Notion API — workspace generation (notion/ package)
├── TinyFish API — web resource scraping + Excalidraw automation
├── Excalidraw — visual workflow diagrams + collaboration rooms
└── Cursor AI — code execution via Notion MCP

Deployment
├── Google Cloud Run — backend
└── Vercel — web frontend

How I Used Gemma 4

DueIt uses all three Gemma 4 model architectures — not because more models sounds impressive, but because each layer of the system has fundamentally different computational demands. A planning engine that reasons through task complexity for 10 seconds is fine. A morning replanner that takes 10 seconds is unusable. A diagram generator that can't hold task structure and visual syntax in its head simultaneously produces garbage. One model can't optimize for all three.

Gemma 4 31B Dense — the reasoning layer

Used for: Task planning, time estimation, phase generation, Notion document content

When you create a task like "Build a RAG chatbot — due in 2 weeks," the model doesn't just split it into equal chunks. It reasons:

This is a multi-phase engineering task — it needs research, design, implementation, testing, and deployment
Research and design are front-loaded — you can't implement what you haven't designed
Implementation is the heaviest phase — it needs 40% of total time, not 20%
The last two days should be lighter — buffer for overrun, not new work
Estimated total: 55 hours across 5 phases, 12 microtasks distributed across 10 working days

Every one of those decisions depends on every other decision. Change the estimate and the distribution changes. Change the phase count and the per-day load changes. This is constraint-dependent multi-step reasoning — not pattern matching, not template filling.

Dense architecture activates all 31B parameters on every token. That matters here because the output is structured JSON where a single malformed field — a negative estimatedMinutes, a missing microtasks array, a schedule longer than the deadline — breaks the entire downstream pipeline. Every token in the output needs the full weight of the model behind it.

GEMMA_31B_DENSE = "google/gemma-4-27b-it"

# The planning prompt includes task title, category, deadline,
# and category-specific instructions (Study vs Work vs Personal)
response_text = _call_gemma(GEMMA_31B_DENSE, prompt, max_tokens=4096)
plan = json.loads(response_text)

# Validate before anything touches Firestore
validated = _validate_ai_plan(plan)
# estimatedMinutes: capped 1-10000
# confidence: clamped 0.0-1.0
# schedule: max 60 days
# microtasks per day: max 10
# missing fields: safe defaults applied

The same model generates Notion document content — task overview, expected output, phase-by-phase notes with microtask breakdowns. This also requires structured reasoning: the Notion page isn't a summary of the plan, it's a restructured representation of the plan optimized for human readability and Cursor agent consumption. Different output format, same reasoning depth.

Why not MoE? The MoE architecture routes tokens to specialist sub-networks. That's powerful when different parts of the input need different expertise. But planning is holistic — the time estimate affects the schedule, which affects the daily load, which affects the pressure score. Routing parts of this reasoning to different experts fragments the very thing that needs to stay unified.

Why not 2B? I tested it. 2B generates plausible-looking JSON that falls apart under scrutiny — phases with no microtasks, schedules that extend past the deadline, time estimates that don't add up to the total. The structured output reliability drops dramatically below 31B for this task.

Gemma 4 2B — the speed layer

Used for: Morning replanning, missed task redistribution, schedule adjustments

This is the model most users interact with without knowing it. Every morning when you open DueIt, the app checks: what did you complete yesterday? What did you skip? How many days are left until each deadline?

If you missed microtasks, 2B redistributes them across your remaining days — proportionally, not equally. A day with 3 existing microtasks gets fewer redistributed tasks than an empty day. The pressure and risk meters recalculate. The calendar updates.

This needs to happen in under 2 seconds. A student checking their phone at 8:47 AM before a 9:00 class is not going to wait for a 31B model to reason through redistribution for 15 seconds. They'll close the app and forget about it — which is the exact problem DueIt exists to solve.

2B handles this because the task is operationally simple. It's not generating a new plan from scratch. It's taking an existing schedule, identifying missed items, and proportionally redistributing them. The reasoning depth required is low. The latency requirement is strict.

GEMMA_2B = "google/gemma-4-4b-it"

# Called on app open — reads yesterday's completions,
# identifies missed microtasks, redistributes across remaining days
# Input is never mutated — copy.deepcopy protects the original
schedule = copy.deepcopy(existing_schedule)
adjusted = _redistribute_schedule(schedule, now, deadline)

Why not 31B? It would produce marginally better redistribution — maybe slightly smarter about which days get more load. But the latency cost is 5-10x higher, and the quality difference is negligible for a redistribution task. The user doesn't notice a 2% better redistribution. They absolutely notice a 10-second wait.

Why not MoE? MoE's routing overhead adds latency even when the task only needs one expert. For a single-domain operation (schedule math), the routing is pure overhead. 2B dense is the fastest path to a correct answer.

Gemma 4 26B MoE — the synthesis layer

Used for: Excalidraw workflow diagram generation, Mermaid flowchart synthesis, multi-domain analysis

When DueIt creates an Excalidraw workflow diagram, the model needs to do three things simultaneously:

Understand task structure — parse the phases (Research → Design → Implementation → Testing → Deploy) and their dependencies
Generate valid Mermaid syntax — produce a flowchart LR block with correct node IDs, arrow syntax, and label formatting
Ensure visual logic — the flowchart should read left-to-right in a sequence that makes sense to a human, not just a valid parse tree

These three domains — task management, code syntax, and visual layout — are genuinely different areas of expertise. A model that's great at understanding task phases might generate broken Mermaid. A model that writes perfect Mermaid might produce a diagram that's technically valid but visually confusing.

This is exactly what Mixture-of-Experts was architectured for. The 26B MoE model has 26 billion total parameters organized into specialist sub-networks, but only activates 4 billion on any given token. Different tokens in the output route to different experts — the task-understanding tokens go to one expert, the syntax tokens to another, the layout decisions to a third.

The result: edge-speed inference (only 4B active parameters per forward pass) with full-depth knowledge (26B total parameters available for routing). You get the speed of a small model with the knowledge of a large one.

GEMMA_26B_MOE = "google/gemma-4-26b-a4b-it"

# Generate Mermaid flowchart from task phases
# The prompt includes phase names, ordering, and dependencies
raw_steps = _call_gemma(GEMMA_26B_MOE, steps_prompt, max_tokens=2048)

# TinyFish takes the Mermaid code, opens Excalidraw,
# imports via the Mermaid importer, starts a collaboration room,
# and returns the shareable URL

Why not 31B Dense? 31B would produce equally good diagrams, but slower. Since diagram generation runs as a BackgroundTask (the user isn't waiting on it), latency matters less here than for replanning. But 31B is already busy with the planning call — running both in parallel on the same model class creates queuing. MoE handles diagram generation on a separate architecture while 31B focuses on planning.

Why not 2B? I tested it. 2B generates Mermaid that looks right but breaks on edge cases — missing arrow connectors, node IDs that collide, labels that overflow. The cross-domain synthesis required (task logic + code syntax + visual layout) exceeds what 2B can hold in context simultaneously.

Model selection summary

Model	Architecture	What it does	Why this specific architecture
Gemma 4 31B Dense	All 31B params active per token	Task planning, time estimation, Notion docs	Holistic multi-step reasoning for reliable structured JSON
Gemma 4 2B	Small dense, fast inference	Morning replan, schedule redistribution	Under 2 seconds — speed is the UX requirement
Gemma 4 26B MoE	4B active / 26B total	Excalidraw diagrams, Mermaid generation	Expert routing across task logic, code syntax, and visual layout

What Gemma 4 unlocked

Before Gemma 4, DueIt used a single gemini-2.5-flash call for everything — planning, diagrams, formatting, replanning. Same model, same latency, same capability ceiling. There was no model selection strategy because there was no model selection available.

The migration wasn't just swapping model strings. It was rethinking which cognitive task each API call actually performs and matching it to the architecture that handles that task best.

Planning got deeper — 31B Dense reasons through constraints that Flash skimmed over. Replanning got faster — 2B responds in the time it takes to glance at your phone. Diagrams got better — MoE's expert routing produces cleaner cross-domain output than a single generalist model juggling three domains at once.

That's what intentional model selection looks like. Not "I used the biggest model for everything." But: I used three models, each one earning its place.

Built solo with too much coffee, three Gemma brains, and the belief that productivity apps should plan around the real you — not the ideal you.

One task. Fully planned. Automatically adapted.