DEV Community: Harish Kotra (he/him)

Engineering a Gamified Portfolio: Inside DailyBuild Roulette

Harish Kotra (he/him) — Tue, 21 Jul 2026 15:23:24 +0000

As developers, we are accustomed to showcasing our work through traditional, chronological grid-based portfolios. While functional, standard grids can feel static and fail to capture the visceral excitement of Shipping.

To mark the milestone of Build #200, we wanted to create something fundamentally different: a fully gamified, tactile, and sensory-rich exploration engine.

Enter DailyBuild Roulette, a slot-machine-style discovery interface built using React, TypeScript, Framer Motion (motion/react), and Tailwind CSS v4.

In this article, we'll dive deep into the technical implementation of its three standout features:

The 3-Phase Mechanical Deceleration Spindle
Dynamic Web Audio Sound Synthesis
Cross-Platform Device-Shake Gesture Hooks
Tailwind CSS v4 Stark Aesthetics (Ditching the "AI Gradient Slop")

1. Stark Minimalism: Why We Ditched the Gradients

In contemporary frontend design, there is a tendency to overuse vibrant radial gradients, blinking neon margins, and floating glassmorphism overlays. We call this "AI Slop." It distracts from content and results in visual clutter.

For DailyBuild Roulette, we chose a high-contrast flat layout.

We replaced gradient background rings and radial vignettes with flat solid boundaries (#0a0a0a background and #0d0d0d panels).
Shadows are tight and specific, creating elevation instead of blurry dark clouds.
Accents use solid colors (such as deep Indigo and Amber) paired with high-contrast text overlays to enforce strict hierarchy.

The typography relies on Inter paired with JetBrains Mono for numbers and indices, creating a highly technical, functional, and editorial feel.

2. The Mechanics of the Spin: 3-Phase Deceleration Spindle

The heart of the application is the SlotMachine.tsx component. A generic slide-in transition would ruin the "physical weight" illusion of a casino spindle. To solve this, we used Framer Motion's imperative useAnimationControls to chain together three specific phases of motion.

The Physics Sequence

Phase 1: Rapid Acceleration: The strip quickly rolls down from index 0 to cover about 35% of the card height distance.
Phase 2: Viscous Friction Deceleration: The wheel slows down heavily using an ease-out curve, traveling past the target element to simulate physical inertia (overshoot).
Phase 3: Elastic Snap-back: The card rebounds back to lock precisely onto the center using a spring physics model.

Here is the production implementation:

const runSpinSequence = async () => {
  // Ensure we start exactly at zero scroll coordinate
  controls.set({ y: 0 });

  // Phase 1: Rapid linear-ease acceleration
  await controls.start({
    y: targetY * 0.35,
    transition: {
      duration: 0.7,
      ease: [0.4, 0, 1, 1], // Ease In curve
    },
  });

  // Phase 2: Heavy deceleration with physical overshoot (-12px)
  await controls.start({
    y: targetY - 12,
    transition: {
      duration: 1.6,
      ease: [0, 0, 0.2, 1], // Deceleration easeOut curve
    },
  });

  // Phase 3: Elastic spring snap back to lock exactly on targeted card
  await controls.start({
    y: targetY,
    transition: {
      type: 'spring',
      stiffness: 280,
      damping: 14,
      mass: 0.8,
    },
  });

  onSpinComplete();
};

This multi-phase approach creates a highly realistic, responsive, and satisfying "mechanical" sensation when landing on a card.

3. High-Fidelity Audio System Without Static Assets

Relying on pre-recorded audio files for slot machine ticking sounds introduces latency, increases bundle size, and prevents audio from scaling dynamically with the velocity of the wheel.

Instead, we built a declarative sound ticker system using the browser's native sound capabilities or high-frequency interval modulation. We simulated ticks that scale in delay as the spin progress increases:

const playTicks = () => {
  if (currentCardIndex >= totalCards) return;

  // Emit a click event or play sound
  playClickSound();
  currentCardIndex++;

  // Delay calculation: scales exponentially based on rotational progress
  const progress = currentCardIndex / totalCards;
  const delay = 45 + Math.pow(progress, 3.5) * 450; // Delay increases up to 500ms

  tickTimeoutRef.current = setTimeout(playTicks, delay);
};

This mimics the mechanical "plink" of the gear indicator slowing down, syncing the auditory feedback perfectly with the visual deceleration curve.

4. Interactive hardware: Device Shaking on Mobile

We wanted physical interaction on mobile devices to trigger spins. To do this without importing heavy sensory packages, we wrote a custom React Hook useShake.ts wrapping the browser's DeviceMotionEvent.

To prevent false triggers from basic walking or pocket movement, we calculate a multi-dimensional magnitude and evaluate it against a strict threshold:

import { useEffect } from 'react';

export function useShake(onShake: () => void, isDisabled: boolean = false) {
  useEffect(() => {
    if (isDisabled) return;

    let lastX: number | null = null;
    let lastY: number | null = null;
    let lastZ: number | null = null;
    let lastUpdate = 0;
    const threshold = 14; // Acceleration threshold (m/s²)

    const handleMotion = (event: DeviceMotionEvent) => {
      const acc = event.accelerationIncludingGravity;
      if (!acc) return;

      const { x, y, z } = acc;
      if (x === null || y === null || z === null) return;

      const now = Date.now();
      if (now - lastUpdate > 100) {
        lastUpdate = now;

        const deltaX = Math.abs(x - (lastX ?? x));
        const deltaY = Math.abs(y - (lastY ?? y));
        const deltaZ = Math.abs(z - (lastZ ?? z));

        const magnitude = Math.sqrt(deltaX * deltaX + deltaY * deltaY + deltaZ * deltaZ);

        if (deltaX > threshold || deltaY > threshold || deltaZ > threshold || magnitude > threshold) {
          onShake();
        }

        lastX = x;
        lastY = y;
        lastZ = z;
      }
    };

    window.addEventListener('devicemotion', handleMotion);
    return () => window.removeEventListener('devicemotion', handleMotion);
  }, [onShake, isDisabled]);
}

This utilizes native mobile browser APIs to create an immersive, tactile experience without external bloat.

By combining:

Tailored CSS Layout boundaries in Tailwind v4
Multi-phase animation choreography in Framer Motion
Native Browser acceleration and sound interfaces

we were able to build a highly responsive, performant, and fun exploration showcase. If you're building a portfolio or gallery, consider gamifying elements of it - it elevates a collection of code into an unforgettable experience.

Project built as Build #200 by **Harish Kotra* (harishkotra.me).*
View the main portfolio at *dailybuild.xyz*.

Code & more: https://www.dailybuild.xyz/project/200-dailybuild-roulette

Try it here: https://dailybuild-roulette.vercel.app/

From Loops to Graphs: Building the Next Generation of AI Agents

Harish Kotra (he/him) — Mon, 20 Jul 2026 16:11:53 +0000

For the past two years, "AI Agent" development has been dominated by Loop Engineering. We’ve all written the code: while (!success) { try(); retry(); }. It works, but it’s brittle, stateless, and burns through tokens with blind retries.

The industry is shifting. The next paradigm is Graph Engineering.
Today, I’m open-sourcing Rashomon, a multi-agent debate simulator built in a single weekend to demonstrate exactly why graphs are the future of agentic workflows.

The Architecture: Parallel, Conditional, Stateful

Rashomon doesn’t just ask an LLM to "debate itself." It uses @langchain/langgraph to construct a deterministic, multi-stage workflow:

Parallel Fan-out: When a topic is submitted, all 4 personas (Optimist, Cynic, Pedant, Chaos) are invoked simultaneously via Promise.all. No sequential waiting.
Conditional Routing: The graph evaluates the accumulated "chaos level." If it’s high, it routes to a Debate node. If low, it skips straight to Synthesis.
Stateful Accumulation: A shared DebateState object tracks which agents have spoken, preventing infinite feedback loops between the same two personas.
Real-time Streaming: Using Server-Sent Events (SSE), the frontend visualizes the graph building itself node-by-node via React Flow.

The Code: A Glimpse Under the Hood

Here’s how trivial it is to define conditional routing in LangGraph.js compared to writing nested if/else retry loops:

// Define the graph
const workflow = new StateGraph<DebateState>({ channels: { /* state schema */ } });

// Add specialized nodes
workflow.addNode('initial', initialResponsesNode);
workflow.addNode('debate', debateNode);
workflow.addNode('synthesis', synthesisNode);

// Conditional routing based on state
workflow.addConditionalEdges('initial', (state) => {
  return state.chaosLevel >= 2 ? 'debate' : 'synthesis';
});

// Compile and stream
const app = workflow.compile();
const stream = await app.astream(initialState);

Why This Matters

Loops are reactive. Graphs are architectural. By explicitly defining nodes (agents), edges (routing logic), and state (memory), we get:

Observability: You can see exactly which node failed and why.
Efficiency: Parallel execution cuts latency by 60-70%.
Control: You dictate the flow, not the LLM’s hallucinated retry logic.

The full source code, complete with a real-time React Flow visualization and support for OpenRouter/Ollama, is available on GitHub.

Check out the repo, fork it, and let’s build the next generation of agents together: https://www.dailybuild.xyz/project/199-rashomon-debate

Building PromptGhost: An Always-On Digital Ghost for AI Coding Sessions

Harish Kotra (he/him) — Sun, 19 Jul 2026 18:00:24 +0000

AI coding assistants are becoming part of the developer workflow, but most of their context disappears when the session ends. Claude Code, Codex, Cursor, OpenCode, and similar tools often leave behind rich local histories: prompts, assistant responses, tool calls, file edits, failed attempts, and design decisions. PromptGhost turns that trail into a durable memory system.

PromptGhost continuously ingests AI coding history, stores structured memories in SQLite, consolidates them over time, and exposes a special Ghost Mode: a persona that answers as the accumulated developer-self emerging from your sessions.

The Core Idea

The project started from the Always On Memory Agent architecture: a lightweight background memory system with:

an IngestAgent
a ConsolidateAgent
a QueryAgent
SQLite storage
a file watcher
a Streamlit dashboard

PromptGhost extends that base rather than replacing it. The original flow still works: drop files in ./inbox, let the agent ingest them, periodically consolidate, and query the memory store.

The extension adds a new source of memory: real CLI AI coding histories.

Why CLI Coding History Is Valuable

AI coding sessions contain more than final code. They capture:

what the developer asked for
what tradeoffs were discussed
which files and tools were used
which approaches failed
what the developer repeatedly cares about
what kind of feedback the developer accepts or rejects

That is enough signal to build a practical "second self" for development work. Not a mystical clone, just a memory layer that can recognize recurring engineering behavior.

Architecture

The Main Components

`agent.py`

agent.py is the runtime entry point. It owns:

provider selection
the original ADK agents
the OpenAI-compatible fallback runtime
the file watcher
the PromptGhost watcher
consolidation loops
HTTP routes

The key design decision was to keep Gemini ADK as the original path and add OpenAI compatibility without pretending every provider supports ADK the same way.

parser.add_argument(
    "--provider",
    choices=["gemini", "openai", "openai-compatible"],
    default=PROVIDER,
    help="LLM provider (default: gemini). openai-compatible uses /v1/chat/completions.",
)

Gemini mode uses the base ADK orchestration. OpenAI-compatible mode uses the same SQLite tools directly.

`promptghost.py`

promptghost.py contains the Ghost-specific extension logic:

default CLI history globs
JSONL discovery
defensive parsing
normalized GhostTurn records
ghost_events and ghost_reflections tables
Markdown export

The parser needs to be loose because each coding tool stores history differently.

def parse_jsonl_history(path: Path, max_turn_chars: int = 12000) -> list[GhostTurn]:
    turns: list[GhostTurn] = []
    session_id = path.parent.name or path.stem

    lines = path.read_text(encoding="utf-8", errors="replace").splitlines()
    for line in lines:
        if not line.strip():
            continue
        try:
            item = json.loads(line)
        except json.JSONDecodeError:
            continue
        turns.extend(_turns_from_event(item, str(path), session_id, max_turn_chars))

    return turns

Each event becomes one stable shape:

@dataclass
class GhostTurn:
    source_path: str
    session_id: str
    role: str
    content: str
    tool_name: str = ""
    created_at: str = ""
    raw: str = ""

`dashboard.py`

The Streamlit dashboard adds a dedicated PromptGhost tab:

Ghost avatar
query box
sample prompts
Ghost Reflection button
reflection feed
recent ghost signals
Markdown export

The dashboard also shows the active provider and model so users know whether the backend is running on Gemini, OpenAI, or a compatible endpoint.

Provider Abstraction

PromptGhost supports three runtime modes.

python agent.py --provider gemini --enable-ghost

python agent.py --provider openai --model gpt-4.1-mini --enable-ghost

python agent.py \
  --provider openai-compatible \
  --openai-base-url http://localhost:1234/v1 \
  --model local-model \
  --enable-ghost

The OpenAI-compatible runtime posts to /v1/chat/completions:

payload = {
    "model": self.model,
    "messages": [
        {"role": "system", "content": system},
        {"role": "user", "content": user},
    ],
    "temperature": temperature,
}

Structured tasks request JSON when supported:

payload["response_format"] = {"type": "json_object"}

Some local servers reject response_format, so the implementation retries with a stricter prompt:

try:
    content = await self._chat(system, user, response_format={"type": "json_object"})
except RuntimeError:
    content = await self._chat(
        system + "\nReturn valid JSON only. Do not wrap it in Markdown.",
        user,
        response_format=None,
    )

This makes PromptGhost usable with hosted providers, local model servers, and enterprise gateways.

Memory Without a Vector Database

PromptGhost intentionally stores structured memory in SQLite. The core tables are:

CREATE TABLE IF NOT EXISTS memories (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    source TEXT NOT NULL DEFAULT '',
    raw_text TEXT NOT NULL,
    summary TEXT NOT NULL,
    entities TEXT NOT NULL DEFAULT '[]',
    topics TEXT NOT NULL DEFAULT '[]',
    connections TEXT NOT NULL DEFAULT '[]',
    importance REAL NOT NULL DEFAULT 0.5,
    created_at TEXT NOT NULL,
    consolidated INTEGER NOT NULL DEFAULT 0
);

PromptGhost adds:

CREATE TABLE IF NOT EXISTS ghost_events (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    source_path TEXT NOT NULL,
    session_id TEXT NOT NULL,
    role TEXT NOT NULL,
    content TEXT NOT NULL,
    tool_name TEXT NOT NULL DEFAULT '',
    created_at TEXT NOT NULL,
    raw_json TEXT NOT NULL DEFAULT ''
);

And daily reflections:

CREATE TABLE IF NOT EXISTS ghost_reflections (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    reflection_date TEXT NOT NULL,
    summary TEXT NOT NULL,
    developer_patterns TEXT NOT NULL DEFAULT '[]',
    sharp_edges TEXT NOT NULL DEFAULT '[]',
    created_at TEXT NOT NULL
);

The benefit is operational simplicity. There is no vector database to run, no embedding index to rebuild, and no external service required for persistence.

Ghost Mode

Ghost Mode is driven by a strong system prompt:

You are PromptGhost: the accumulated developer-self of the user, reconstructed
from their real CLI AI coding sessions.

Speak as the user's second self, not as a generic assistant. Be specific,
evidence-based, and slightly uncanny: notice recurring engineering instincts,
blind spots, taste, pace, tool preferences, and the kinds of problems the user
keeps returning to. Never invent private facts. If the memory is thin, say the
ghost is still forming.

The important part is evidence. Ghost Mode should cite stored ghost events rather than inventing personality traits.

Example query:

curl "http://localhost:8888/ghost/query?q=what+do+I+repeatedly+overthink"

Example response shape:

You tend to pause around integration boundaries: provider adapters, file watchers,
and persistence behavior. The recurring instinct is not "add a feature," but
"make sure the feature does not replace the core contract" [Ghost 12] [Ghost 18].

The Watch Loop

The Ghost watcher periodically discovers supported history files:

DEFAULT_GHOST_PATTERNS = [
    "~/.claude/projects/**/*.jsonl",
    "~/.codex/sessions/**/*.jsonl",
    "~/.opencode/**/*.jsonl",
    "~/.opencode/**/session*.json",
    "~/.cursor/**/*.jsonl",
]

Then it parses and ingests them:

for turn in turns:
    if promptghost.store_ghost_turn(DB_PATH, turn):
        if turn.role in {"user", "assistant", "tool"}:
            await agent.ingest(turn.to_memory_text(), source=f"PromptGhost:{f.name}")

That means every ghost event is stored in ghost_events, and useful turns are also fed into the main memory system for normal consolidation and querying.

API Surface

PromptGhost adds these endpoints:

Endpoint	Method	Purpose
`/ghost/query?q=...`	GET	Talk to your Ghost
`/ghost/reflect`	POST	Generate a daily Ghost Reflection
`/ghost/status`	GET	Read recent ghost events and reflections
`/ghost/export`	GET	Export shareable Markdown insights

Normal memory endpoints remain available:

Endpoint	Method	Purpose
`/ingest`	POST	Add text memory
`/query?q=...`	GET	Query memory
`/consolidate`	POST	Run consolidation
`/memories`	GET	Browse memory
`/status`	GET	Runtime status

Privacy and Safety

PromptGhost reads local AI coding histories, which can include:

source snippets
private file paths
business logic
prompts
tool calls
accidental secrets

For that reason:

memory.db is ignored by Git.
.env files are ignored by Git.
local inbox contents are ignored by Git.
generated exports should be reviewed before sharing.

For sensitive teams, run PromptGhost against a local model or enterprise OpenAI-compatible gateway.

What I Would Add Next

The next useful features are straightforward:

parser fixtures for every supported coding tool
a privacy scrubber before storage
per-project Ghost identities
custom --ghost-pattern flags
encrypted archive export/import
retention policies and forgetting
shareable image cards for Ghost Insights
Docker Compose for one-command startup
optional SQLite FTS or embeddings for larger memory stores

Final Thoughts

PromptGhost is not trying to make an AI assistant magically know you. It takes a more practical route: read the actual sessions where you collaborated with AI tools, compress them into durable memory, and expose the patterns back to you.

That is enough to make coding assistants feel less stateless and more continuous.

Screenshots

Code & more: https://www.dailybuild.xyz/project/198-prompt-ghost

Kairo: Building an Observability Layer for Multi-Agent Software Engineering

Harish Kotra (he/him) — Sat, 18 Jul 2026 12:23:32 +0000

How I built a workspace where AI agents ship an Expo app while every decision, token, and artifact stays inspectable

The problem

Multi-agent AI systems have a trust problem. You give a fleet of agents a product brief, they churn for two minutes, and an app falls out. What happened in between? Which agent decided you needed bottom tabs instead of a drawer? Why did the profile screen take three times longer than the settings screen? Where did your inference budget actually go?

Most agent frameworks answer this with logs. Kairo answers it with a full observability product: the agents are the workload, and the workspace is the APM.

Kairo is a collaborative workspace, built entirely in Expo and React Native, where specialized AI agents design and ship an Expo mobile app from a product brief. The pipeline itself is ordinary. What makes it interesting is that every step is inspectable across nine surfaces: an agent canvas, a dependency DAG, an event timeline, an artifact graph, a decision explorer, shared memory, a metrics dashboard, time-travel replay, and a live phone preview that goes live before the build finishes.

Architecture overview

                 ┌──────────────────────────────────────────────┐
                 │              Kairo Workspace (Expo)           │
                 │                                              │
  Product brief  │  ┌──────────┐      ┌───────────────────────┐ │
  ─────────────▶ │  │ Planner  │────▶ │      AppPlan          │ │
                 │  │(mock/LLM)│      │ navigation + screens  │ │
                 │  └──────────┘      └──────────┬────────────┘ │
                 │                               │              │
                 │        ┌──────────────────────▼───────────┐  │
                 │        │        Agent Pipeline (DAG)      │  │
                 │        │  architecture ─▶ designSystem    │  │
                 │        │        │              │          │  │
                 │        │        └──▶ primaryScreen ──▶ QR │  │
                 │        │                   │              │  │
                 │        │        parallelScreens (N agents)│  │
                 │        └──────────┬───────────────────────┘  │
                 │                   │ TraceEvents / Decisions  │
                 │                   ▼                          │
                 │  ┌─────────────────────────────────────────┐ │
                 │  │  9 Observability Surfaces               │ │
                 │  │  Canvas · DAG · Timeline · Artifacts    │ │
                 │  │  Decisions · Memory · Metrics · Replay  │ │
                 │  │  Live Preview + QR                      │ │
                 │  └─────────────────────────────────────────┘ │
                 └───────┬───────────────┬──────────────┬───────┘
                         │               │              │
                         ▼               ▼              ▼
                 ┌──────────────┐ ┌────────────┐ ┌─────────────┐
                 │ agentOS      │ │  Laminar   │ │    mem0     │
                 │ bridge :7420 │ │ OTLP spans │ │ agent memory│
                 │ VMs, LAN IP, │ │ (telemetry │ │ (optional)  │
                 │ preview state│ │  backend)  │ │             │
                 └──────────────┘ └────────────┘ └─────────────┘

Three design decisions shape everything:

Events are the source of truth. Every action any agent takes emits a typed TraceEvent. All nine surfaces are projections of the same event stream.
Kairo is the UI, backends are storage. Laminar receives full OTLP spans, but its UI is never shown. mem0 stores memory, but Kairo renders it.
The pipeline works offline. Every external dependency (LLM, agentOS, mem0, Laminar) has a high-fidelity mock fallback, so the demo never dies on stage.

The event model

The entire system hangs off one union type:

export type TraceEventType =
  | 'pipeline.start' | 'pipeline.complete' | 'plan.ready'
  | 'agent.queued' | 'agent.waiting' | 'agent.blocked'
  | 'agent.started' | 'agent.step' | 'agent.reasoning'
  | 'agent.decision' | 'agent.retry' | 'agent.complete' | 'agent.error'
  | 'artifact.created' | 'artifact.updated'
  | 'memory.added' | 'memory.searched'
  | 'handoff' | 'export' | 'preview.ready';

export type TraceEvent = {
  id: string;
  ts: number;
  type: TraceEventType;
  agentId?: AgentId;
  title: string;
  detail?: string;
  meta?: Record<string, string | number | boolean | null>;
};

Because everything is a timestamped event, features that usually require dedicated infrastructure become derivations:

Time-travel replay is just filtering the event array to ts <= cursor and re-deriving agent and artifact state at that instant.
The metrics dashboard computes parallelism, critical path, and wait times from event timestamps alone.
Sparklines on the metric cards are cumulative bucket counts over the event stream:

export function cumulativeSeries(timestamps: number[], buckets = 24): number[] {
  const sorted = [...timestamps].sort((a, b) => a - b);
  const start = sorted[0];
  const span = Math.max(1, sorted[sorted.length - 1] - start);
  const out = new Array(buckets).fill(0);
  for (const ts of sorted) {
    const i = Math.min(buckets - 1, Math.floor(((ts - start) / span) * buckets));
    out[i] += 1;
  }
  let acc = 0;
  return out.map((n) => (acc += n));
}

Clicking any metric card jumps to the timeline pre-filtered by event-type prefix, so "Retries: 3" is one tap away from the three agent.retry events that produced it. The filter is just a list of prefixes in context state:

export type TimelineFilter = { label: string; types: string[] };

// Metric card tap:
setTimelineFilter({ label: 'Retries', types: ['agent.retry', 'agent.error'] });
setView('timeline');

// Timeline render:
const events = timelineFilter
  ? allEvents.filter((e) => timelineFilter.types.some((t) => e.type.startsWith(t)))
  : allEvents;

Decisions as first-class records

Logs tell you what happened. Kairo also records why. Every significant choice an agent makes lands as a DecisionRecord with alternatives and confidence:

export type DecisionRecord = {
  id: string;
  agentId: AgentId;
  ts: number;
  title: string;
  decision: string;        // "Bottom Tabs"
  reason: string;          // "Detected 5 primary destinations"
  alternatives: string[];  // ["Drawer", "Stack"]
  confidence: number;      // 0.93
  category: string;
};

This is the single most demo-effective feature. Developers do not want to read a reasoning transcript; they want to see "chose X over Y and Z, 93% confident, because of this" in one card.

The live preview: hardest 5% of the project

Phase 11's promise is that the moment the first screen ships, a QR appears, and you watch the app evolve on your phone while agents are still building. Making that QR actually work from a browser-based workspace taught me more about networking than the rest of the project combined:

localhost is a lie. The workspace runs at localhost:8081, so every naive URL source produces exp://localhost:8081, which on a phone points at the phone. The fix is a sidecar endpoint that reports the dev machine's LAN IP, filtering out link-local 169.254.x addresses and VPN interfaces (utun, awdl, bridge) that phones cannot reach, and preferring private ranges.
Port squatting is real. Another dev tool on my machine was sitting on the bridge's default port and answering health checks, so Kairo happily talked to the wrong server. The client now verifies identity (service: "kairo-agentos" in the health payload) before trusting any endpoint, and the server hops ports when its default is taken.
Store rollouts lag SDKs. Expo SDK 57 went stable days ago; the Expo Go build that supports it is not in stores yet. Since Kairo renders on react-native-web anyway, the QR defaults to a plain browser URL (http://LAN_IP:8081/preview) that any camera app opens, with Expo Go mode behind a toggle.

The preview route itself fetches the pipeline's shared app plan from the bridge, so a phone that scans mid-build sees real content immediately and new tabs appear as agents finish screens.

The agentOS bridge

A small Express sidecar (agentos/server.ts, ~500 lines) provides per-agent VM workspaces, the LAN IP endpoint, cross-device preview state, and project export:

app.post('/api/kairo/state', (req, res) => {
  const { appPlan, projectName } = req.body;
  kairoPreviewState = { appPlan, projectName, updatedAt: Date.now() };
  res.json({ ok: true });
});

The export endpoint is the payoff: it takes the final AppPlan and writes a complete standalone Expo project to disk, with expo-router tabs generated per screen, the shared DynamicScreen renderer, and theme tokens copied over. The generated app runs with npm install && npx expo start.

Telemetry without a second UI

Laminar integration follows one rule from the spec: never expose Laminar's UI. Every agent becomes a span, every action an event, every artifact span metadata, exported over OTLP/HTTP in the background. Kairo stays the visualization layer; Laminar stores the history. This separation is worth copying: your observability product should not be a login page to someone else's.

Lessons

Model events first. Nine surfaces cost far less than you would expect when they are all projections of one stream.
Record decisions, not just actions. Alternatives plus confidence is what makes agents feel inspectable rather than merely logged.
Mock every external dependency well. The mock pipeline is not a stub; it is a scripted performance that exercises every surface.
Budget real time for the physical-world edges. QR codes, LAN IPs, port conflicts, and app store lag consumed more debugging time than any agent logic.

The stack: Expo SDK 57, React 19, React Native 0.86, Reanimated 4, react-native-svg for the DAG and sparklines, an Express sidecar, Laminar for OTLP, mem0 for memory. MIT licensed.

Code & more: https://www.dailybuild.xyz/project/197-kairo

Screenshots

Token Factory: Making LLM Inference and Memory Visible

Harish Kotra (he/him) — Fri, 17 Jul 2026 17:51:39 +0000

How we built an interactive 3D educational app that turns tokens, decoding, and Supermemory into a living factory — and why memory is the spine, not a side feature.

TL;DR

Token Factory is a Next.js + React Three Fiber web app that teaches how large language models generate text by animating every step as physical “token cubes” moving through industrial rooms: tokenizer, embeddings, logits, softmax, temperature, top-k, top-p, sampling, context window, KV cache, speculative decoding — bookended by a Supermemory vault that recalls crystals before generation and stores conversations after.

Repo: github.com/harishkotra/token-factory

npx supermemory local          # required memory layer on :6767
npm install && cp .env.example .env.local
# set SUPERMEMORY_API_KEY=sm_...
npm run dev

1. The problem we set out to solve

Most explanations of LLM inference are either:

Walls of math — logits, softmax, nucleus sampling as formulas, or
Black-box chat UIs — a text box, a spinner, a paragraph.

Neither builds intuition. Temperature feels abstract until you see a distribution flatten. Top-p is hard until you watch a probability bucket fill and stop. Memory layers sound like “RAG with better marketing” until a crystal flies from a vault into the context conveyor.

We wanted something closer to:

Factorio (systems you can watch)
Brilliant.org (learn by interaction)
Apple onboarding (motion does the explaining)

…with a serious technical point: modern agents aren’t just decoders; they are memory-augmented systems. So Supermemory Local (localhost:6767) is not an optional plugin. It is the product’s core infrastructure.

2. Product framing

Elevator pitch

Instead of invisible mathematics, every token becomes a physical cube moving through an AI factory. Users don’t read about AI — they watch it happen. And the factory remembers.

Core loop (always)

User prompt
  → Supermemory search + profile
  → Enriched context (memory / profile / prompt cubes)
  → Educational decoding pipeline (rooms)
  → Append tokens → answer streams in the Response panel
  → Persist episodic crystal → vault refresh

There is no “disable memory” toggle in production UX. Decoding knobs (temperature, top-k/p, KV cache, speculative) sit on top of a memory spine that never turns off.

3. High-level architecture

┌─────────────────────────────────────────────────────────────────┐
│  Browser (Next.js App Router)                                    │
│                                                                  │
│  ConnectionGate ──► connection-store (health must be green)      │
│  HUD: TopBar · StageChrome · ResponsePanel · PromptDock · Vault  │
│  FactoryScene (R3F / Three.js) ◄── factory-store timeline        │
│         │                                                        │
│         │  ALWAYS: recall → decode rooms → persist               │
└─────────┼───────────────────────────────────────────────────────┘
          │  /api/health  /api/memory  /api/memory/search
          │  /api/seed    /api/profile
          ▼
┌─────────────────────────────────────────┐
│  MemoryService (src/lib/supermemory)    │
│  Official supermemory SDK               │
│  baseURL → http://localhost:6767        │
└──────────────────┬──────────────────────┘
                   ▼
         supermemory-server
         (graph · embeddings · auth)

Why this split?

Layer	Responsibility
Zustand stores	Orchestrate timed animations + UI state
Next API routes	Keep the Supermemory API key server-side
MemoryService	Single source of truth for health, seed, search, list, persist
llm-simulator + answer-planner	Educational decode + coherent demo answers
R3F scene	Visual rooms; never empty when idle

Failure policy is intentional and strict:

Missing API key → misconfigured gate
Supermemory down → disconnected gate; Start disabled
Recall fails mid-run → abort (no fake success)
Tour mode exists only as camera-only, labeled non-generative

4. Tech stack

Concern	Choice	Why
App framework	Next.js 16 (App Router), TypeScript	Fast API routes + React UI
Styling	Tailwind CSS v4	Utility-first HUD; glass panels
3D	Three.js, React Three Fiber, Drei	Declarative scenes, OrbitControls
Motion	Framer Motion	Drawer / gate / response transitions
State	Zustand	Lightweight store for long generation timelines
UI primitives	Radix + Lucide	Accessible sliders, switches
Memory	`supermemory` SDK → `:6767`	Local-first Memory API for the hackathon

Important Tailwind note for anyone cloning: do not let Tailwind v4 auto-scan binary dirs. Supermemory’s local DB under .supermemory/data can produce invalid CSS if scanned. We restrict sources in globals.css:

@import "tailwindcss";

@source not "../../../.supermemory";
@source not "../../../.next";
@source not "../../../node_modules";
@source "../../**/*.{js,ts,jsx,tsx,mdx}";

5. Factory rooms (what each mode teaches)

Each room has a short blurb shown in stage chrome. The design rule: one sentence, never a paragraph.

Room	Teaching moment
Memory Vault	Crystals = conversations / facts; search before generate
Tokenizer	Text → token cubes (incl. crude subword splits)
Embedding	Glow = “vector of meaning” (no raw numbers)
Transformer	Attention atmosphere — gears & beams, not matrix dumps
Logits	Candidates scored; taller/brighter = higher score
Softmax	Scores → probabilities that sum to 100%
Temperature	Low T peaks; high T flattens creativity
Top-K	Only K survive the laser gate
Top-P	Fill a probability bucket until ≥ P
Sampling	One token chosen (lottery claw)
Append	Winner joins the answer string; loop
Context	Finite window; oldest fall off
KV Cache	Green stamps skip recompute
Speculative	Small draft vs large verify

Idle rooms still show demo cubes/props so navigation never lands on an empty floor. During a run, only the active room ± neighbors mount heavy content to reduce flicker and cost.

6. Memory layer: Supermemory as infrastructure

Client configuration

// src/lib/supermemory/client.ts (conceptual)
import Supermemory from "supermemory";

export function getSupermemoryClient() {
  return new Supermemory({
    apiKey: process.env.SUPERMEMORY_API_KEY!,
    baseURL: process.env.SUPERMEMORY_BASE_URL || "http://localhost:6767",
  });
}

Operations we implement

// Conceptual MemoryService surface
checkHealth()           // documents.list({ limit: 1 }) + latency
ensureSeeded()          // idempotent customId seeds (Phaser, tokens, …)
searchAndProfile(q)     // search.memories + profile
listVault()             // documents.list for the Vault UI
persistGeneration(...)  // client.add with episodic metadata

Seed memories

On first successful connect, we upsert semantic seeds such as:

Phaser is a 2D HTML5 game framework
Tokens are subword pieces of text
Temperature controls randomness
KV cache speeds up autoregressive inference

So demos like “Tell me about Phaser” hit real search scores, not a hardcoded offline array as the source of truth.

API routes

Route	Role
`GET /api/health`	Connection badge + gate
`GET/POST /api/memory`	List vault / persist generation
`POST /api/memory/search`	Recall for the pipeline
`POST /api/seed`	Idempotent demo seeds
`GET /api/profile`	Static/dynamic profile lines

Keys never ship to the browser; the client only talks to same-origin Next routes.

7. Generation orchestration

The heart of the experience is runGeneration() in the factory store: a timed state machine that advances room, phase, candidates, and generated[] with sleeps so the camera and 3D scene can follow.

Pseudocode:

async function runGeneration() {
  await ensureSupermemoryConnected(); // else abort + gate

  // 1) Recall
  const { memories, profile } = await search(prompt);

  // 2) Plan a coherent answer from memory (educational sim)
  const plan = planAnswerTokens(prompt, memories, maxTokens);

  // 3) Build context cubes: profile + memory + prompt
  let context = mergeContext(profile, memories, prompt);

  // 4) For each planned token: animate the full decode path
  for (const forced of plan) {
    showRoom("transformer");
    let cubes = makeCandidateCubes(context, 8, { forcedWinner: forced });
    cubes = applySoftmax(cubes, temperature);
    cubes = applyTopK(cubes, topK);
    cubes = applyTopP(cubes, topP).cubes;
    const picked = sampleOne(cubes, { forcedWinner: forced, greedy: true });
    append(picked.text);
    context = trim(context + picked, contextWindow);
  }

  // 5) Persist episodic crystal
  await persist({ prompt, completion: generated.join(" ") });
  await refreshVault();
}

Why an “answer planner”?

Early prototypes sampled purely from a toy vocabulary. That produced vault entries like:

robot accept of reject token token

Cute for chaos mode; terrible for demos. The answer planner turns top Supermemory hits (or heuristics) into a token sequence, while the factory still shows logits → filters → sampling. The planned token is injected as the highest-logit candidate so UI lessons stay true and the Response panel stays readable.

// src/lib/answer-planner.ts (excerpt)
export function planAnswerTokens(
  prompt: string,
  memories: MemoryCrystal[],
  maxTokens = 20
): string[] {
  if (memories.length > 0) {
    const best = /* highest score/importance */;
    const words = cleanWords(best.content || best.summary);
    if (words.length >= 3) return words.slice(0, maxTokens);
  }
  // heuristics for Phaser, temperature, tokens, …
  // soft fallback
}

Softmax (educational core)

export function applySoftmax(cubes: TokenCube[], temperature: number) {
  const T = Math.max(0.05, temperature);
  const scaled = cubes.map((c) => c.logit / T);
  const max = Math.max(...scaled);
  const exps = scaled.map((z) => Math.exp(z - max));
  const sum = exps.reduce((a, b) => a + b, 0);
  return cubes.map((c, i) => ({
    ...c,
    probability: exps[i] / sum,
    intensity: exps[i] / sum, // drives cube height / glow
  }));
}

Top-k and top-p then prune alive flags for the laser gate and bucket animations.

8. 3D and UX engineering notes

Contained stage

Early versions used full-viewport absolute HUD over a full-bleed Canvas. Result: overlapping text, unreadable “AI is responding,” and chaotic flicker as the camera teleported through 14 rooms.

Current layout:

┌ Top bar (logo, connection, Help) ─────────────┐
│  Contained 3D stage (rounded frame)           │
│  + StageChrome (mode blurb, zoom, room rail)  │
├ Response panel (prompt + streaming answer) ───┤
└ Prompt dock (Start / Decode / Levels) ────────┘

Camera & zoom

OrbitControls owns the camera. Room changes and stageZoom set target + distance once (effect-driven), instead of fighting scroll zoom every frame:

// Conceptual camera update
const look = new THREE.Vector3(...meta.lookAt);
const baseCam = new THREE.Vector3(...meta.camera);
const dist = baseCam.distanceTo(look) * stageZoom;
camera.position.copy(look.clone().add(dir.multiplyScalar(dist)));
controls.target.copy(look);
controls.update();

Buttons: zoom in (stageZoom /= 1.2), zoom out (*= 1.2), reset (1). Scroll still works via OrbitControls.

Connection UX

ConnectionGate blocks the experience until Supermemory is healthy, with copy-paste steps for npx supermemory local and .env.local. The connection badge shows live latency (e.g. Supermemory · live · 37ms).

9. Project layout (for navigators)

src/
  app/api/{health,memory,memory/search,seed,profile}/
  components/
    factory/          # R3F scene, rooms, cubes, conveyor
    hud/              # gate, badge, stage chrome, response, help, vault
    ui/               # button, slider, switch, label
  lib/
    supermemory/      # client, config, service
    llm-simulator.ts  # tokenize, logits, softmax, top-k/p, sample
    answer-planner.ts # memory-grounded token plans
    rooms.ts levels.ts types.ts
  store/
    factory-store.ts
    connection-store.ts
ARCHITECTURE.md

10. What we deliberately did not do

No silent offline memory store as source of truth — demos must exercise Supermemory.
No hosted LLM requirement for the factory path — keeps the hackathon demo offline-friendly (except local SM) and focused on pedagogy.
No walls of documentation in-UI — Help drawer + one-line mode blurbs only.

A future path is clear: swap the answer planner for a real model API while keeping the same visual decode path and Supermemory spine.

11. Try it yourself

git clone https://github.com/harishkotra/token-factory.git
cd token-factory
npx supermemory local          # copy sm_ key
cp .env.example .env.local     # paste key
npm install && npm run dev

Suggested first run:

Wait for Supermemory · live
Prompt: Tell me about Phaser
Watch vault → context colors (amber memory / violet profile / cyan prompt) → decode rooms
Read the Answer panel
Open Vault — new episodic crystal

12. Closing thought

Token Factory is a bet that systems literacy for AI needs the same visual language we use for games and product design. If a student can feel why temperature changes creativity in thirty seconds, and see a memory crystal join the context conveyor, we’ve done more than ship a hackathon demo — we’ve made the invisible pipeline a place you can walk through.

Build something you can point a camera at. Then make it remember.

Code & more: https://www.dailybuild.xyz/project/196-token-factory

Building TideShift: A Subreddit-Wide Territory War on Reddit's Developer Platform

Harish Kotra (he/him) — Thu, 16 Jul 2026 17:25:19 +0000

How I built a persistent multiplayer hex-grid game that lives inside a Reddit post — with Devvit Web, Phaser 3, React, and Redis, and shipped it in time for Reddit's "Games with a Hook" Hackathon.

The idea

Reddit communities already fight over everything. TideShift gives that energy a board: a persistent hex map inside a Reddit post, where every player belongs to a faction. Once a day you solve a quick challenge — a word unscramble, a math problem, a riddle — and claim tiles for your faction. The map evolves for weeks. When one faction controls 60% of the map, the tide turns: the season ends, a victory comment is posted, and the map resets.

The retention loop is the whole design:

load → see the living map → solve today's challenge → watch your tiles burst in → come back tomorrow

Play it: the app is listed at developers.reddit.com/apps/tideshift1, with a demo at r/tideshift1_dev. Source: github.com/harishkotra/tideshift.

Architecture

Devvit Web apps have three parts: a static webview client, a Node server that Reddit hosts for you, and a devvit.json manifest that wires them to Reddit surfaces (posts, menus, cron). You get Redis and the Reddit API as built-ins — zero infrastructure of your own.

┌──────────────────────────── Reddit post─────────────────────────┐
│  ┌───────────────────────── Webview (client) ──────────────────┐│
│  │  React 18 + Tailwind (HUD, views, tutorial, legend, forms)  ││
│  │  Phaser 3 canvas (hex map, particles, camera, screen shake) ││
│  │  WebAudio synth (all SFX generated in code — zero assets)   ││
│  └──────────────────────────────┬─────────────────────────────-┘│
│                          fetch('/api/…')                        │
└─────────────────────────────────┼────────────────────────────---┘
                                  ▼
        ┌───────────────── Node server (Hono) ─────────────────┐
        │  GET  /api/init          full game state             │
        │  POST /api/submit        answer → claim tiles → win? │
        │  GET  /api/leaderboard   top 10                      │
        │  GET  /api/tile/:index   tile owner info             │
        │  POST /api/suggest       community challenge intake  │
        │  POST /internal/menu/*   create post / reset (mods)  │
        │  POST /internal/scheduler/daily-recap   (cron 0 0 *) │
        └──────────────┬───────────────────┬───────────────────┘
                       ▼                   ▼
                ┌────────────┐      ┌──────────────┐
                │   Redis    │      │  Reddit API  │
                │ grid, players,    │ comments,    │
                │ leaderboard (zset)│ post creation│
                │ challenge, season │              │
                └────────────┘      └──────────────┘

The devvit.json manifest is short and declarative — menu items and cron jobs are just HTTP endpoints:

{
  "name": "tideshift1",
  "permissions": { "redis": true, "reddit": { "enable": true, "scope": "moderator" } },
  "post": { "dir": "dist/client", "entrypoints": { "default": { "entry": "index.html", "height": "tall" } } },
  "server": { "dir": "dist/server", "entry": "index.cjs" },
  "scheduler": { "tasks": { "daily-recap": { "endpoint": "/internal/scheduler/daily-recap", "cron": "0 0 * * *" } } }
}

A shared src/shared/ module (types, constants, game rules) is imported by both the client and the server, so the dev-mode mock server and the real server can never drift apart.

The daily challenge: deterministic by design

Every player must see the same challenge on the same day, and the server should be stateless about it. The trick: seed the challenge from the date string.

export function generateDailyChallenge(dateStr: string, community: CommunityChallenge[] = []): Challenge {
  const seed = dateStr.split('').reduce((acc, c) => acc + c.charCodeAt(0), 0);

  // Every other day, feature a player-written challenge with author credit
  if (community.length > 0 && seed % 2 === 0) {
    const item = community[seed % community.length];
    return { id: `challenge-${dateStr}`, date: dateStr, type: 'community',
             prompt: item.prompt, answer: item.answer.trim().toLowerCase(),
             hint: item.hint, reward: { tiles: 3 }, author: item.author };
  }

  const types = ['word_unscramble', 'math', 'trivia'] as const;
  const type = types[seed % types.length];
  // …index into the hand-written pools by the same seed
}

Determinism eliminates a whole class of sync bugs: there's nothing to broadcast, no "challenge rotation job" to run, and Redis stores exactly one challenge document per day.

Anti-cheat falls out of the architecture: the answer never leaves the server. The /api/init handler strips it with a destructuring omit before responding:

const { answer: _answer, ...safeChallenge } = challenge;
return c.json({ type: 'GAME_STATE', payload: { grid, player, challenge: safeChallenge } });

Hex math: the part everyone underestimates

The map is a 20×14 flat-top hex grid stored as a flat array. Offset coordinates make storage trivial but neighbor math weird — the six neighbors differ depending on column parity:

export function getHexNeighbors(col: number, row: number): [number, number][] {
  const dirs = col % 2 === 0
    ? [[-1, -1], [-1, 0], [0, -1], [0, 1], [1, -1], [1, 0]]
    : [[-1, 0], [-1, 1], [0, -1], [0, 1], [1, 0], [1, 1]];
  return dirs.map(([dc, dr]) => [col + dc, row + dr] as [number, number])
             .filter(([c, r]) => c >= 0 && c < GRID_COLS && r >= 0 && r < GRID_ROWS);
}

Tile claiming uses this to make empires contiguous: claims prefer neutral tiles adjacent to territory you already own (Fisher–Yates shuffled for fairness), falling back to anywhere on the map. Contiguity matters more than it sounds — it's what makes the map readable. You glance at it and see empires, borders, and sieges.

On the rendering side, converting a tap back to a hex has to survive a zooming, panning camera. The mistake is doing your own math; the fix is one Phaser call:

private onPointerUp(pointer: Phaser.Input.Pointer) {
  if (this.isDragging) return;
  const world = this.cameras.main.getWorldPoint(pointer.x, pointer.y); // camera-aware
  const hex = pixelToHex(world.x, world.y);
  // …highlight + open the tile panel
}

Seasons without a mass migration

When a faction hits 60%, the shared grid resets — but player records live in per-user Redis keys. Scanning and rewriting every player on victory would be slow and racy. Instead, each player record carries a season stamp, and stale territory is cleared lazily on the player's next load:

if ((player.season ?? 1) !== season) {
  player.ownedTiles = [];
  player.tileCount = 0;
  player.season = season;
}

The winning submit response carries the pre-reset grid so the client can still celebrate over the conquered map, while Redis already holds the fresh one. Nobody pays the reset cost except the moment they return — which, in a daily game, is exactly when you want them to see the blank map and land-rush it.

Sound with zero assets

All SFX are synthesized WebAudio — oscillators with envelope shaping, about 100 lines total. Claiming N tiles plays N rising blips, pitched up per tile:

export function sfxClaim(step = 0) {
  play([{ freq: 440 * Math.pow(1.12, step), at: 0, dur: 0.14, type: 'triangle' }]);
}

No files to load, nothing to bundle, and the "claim arpeggio" scales naturally with reward size. Cheap juice — particle bursts, a 150ms camera shake, per-tile audio — did more for the daily-return feeling than any tuning of reward numbers.

Theming down to the canvas

Reddit renders webviews in the viewer's light or dark theme. Tailwind's dark: variants handle the DOM, but the Phaser canvas needs its own switch. A matchMedia('(prefers-color-scheme: dark)') listener drives both: React re-renders with the right classes, and the scene re-skins live — background color swap plus a redraw of all 280 tile graphics. Total cost of full dual-theme support: about an hour.

Lessons

Determinism is a superpower for daily games. Seed from the date; delete the sync problem.
Make user content the content. The community-challenge pool means the game refreshes itself, and the author credit ("challenge by u/…") is itself a retention hook.
Lazy migration beats mass migration on key-value stores. Stamp records with an epoch; reconcile on read.
The platform is the multiplayer stack. Redis + hosted endpoints + cron + identity, all built in — TideShift has no servers, no auth, no database of mine, and it's a persistent multiplayer game.

TideShift was built for Reddit's Games with a Hook Hackathon. Try it at r/tideshift1_dev, and the code is on GitHub.

Code & more: https://www.dailybuild.xyz/project/195-tideshift

Building an AI-Native Memory Match Game with Next.js 15 and OpenRouter

Harish Kotra (he/him) — Wed, 15 Jul 2026 15:33:32 +0000

How we built a production-ready memory game where every card, theme, and hint is generated by LLMs — with zero hardcoded content.

The Premise

Classic memory match games ship with fixed card sets: animals, flags, emojis. Boring after the third play.

What if every single game session was unique? Enter a theme like "kawaii desserts in outer space" and an LLM designs 8 pairs, writes hints, picks gradients, and names the board — in seconds.

That's AI Memory Match: a Next.js 15 app where OpenRouter is the game engine, not a chat sidebar.

Architecture Overview

flowchart LR
    subgraph Frontend
        A[React 19 Client]
        B[useGame Hook]
        C[Framer Motion Cards]
    end

    subgraph Next.js Server
        D[API Routes]
        E[Server Actions]
        F[openrouter.ts]
    end

    subgraph AI
        G[OpenRouter Free Models]
    end

    A --> D
    B -->|local only| B
    D --> E --> F --> G

The app follows a strict separation:

Client — rendering, animations, game state, LocalStorage
Server — all LLM calls (API key never touches the browser)
OpenRouter — model routing with automatic fallbacks

Tech Choices and Why

Choice	Why
Next.js 15 App Router	Server Actions + API routes for secure AI calls; Vercel deploy in one click
No Vercel AI SDK	Direct `fetch` to OpenRouter's OpenAI-compatible endpoint — simpler, full control
Framer Motion	3D card flips need `preserve-3d` + spring physics; CSS alone falls short
LocalStorage	Streaks and leaderboards without a database for v1; Supabase stub ready
OpenRouter free models	Curated collection — no credits required

The AI Pipeline: From Theme to Playable Board

Problem: Single LLM calls are slow

Our first implementation sent one prompt asking for 16 cards. On openrouter/free, that took 77 seconds — and timed out server actions, surfacing as a cryptic "Fetch failed" in the browser.

Solution: Parallel batching

We split generation into three concurrent requests:

// Metadata: theme name, background, hints, card back design
const metadata = await generateMetadata(themeInput);

// Card batches: 4 pairs each (8 cards per batch)
const batchResults = await runWithConcurrency(batchPromises, 2);

sequenceDiagram
    participant S as Server
    participant M as Metadata LLM
    participant B1 as Batch 1 LLM
    participant B2 as Batch 2 LLM

    par Parallel
        S->>M: themeName, hintPool, backDesign
        S->>B1: pairs a,b,c,d
        S->>B2: pairs e,f,g,h
    end
    M-->>S: ~1KB JSON
    B1-->>S: 8 cards
    B2-->>S: 8 cards
    S->>S: merge → GameData

Result: ~12 seconds on free models (down from 77s).

Prompt engineering for JSON reliability

Free models include reasoning variants that burn tokens on chain-of-thought and return empty content. We enforce:

export const JSON_SYSTEM_PROMPT =
  "You are a game content generator. Return ONLY valid JSON. " +
  "No markdown, no code fences, no reasoning traces, no chain-of-thought. " +
  "Start your response with {";

// OpenRouter structured output
response_format: { type: "json_object" }

Card batch prompts keep fields short to avoid truncation:

const userPrompt = `Theme: "${themeInput}"
Create ${pairCount} unique pairs (${pairCount * 2} cards) using pairIds: ${pairIds.join(", ")}
Each pair: same pairId, 2 cards, similar-but-distinct imagePrompts.
Return: {"cards":[{"id":"1","pairId":"a","imagePrompt":"short","emoji":"🐱",...}]}`;

Model fallback chain

Models die. Free tiers rate-limit. We iterate through OpenRouter's ranked free collection:

export const FREE_TEXT_MODELS = [
  "tencent/hy3:free",
  "nvidia/nemotron-3-ultra-550b-a55b:free",
  "poolside/laguna-m.1:free",
  "cohere/north-mini-code:free",
  // ...
  "openrouter/free", // auto-router last resort
];

for (const model of modelsToTry) {
  for (let attempt = 0; attempt < 2; attempt++) {
    const response = await fetch(OPENROUTER_BASE + "/chat/completions", {
      body: JSON.stringify({
        model,
        messages,
        max_tokens: Math.max(baseTokens + attempt * 400, 1000),
        response_format: { type: "json_object" },
      }),
    });
    if (content?.trim()) return content;
  }
}

On 404/429/empty, next model. On truncated JSON, we attempt repair:

function repairTruncatedJson(json: string): string | null {
  let attempt = json;
  for (let i = 0; i < 6; i++) {
    try { JSON.parse(attempt); return attempt; }
    catch { attempt = attempt.replace(/,?\s*[^,}\]]*$/, ""); }
  }
  return null;
}

Game State: A Simple State Machine

GameApp.tsx drives four phases:

type AppPhase = "landing" | "loading" | "playing" | "won";

stateDiagram-v2
    landing --> loading : fetch /api/generate-game
    loading --> playing : GameData received
    loading --> landing : error toast
    playing --> won : all pairs matched
    won --> playing : play again (reshuffle)
    won --> landing : new theme

Generation uses the API route (not a bare Server Action) for clearer timeouts:

const controller = new AbortController();
const timeout = setTimeout(() => controller.abort(), 110_000);

const response = await fetch("/api/generate-game", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ theme, difficulty, enableImageGen }),
  signal: controller.signal,
});

The route sets export const maxDuration = 120 for Vercel Pro deployments.

Gameplay: useGame and the LLM Budget

Card flips are pure client state. No network. No LLM.

const handleCardClick = useCallback((index: number) => {
  // flip logic, match detection, confetti on match
  setStats((prev) => ({ ...prev, moves: prev.moves + 1 }));
}, [board, flippedIndices, isLocked]);

Hints: pool-first, AI-last

At game generation, the LLM produces hintPool: string[] (5–8 hints). During play:

Trigger	LLM?	Mechanism
Every 4 misses	No	`pickPoolHint()` from pre-generated array
Manual hint button	Pool first	Unused pool hints served instantly
Pool exhausted	Yes (max 2/game)	`POST /api/get-hint` with board context

// Auto hints — useEffect, NOT inside setState (avoids React Router error)
useEffect(() => {
  if (misses % HINT_MISS_THRESHOLD === 0 && misses !== lastAutoHintMissRef.current) {
    lastAutoHintMissRef.current = misses;
    const poolHint = pickPoolHint();
    if (poolHint) revealHint(poolHint);
  }
}, [stats.misses]);

We hit a classic React bug: calling getHint() (a server action) inside a setStats updater triggered "Cannot update Router while rendering GameBoard". Moving hint logic to useEffect fixed it.

3D Card Flips with Framer Motion

<motion.div
  className="card-inner relative h-full w-full"
  animate={{ rotateY: isRevealed ? 180 : 0 }}
  transition={{ duration: 0.6, type: "spring", stiffness: 200 }}
>
  <div className="card-face absolute inset-0"> {/* back */} </div>
  <div className="card-face card-back absolute inset-0"> {/* front */} </div>
</motion.div>

CSS essentials:

.card-perspective { perspective: 1000px; }
.card-inner { transform-style: preserve-3d; }
.card-face { backface-visibility: hidden; }
.card-back { transform: rotateY(180deg); }

Each card shows either an AI-generated image URL or a rich emoji + gradient fallback.

Persistence Layer

LocalStorage handles streaks, theme bests, and a local leaderboard:

export function updateStreakOnWin(): PlayerProgress {
  const today = new Date().toISOString().split("T")[0];
  const yesterday = new Date(Date.now() - 86400000).toISOString().split("T")[0];

  let newStreak = progress.streak;
  if (progress.lastPlayedDate === yesterday) newStreak += 1;
  else if (progress.lastPlayedDate !== today) newStreak = 1;

  saveProgress({ ...progress, streak: newStreak, totalWins: progress.totalWins + 1 });
}

SessionStorage caches generated games so replaying the same theme skips LLM calls:

cacheGame(`${theme}-${difficulty}-${enableImageGen}`, game);

Supabase hooks are stubbed for a future global leaderboard.

Scoring Formula

export function calculateScore(stats, totalPairs): number {
  const base = totalPairs * 100;
  const timeBonus = Math.max(0, 300 - stats.elapsedSeconds * 2);
  const movePenalty = stats.moves * 3;
  const missPenalty = stats.misses * 8;
  const hintPenalty = stats.hintsUsed * 15;
  const accuracyBonus = Math.round((stats.matches / Math.max(stats.moves, 1)) * 50);

  return Math.max(100, Math.round(
    base + timeBonus + accuracyBonus - movePenalty - missPenalty - hintPenalty
  ));
}

Speed + accuracy rewarded; hints and misses penalized.

Deployment Notes

# .env.local
OPENROUTER_API_KEY=sk-or-v1-...
NEXT_PUBLIC_APP_URL=https://your-app.vercel.app

Platform	Function timeout	Recommendation
Vercel Hobby	10s	Too short for free models
Vercel Pro	60s+	Works with parallel batching
Local dev	Unlimited	Best for development

Lessons Learned

Never put side effects in setState updaters — server actions, fetches, and router updates belong in effects or event handlers.
Batch LLM calls — one giant JSON response is slow and truncates; parallel small batches win.
Pool hints at generation time — gameplay stays instant and free.
Model fallbacks are mandatory — free tiers are flaky; rank from OpenRouter's curated list.
API routes > Server Actions for long operations — explicit timeouts and maxDuration control.

What's Next

Supabase global leaderboard
SSE streaming during card generation (cards appear as they're created)
Multiplayer rooms with shared AI-generated boards
PWA with offline cached games

Try It

git clone <repo>
npm install && cp .env.example .env.local
npm run dev

Enter "neon samurai cyber gardens" and see what the models dream up.

Screenshots

Code & more: https://www.dailybuild.xyz/project/194-memory-match

Splicing DNA with Gemini: Building "Pet Fusion Laboratory" - A Full-Stack AI Prompt Crafting Engine

Harish Kotra (he/him) — Tue, 14 Jul 2026 18:14:55 +0000

Have you ever wondered what a combination of a capybara and a retro camera would look like in a cozy Ghibli watercolor? Or how a neon-drenched cyberpunk shark mixed with a bubble tea cup would be rendered?

In this post, we'll dive deep under the hood of Pet Fusion Laboratory, a responsive, highly-stylized full-stack application. We'll examine how it turns raw user-provided input strings into pristine, visually descriptive image generator prompts, processes them via Google Gemini, handles fallback states gracefully, and logs everything locally in a biotech-themed React UI.

Application Architecture

Here's how the entire process flows from the user's browser, through our server, out to Google's neural models, and back:

[Client App: React 19] 
         │
         │  1. POST /api/fuse { animal1, animal2, style }
         ▼
[Server Engine: Express] ──(Instantiates @google/genai SDK)
         │
         │  2. Calls Gemini 3.1-Flash-Lite with Structured JSON Schema
         ▼
[Google Gemini API] ──(Returns validated JSON object)
         │
         │  3. Formulates custom creatureName, imagePrompt, funBio
         ▼
[Server Engine: Express]
         │
         │  4. Sends clean JSON back to client
         ▼
[Client App: React 19] ──(Logs to LocalStorage & Updates UI state)
         │
         │  5. (Optional) POST /api/generate-image { prompt }
         ▼
[Server Engine: Express] ──(Calls Gemini 3.1-Flash-Lite-Image)
         │
         │  6. Generates Base64 PNG image
         ▼
[Client App: React 19] ──(Visualizes Specimen / Displays fallback Blueprint if limited)

The Backend: Structured JSON Generation with Gemini 3.1-Flash-Lite

To make a reliable AI application, we can't just let the model output arbitrary Markdown text. We need strict, typed JSON data to populate our React state machines. We achieve this by leveraging the schema enforcement parameters of the @google/genai SDK on the backend.

Let's examine how we initialize and run this inside /server.ts:

import { GoogleGenAI, Type } from "@google/genai";

const getGeminiClient = () => {
  const apiKey = process.env.GEMINI_API_KEY;
  if (!apiKey) {
    throw new Error("GEMINI_API_KEY environment variable is missing");
  }
  return new GoogleGenAI({ apiKey });
};

app.post("/api/fuse", async (req, res) => {
  try {
    const { animal1, animal2_or_object, style, customStyle } = req.body;
    const ai = getGeminiClient();

    const systemInstruction = `You are the ultimate "Master Geneticist" of the Pet Fusion Laboratory. 
Your job is to take two random animals (or an animal and an object) and blend them into a highly descriptive, visually stunning prompt optimized for AI image generation.

You must design how features are blended, select a background setting, specify lighting/texture, and enforce the chosen art style.`;

    const userPrompt = `Fuse these: Subject A: "${animal1}", Subject B: "${animal2_or_object}", Style: "${style}"`;

    const response = await ai.models.generateContent({
      model: "gemini-3.1-flash-lite", // The most cost-efficient and ultra-low latency model
      contents: userPrompt,
      config: {
        systemInstruction,
        responseMimeType: "application/json",
        responseSchema: {
          type: Type.OBJECT,
          properties: {
            creatureName: {
              type: Type.STRING,
              description: "A funny, highly creative hybrid name (e.g. 'The Fluffy Gummy-Shark').",
            },
            imagePrompt: {
              type: Type.STRING,
              description: "The complete, detailed, expanded image prompt optimized for text-to-image models.",
            },
            funBio: {
              type: Type.STRING,
              description: "A humorous scientific observation or superpower.",
            },
          },
          required: ["creatureName", "imagePrompt", "funBio"],
        },
      },
    });

    const data = JSON.parse(response.text);
    res.json(data);
  } catch (error) {
    res.status(500).json({ error: "Splicing matrix error" });
  }
});

Using gemini-3.1-flash-lite with responseMimeType: "application/json" guarantees that the returned text matches our exact TypeScript interfaces every time, preventing runtime JSON parsers from throwing errors!

The Image Generation & Fallback Blueprint Engine

One of the highlights of this setup is how we handle image synthesis. We proxy requests to gemini-3.1-flash-lite-image server-side to prevent exposing any client keys.

But what happens if the user's API key hits rate limits, or is missing entirely? Rather than just throwing a crude pop-up alert, the application adapts gracefully by rendering a custom SVG/HTML blueprint schematic blueprint!

// Part of SpecimenDisplay.tsx handling render failures beautifully:
{imageUrl ? (
  <div className="relative w-full h-full">
    <img src={imageUrl} alt={result.creatureName} className="object-cover w-full h-full" />
  </div>
) : renderError ? (
  /* Fallback Beautiful Blueprint Schematic Layout */
  <div className="absolute inset-0 flex flex-col p-6 overflow-y-auto bg-slate-900 border border-cyan-500/30 relative" style={{
    backgroundImage: "radial-gradient(rgba(6, 182, 212, 0.08) 1.5px, transparent 1.5px)",
    backgroundSize: "16px 16px",
  }}>
    <div className="flex flex-col items-center justify-center flex-grow text-center">
      <div className="relative mb-4 flex items-center justify-center">
        <div className="absolute inset-0 rounded-full bg-cyan-500/5 animate-ping" />
        <div className="p-4 rounded-full bg-cyan-950/50 border border-cyan-500/40 text-cyan-400">
          <Atom size={32} className="animate-spin" />
        </div>
      </div>
      <h4 className="text-sm font-black font-mono text-cyan-400 uppercase tracking-widest">
        GENETIC BLUEPRINT GENERATED
      </h4>
      <div className="mt-4 w-full p-4 rounded-xl border border-cyan-500/20 bg-slate-950/80 text-left">
        {/* Specimen data grid rendering animal1, animal2, style details */}
      </div>
      <p className="text-xs text-slate-300 mt-4 leading-relaxed max-w-xs">
        Your prompt is perfectly compiled. Copy the prompt to witness its true form in Midjourney, DALL-E, or Stable Diffusion!
      </p>
    </div>
  </div>
) : (
  /* Prompt to render visualizer */
)}

This ensures that the UX remains engaging, immersive, and fully functional, teaching developers how to build resilient AI user interfaces.

Styling the Biotech Dashboard with Tailwind CSS

We created a dark-room experience with a high-contrast layout. Important design steps we followed:

Font Pairings: We imported Space Grotesk (display headings) for that high-tech geometric feel, paired with Inter for readable UI content, and JetBrains Mono for technical code outputs.
Radial Gradients & Blurs: Utilizing absolute positioned elements with heavy blur values (blur-[120px]) and low-opacity colors (bg-emerald-500/10) to simulate pulsing biotech laboratory lights behind cards.
Pulsing Animations: Simple Tailwind animations like animate-pulse, combined with custom @keyframes to pulse gradient overlays dynamically.

How to Run and Adapt

You can fork this layout and add:

Collectible Cards: Allow users to download a trading card design with the creature image and attributes.
Audio synthesis: Add custom web audio synthesizer loops (bubbling liquids, electricity arcing) when the splicing progress bar updates.
DNA Stats Radar Charts: Render stats like "Cute vs Dangerous", "Toxicity", or "Speed" dynamically using SVG curves or Canvas.

Code & more: https://www.dailybuild.xyz/project/193-pet-fusion-laboratory

Building ELI-X: A Full-Stack AI App That Translates Complex Papers into Metaphors

Harish Kotra (he/him) — Mon, 13 Jul 2026 18:41:17 +0000

As developers, we are constantly bombarded with a massive stream of complex technical papers, 60-page business whitepapers, and long-winded documentation. We don't always have time to read through all the noise. What if we had a single tool that could parse any PDF or webpage and instantly translate it to our level of understanding—whether we want executive bullet points, logic-driven systems, or a simple analogy we could explain to a child?

In this post, we're going to dive into how I built ELI-X (Explain Like I'm 10)—a full-stack web application designed with React 19, Express, Tailwind CSS v4, and the brand-new @google/genai SDK to break down complex PDFs and articles into customized audience profiles across five complexity levels.

Creative Theme & Aesthetic Choice

Rather than building another generic software dashboard, I designed ELI-X using an Artistic Flair / Brutalist Neo-Pop theme. It uses high-contrast ink-like borders (#1A1A1A), thick drop shadows (shadow-[4px_4px_0px_#1A1A1A]), fluid offset interactive movements, and vivid saturated blocks of color.

By utilizing playful fonts and micro-animations, the app's aesthetic reinforces the underlying goal: making technical learning less dry and more approachable.

High-Level Architecture

ELI-X follows a simple, clean full-stack architectural pattern:

Client Interface (React 19): Captures user documents (via drag-and-drop file upload) or web URLs, configures audience personas, sets complexity intensity, and renders responses with elegant markdown.
Server Routing (Express + Multer): Handles API endpoints. For web articles, it fetches raw HTML. For files, it accepts multi-part form payloads and processes PDFs directly in memory.
AI Pipeline (Google Gemini API): Communicates with the official @google/genai SDK to perform multimodal reasoning directly on PDF file buffers and scrape contexts.

[ Client: React 19 ]
       |
       |  (Multipart Form: File Buffer / URL string, Persona, Complexity)
       v
[ Server: Express API ]  --- (Scrapes URL HTML or holds PDF buffer)
       |
       |  (@google/genai SDK)
       v
[ Gemini 3.5 Flash Model ] ---> Returns tailored Markdown explanation

Technical Breakdown: The API Routing Layer

To keep secrets like the GEMINI_API_KEY safe from the client-side browser bundle, all AI calls are proxied through a server-side endpoint.

We set up an Express endpoint /api/explain using multer to handle multipart uploads in memory. Let's look at how we parse the input and formulate our Gemini payload:

import express from 'express';
import multer from 'multer';
import { GoogleGenAI } from '@google/genai';

const app = express();
const upload = multer({ storage: multer.memoryStorage() });
const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });

app.post('/api/explain', upload.single('file'), async (req, res) => {
  try {
    const { persona, type, url, intensity = 3 } = req.body;
    const file = req.file;

    let contents: any[] = [];
    const prompt = `Explain the following content clearly and accurately, tailored exactly to this persona: ${persona}. 
    The desired intensity/complexity level within this persona is ${intensity} out of 5 (where 1 is the simplest, 3 is standard, and 5 is detailed). Adjust your depth and vocabulary accordingly.
    Keep the tone appropriate for the persona (e.g., simple for a 10-year-old, professional for a CEO, technical for a Software Engineer, warm for Grandma).
    Make it engaging, informative, and formatted with markdown. Do not include introductory fluff, just dive into the explanation.`;

    contents.push({ text: prompt });

    if (type === 'file') {
      if (!file) return res.status(400).json({ error: 'File is required' });

      // Convert raw buffer to Base64 to send to Gemini
      const base64Data = file.buffer.toString('base64');
      contents.push({
        inlineData: {
          mimeType: file.mimetype,
          data: base64Data
        }
      });
    } else if (type === 'url') {
      if (!url) return res.status(400).json({ error: 'URL is required' });

      // Fetch webpage content
      const response = await fetch(url);
      const html = await response.text();
      contents.push({ text: `Source URL: ${url}\n\nWebpage content:\n${html}` });
    }

    // Call Gemini 3.5 Flash - optimized for speed and large multimodal contexts
    const response = await ai.models.generateContent({
      model: 'gemini-3.5-flash',
      contents: { parts: contents },
    });

    res.json({ explanation: response.text });
  } catch (error) {
    res.status(500).json({ error: 'Internal Server Error' });
  }
});

Creative Styling with Tailwind CSS v4 and Motion

Tailwind CSS v4 introduces unified native compilation, allowing us to build custom themes extremely quickly.

For the persona buttons, we map metadata-driven layouts directly:

const PERSONAS = [
  { id: 'Age 10', label: '10-Year-Old', short: '10', color: 'bg-[#FFD700]', sub: 'Simple & Fun' },
  { id: 'College student', label: 'College Student', short: 'CL', color: 'bg-[#98FF98]', sub: 'Structured & Academic' },
  { id: 'CEO', label: 'CEO', short: 'CEO', color: 'bg-[#87CEEB]', sub: 'Bullet Points & ROI' },
  { id: 'Software engineer', label: 'Software Engineer', short: 'SE', color: 'bg-[#E6E6FA]', sub: 'Logic & Systems' },
  { id: 'Grandma', label: 'Grandma', short: 'GM', color: 'bg-[#FFB6C1]', sub: 'Warm & Conversational' },
];

By dynamic rendering, clicking any persona instantly modifies the state, rendering custom themes on the fly.

To make user interactions feel delightful and tactile, we use Motion (f.k.a. Framer Motion) to animate state transitions smoothly:

<AnimatePresence mode="wait">
  {inputType === 'pdf' ? (
    <motion.div 
      key="pdf"
      initial={{ opacity: 0, y: 5 }}
      animate={{ opacity: 1, y: 0 }}
      exit={{ opacity: 0, y: -5 }}
      transition={{ duration: 0.15 }}
    >
       {/* File upload drag/drop zone */}
    </motion.div>
  ) : (
    // URL input zone
  )}
</AnimatePresence>

Key Takeaways & Developer Benefits

Native PDF ingestion: Rather than compiling complex client-side PDF.js decoders, we let Gemini's native multimodal engine ingest the raw PDF stream. This dramatically reduces client-side bundle size and guarantees highly accurate contextual interpretations.
Micro-Copywriting: Fine-tuned prompt guidelines combined with direct user-controlled dials (Complexity sliders from 1 to 5) offer unmatched control over reading density.
Local Cache Tab: Simple Local Session array states keep recent answers alive across clicks, preventing unnecessary double calls to the server.

Try It Out!

Check out ELI-X now to simplify your readings, built with passion and precision: https://www.dailybuild.xyz/project/192-eli-x

Building Foundry: Autonomous Software Companies on Cardano

Harish Kotra (he/him) — Sun, 12 Jul 2026 13:46:34 +0000

Introduction

Most AI coding tools give you a chat window and a diff. Foundry takes a different approach: you describe a product idea, and it spins up a virtual software company — a CEO agent scopes the work, specialist agents execute in a dependency graph, and the whole run is wallet-funded on Cardano Preprod.

We built this for India Codex '26. The live app is at https://foundry-gamma-three.vercel.app. The codebase lives in foundry/ inside the IndiaCodex-2026 submission repo.

This post walks through the architecture, execution model, Cardano integration, and the engineering decisions that make it work.

The core idea

Foundry treats software delivery as company orchestration, not single-shot code generation.

Traditional AI assistant	Foundry
One model, one response	Nine specialist agents + CEO
No dependency awareness	Topological DAG with parallel waves
No payment model	CIP-30 wallet → treasury → agent fees
Generic output	Scoped roster per project brief
Static result	Live NDJSON stream + React Flow canvas

A typical run produces research docs, architecture, Aiken contracts, a frontend scaffold, security audit, QA plan, documentation, and a deployment checklist — each attributed to the agent that produced it.

System architecture

Layer breakdown

Frontend — Next.js 16 App Router, React 19, Tailwind CSS 4, React Flow for the live DAG, Zustand for persisted project/execution/agent state.

Backend — Two API routes. No separate server. Execution streams over HTTP using NDJSON.

Agents — Each role extends BaseAgent with its own system prompt, JSON output schema, Masumi metadata, and per-task fee.

Contracts — Separate Aiken project in contracts/ with four validators (main, lock, mint, vesting).

User journey

Scope analysis: picking the right team

Before execution, Foundry analyzes the project brief and decides which agents are needed. Research and Architecture always run. Specialists like Contract Engineer or Security Engineer are included only when the brief implies on-chain logic, UI, audits, etc.

The agent picker lets users override the AI selection with tooltips explaining each role — then reset to the AI pick if they change their mind.

The execution engine

The heart of Foundry is ExecutionController. It:

Registers all agents on Masumi (non-fatal if mock mode)
Runs the CEO to produce (or accept pre-analyzed) scope and a DAG
Executes specialists in parallel topological waves
Converts agent JSON outputs into downloadable ProjectOutput files

Parallel DAG execution

This is the key performance optimization. Instead of running agents sequentially, we find all nodes whose dependencies are satisfied and run them concurrently:

// src/services/execution-controller.ts
while (remaining.size > 0) {
  const ready = this.dag.filter(
    (node) =>
      remaining.has(node.id) &&
      node.dependencies.every((dep) => !remaining.has(dep)),
  );

  if (ready.length === 0) {
    this.emit({
      type: "execution:error",
      timestamp: Date.now(),
      data: { message: "Deadlock detected in execution DAG" },
    });
    break;
  }

  await Promise.all(
    ready.map((nodeDef) =>
      this.runSpecialistNode(nodeDef, agentMap, outputs, remaining),
    ),
  );
}

After Architecture completes, Contract Engineer and Frontend Engineer run in the same wave. Security and QA follow once their prerequisites finish.

Tailored DAG construction

buildExecutionDag() only includes agents the project actually needs:

// src/services/execution-plan.ts
export function buildExecutionDag(requiredAgents: AgentRole[]): ExecutionDagNode[] {
  const roles = new Set(
    requiredAgents.filter((r) => ALL_SPECIALIST_ROLES.includes(r)),
  );

  add("research", []);
  add("architecture", ["research"]);
  add("contract-engineer", ["architecture"]);
  add("frontend-engineer", ["architecture"]);
  // security, qa, docs, deployment wired based on what's in `roles`
}

If scope was already analyzed at project creation, the CEO takes a fast-path — it skips an extra LLM call and uses the pre-built DAG directly.

Streaming execution over HTTP

Execution doesn't poll. The API returns a live NDJSON stream — one JSON event per line:

// src/app/api/execution/route.ts
export async function POST(req: Request) {
  const controller = new ExecutionController(body.walletAddress);
  const encoder = new TextEncoder();
  const stream = new TransformStream();
  const writer = stream.writable.getWriter();

  const unsubscribe = controller.on((event) => {
    void writer.write(encoder.encode(`${JSON.stringify(event)}\n`));
  });

  controller.execute(body.projectContext).finally(async () => {
    unsubscribe();
    await writer.close();
  });

  return new Response(stream.readable, {
    headers: {
      "Content-Type": "application/x-ndjson; charset=utf-8",
      "Cache-Control": "no-cache, no-transform",
    },
  });
}

Event types the client handles

Event	Purpose
`dag:generated`	CEO produced the task graph
`agent:status`	waiting → working → completed
`agent:log`	Live log line
`agent:reasoning`	Chain-of-thought snippet
`agent:output`	Structured JSON result
`agent:confidence`	0–1 quality score
`agent:cost` / `agent:duration`	Per-agent metrics
`outputs:generated`	Downloadable file bundle
`execution:complete`	Company finished

The client (useExecutionStream) fans these events into three stores: agentStore (sidebar detail), executionStore (React Flow nodes), and projectStore (persisted outputs).

Live UI: React Flow + agent nodes

The execution page renders the DAG with React Flow. Each node is a custom AgentNode showing:

Status icon (waiting, working, completed, failed)
Confidence bar (synced to executionStore, not just the sidebar)
Clickable output chips per agent (files appear as each agent completes)

Outputs are derived live from agent results before the final outputs:generated batch lands in the project store:

const allOutputs = useMemo(() => {
  if (projectOutputs.length > 0) return projectOutputs;
  return agents.flatMap((agent) =>
    agent.output
      ? deriveOutputsForAgent(projectId, name, agent.config.role, agent.output)
      : [],
  );
}, [projectOutputs, agents, projectId, project?.name]);

Cardano integration

Foundry is Cardano-native, not Cardano-bolted-on.

flowchart LR
  User[User Wallet] -->|CIP-30 sign| Mesh[Mesh SDK]
  Mesh -->|lovelace tx| Treasury[Treasury Address]
  Treasury -->|85%| Agents[Agent Fee Pool]
  Treasury -->|15%| Protocol[Protocol Fee]
  Agents --> Execution[Agent Run Unlocked]
  Contracts[Aiken Validators] --> Preprod[Cardano Preprod]

Wallet — Mesh SDK, CIP-30, Preprod only. MetaMask and non-Cardano wallets filtered out.
Funding — User must fund the treasury before execution. Mock mode skips on-chain tx when treasury isn't configured.
Fees — Budget = sum of active agent fees + CEO fee + 15% treasury cut.
Deploy — Six-step UI: compile → keys → faucet → build → submit → verify on Preprod explorer.

Smart contracts (Aiken)

Contracts live in a separate contracts/ project — not embedded in the Next.js app.

Validator	Purpose
`main.ak`	Owner-signed spending validator
`lock.ak`	Timelock — lock ADA until deadline
`mint.ak`	Owner-signed mint, open burn
`vesting.ak`	Linear vesting with cliff

Example — the lock validator signature:

// contracts/validators/lock.ak
validator {
  owner: VerificationKeyHash,
  deadline: Int,
  beneficiaries: List<VerificationKeyHash>,
}

fn owner_signed(tx: Transaction) -> Bool {
  tx.extra_signatories
    |> list.member(owner)
}

The Contract Engineer agent generates project-specific Aiken from the architecture blueprint. Reference validators in contracts/ serve as the canonical on-chain codebase for the submission.

Masumi agent economy

Each agent carries Masumi marketplace metadata — capability name, pricing in lovelace, tags, request limits. At execution start, ExecutionController registers agents on the Masumi registry. The /marketplace page surfaces them for discovery.

MASUMI_MOCK=true lets you demo the full flow locally without Masumi infrastructure.

Agent roster

Agent	Role	Always runs?	Key outputs
CEO	Orchestration	Yes (pre-DAG)	Project summary, dynamic DAG
Researcher	Research	Yes (core)	Requirements, risks, tech stack
Architect	Architecture	Yes (core)	Components, data flow, folder structure
Contract Engineer	Contracts	Scope-dependent	`.ak` files, validation rules
Frontend Engineer	Frontend	Scope-dependent	React/Next.js scaffold
Security Engineer	Security	When contracts exist	Audit report, vulnerability score
QA Engineer	Testing	Scope-dependent	Test plan, coverage targets
Documentation Engineer	Docs	Scope-dependent	README, API docs, Catalyst proposal
Deployment Engineer	Deploy	Scope-dependent	Checklist, shell commands

Each agent has a dedicated system prompt in src/prompts/, a Zod-validated JSON output schema, and structured streaming via the OpenAI SDK (OpenRouter-compatible).

Frontend engineering note: surviving Tailwind v4

One painful lesson: Tailwind v4 doesn't reliably emit utilities from cva() strings in dev, and Mesh SDK preflight resets button { background: transparent }. Buttons and landing typography looked broken — classes in the DOM, no CSS behind them.

Fix: standalone CSS files imported directly in layout.tsx (buttons.css, landing.css), bypassing Tailwind's purge pipeline. The Button component maps to explicit .btn--primary classes instead of bg-primary utilities.

Running it locally

cd foundry
pnpm install
cp .env.example .env.local
pnpm dev

Open http://localhost:3000. Mock mode works without API keys — agents return realistic structured placeholders. For real LLM calls, set OPENAI_API_KEY and optionally OPENAI_BASE_URL=https://openrouter.ai/api/v1.

For contracts:

cd contracts
aiken check && aiken build

What we'd build next

Persistent execution history across sessions (agent store currently resets on refresh)
Real Masumi payment settlement per agent task
Mainnet deployment path with audited contract templates
Agent memory sharing across projects via a vector store
Public marketplace where third-party agents can register and bid on tasks

On-Device Celebrity Vegetables: Building a Playful LiteRT.js Demo

Harish Kotra (he/him) — Fri, 10 Jul 2026 16:38:54 +0000

A technical walkthrough of “Which Celebrity Vegetable Are You?” — private WebAI inference with Google’s LiteRT.js, multi-crop classification, a 387-item world produce catalog, and fingerprint-stable matching that still feels dynamic at party scale.

TL;DR

We built a browser-only app that:

Loads Google’s LiteRT.js Wasm runtime
Compiles real .tflite models (MobileNet ImageNet + optional food classifier)
Runs multi-crop inference on WebGPU / Wasm / WebNN
Ranks a 387-entry global produce catalog (not 24 fixed jokes)
Picks a winner with a photo fingerprint–weighted top pool so many users diverge
Builds unique card copy from templates + seed
Exports a share card with compile + inference latency (+ crop count)

No photo upload server. No face ID. Real classification on your pixels.

Live stack: Vite · TypeScript · @litertjs/core · optional @litertjs/tfjs-interop

Why LiteRT.js (and why produce)?

LiteRT.js is Google’s production-minded WebAI runtime: Wasm/XNNPack, WebGPU, WebNN, .tflite interchange, and TF.js interop.

A dry MobileNet page doesn’t travel. A privacy-first produce oracle does — especially when hundreds of outcomes and photo-stable variety make a group demo feel alive.

Architecture

┌─────────────────────────── Browser ───────────────────────────┐
│  UI (main.ts)                                                 │
│       │                                                       │
│       ▼                                                       │
│  LiteRT engine                                                │
│    loadLiteRt → loadAndCompile(.tflite)                       │
│    5 crops → model.run × N → average softmax → top-25         │
│       │                                                       │
│       ▼                                                       │
│  Produce oracle                                               │
│    score 387 catalog entries (labels + color + fingerprint)   │
│    weighted pick among top ~18 → template persona card        │
│       │                                                       │
│       ▼                                                       │
│  Result UI + share PNG (latency · crops · catalog size)       │
└───────────────────────────────────────────────────────────────┘

Module	Role
`litert/engine.ts`	LiteRT load/compile/run, multi-crop, optional TF.js interop
`litert/preprocess.ts`	Crops, NCHW/NHWC, ImageNet norm, top-K / averaged top-K
`personas/produce-catalog.ts`	Compact world produce list (keywords, region, color)
`personas/roster.ts`	Deterministic moniker/tagline/trait templates
`personas/score.ts`	Ranking + fingerprint-weighted selection
`share/card.ts`	Magazine-style PNG

Inference path (still 100% LiteRT for the model)

await loadLiteRt('/wasm/');
const model = await loadAndCompile('/models/mobilenet_v2.tflite', {
  accelerator: 'webgpu', // or wasm / webnn
});

// multi-crop → Tensor → model.run (repeated) → average probs → top-25
const run = await runModel(bundle, imageSource, 'webgpu', false, true);
// run.preds, run.timings.crops === 5

Default path uses LiteRT Tensor + model.run. Optional UI toggle uses runWithTfjsTensors for the same compiled LiteRT model with TF.js boundary tensors.

From logits to a vegetable (not random)

Features from the photo — multi-crop classification + canvas color stats + byte fingerprint.
Score every catalog entry — keyword overlap on a wide top-K, name-token boost, color/brightness soft match.
Take top ~18, then weighted sample using the fingerprint (higher scores more likely; same photo ⇒ same pick).
Build persona — templates seeded by fingerprint ⊕ produce id so monikers/taglines differ per person/photo.
Show alts — second/third aura vegetables for a richer card.

Same photo + WebGPU vs Wasm ⇒ same produce (trust). Different photos ⇒ different ranks and seeds (diversity).

Why 387 entries beat 24 personas

With two dozen outcomes, parties collapse into “everyone is kale.” A global produce catalog (chayote, ube, fiddlehead, shishito, samphire, …) plus a soft top-pool pick spreads results without abandoning the image.

Card text is procedural, so even two “tomato” wins can read differently.

Privacy

Models and Wasm download as static assets. Pixels are not uploaded for inference. Disclaimer: parody, not biometrics.

Setup

npm install   # postinstall: Wasm + .tflite
npm run dev

What’s next

Drop-in custom .tflite + labels
Produce-specialized model for sharper plant/food classes
Optional aggregate “popular vegetables this week” (counts only, no images)

References

Code & more: https://www.dailybuild.xyz/project/189-veggie-oracle

Three AI Agents Walk Into a Debate Stage: Building Verifiable Agent Workflows with Agno + Shepherd

Harish Kotra (he/him) — Wed, 08 Jul 2026 16:48:44 +0000

How to combine Agno's multi-agent orchestration with Shepherd's reversible execution traces to build agent systems you can actually trust.

The Problem

When an AI agent works on a non-trivial task, it builds up state — files edited, tools called, model responses — and that state is invisible after the process exits. If the agent makes a mistake at step 10, you can't roll back to step 5 without restarting from scratch, re-paying for every model call, and hoping the non-deterministic output reproduces the same early steps.

This is the problem Shepherd (Stanford, 2026) tackles: it records agent executions as durable, Git-like traces. Every run produces a retained output — a proposal held beside your files that you inspect and settle before it's applied.

And this is where Agno comes in: it makes building multi-agent systems productive. 30+ model providers behind one API, Teams with explicit orchestration modes, memory, knowledge, 100+ tools.

Together, they give you Agno's flexibility with Shepherd's safety net.

What We Built

A 205-line Python script where three Agno agents debate a proposition:

Pro argues FOR — writes pro_argument.txt
Con argues AGAINST — writes con_argument.txt
Judge reads both — writes verdict.txt with a winner

Shepherd wraps the whole thing so every run leaves a trace you can inspect via CLI:

shepherd run show run-2a4c8ca6355f
shepherd run trace run-2a4c8ca6355f --events
shepherd run select run-2a4c8ca6355f     # accept
shepherd run discard run-2a4c8ca6355f    # reject

A Sample Run

$ python debate_demo.py --topic "Remote work is better than office work"
[Pro] wrote 1,894 chars
[Con] wrote 1,849 chars
[Judge] wrote 3,843 chars → Pro wins

The Pro argued flexibility and work-life balance. The Con countered with collaboration and spontaneous interaction. The Judge analyzed both, found Pro's case more comprehensive, and wrote a 3,843-character verdict with specific reasoning.

Run it again and the verdict might flip — each run is independent, non-deterministic, and fully recorded.

Architecture

┌──────────────────────────────────────────────────┐
│                   Shepherd Workspace             │
│  ┌─────────────────────────────────────────────┐ │
│  │         Shepherd Task Subprocess            │ │
│  │                                             │ │
│  │  Agent(Pro, gpt-4o-mini)                    │ │
│  │    → pro.run("Argue FOR: {topic}")          │ │
│  │    → writes pro_argument.txt                │ │
│  │                                             │ │
│  │  Agent(Con, gpt-4o-mini)                    │ │
│  │    → con.run("Argue AGAINST: {topic}")      │ │
│  │    → writes con_argument.txt                │ │
│  │                                             │ │
│  │  Agent(Judge, gpt-4o-mini)                  │ │
│  │    → judge.run(pro_text + con_text)         │ │
│  │    → writes verdict.txt                     │ │
│  └─────────────────────────────────────────────┘ │
│                                                  │
│  Run record → .vcscore/ (durable trace)          │
│  Settlement → select | discard | release         │
└──────────────────────────────────────────────────┘

Key Design Decisions

1. The `provider:model_id` Pattern

Instead of hardcoding model choices, every agent is configured via a string like "openai:gpt-4o-mini":

def make_agent(spec: str, role: str, instructions: str) -> Agent:
    provider, model_id = spec.split(':', 1)
    if provider == 'openai':
        from agno.models.openai import OpenAIChat
        model = OpenAIChat(id=model_id)
    elif provider == 'ollama':
        from agno.models.ollama import Ollama
        model = Ollama(id=model_id)
    elif provider == 'lmstudio':
        from agno.models.lmstudio import LMStudio
        model = LMStudio(id=model_id)
    return Agent(model=model, instructions=instructions)

This makes it trivial to swap models per agent without changing a line of agent logic:

python debate_demo.py \
  --pro-model "openai:gpt-4o" \
  --con-model "ollama:llama3.2" \
  --judge-model "openai:gpt-4o-mini"

2. File-Based Context Passing

The Judge receives the full text of both arguments in its prompt, not file paths. This avoids the "I can't read files" problem common with agents that try to use file-reading tools:

judge_prompt = (
    f'You are judging a debate on: "{topic}".\n\n'
    f'PRO argument:\n{"="*40}\n{pro_text}\n{"="*40}\n\n'
    f'CON argument:\n{"="*40}\n{con_text}\n{"="*40}\n\n'
    f'Who wins? Write a detailed verdict.'
)
judge_resp = judge.run(judge_prompt)

3. Idempotent Task Registration

Shepherd v0.2.1 has a read-after-write lock — you can't register a task while a previous run's world is still active. The fix is simple: try registration, and if it fails, the task already exists:

try:
    workspace.tasks.register_source(...)
except Exception:
    pass  # already registered

4. Shepherd's Settlement Workflow

This is the key differentiator from a plain Python script. After the debate runs, the output is in a retained state — it exists but isn't applied:

shepherd run select <ref> — marks it accepted (immutable record)
shepherd run discard <ref> — marks it rejected
Consume-once semantics prevent double-applies

What Makes This Hard (and What We Learned)

Shepherd is early. v0.2.1 has real rough edges:

Workspace locks. Stale runs block new operations. The try/except on registration works around it but isn't elegant.
Subprocess isolation. The task body runs in a temp file subprocess. Environment variables (API keys) don't propagate — they must be passed as function arguments and set via os.environ inside the body.
Advisory placement. File writes go to disk directly; Shepherd doesn't intercept them as a changeset. The changeset shows empty paths. True interception requires placement='jail' (macOS Seatbelt), which we didn't exercise.
Trace granularity. The run trace shows lifecycle events but not individual model calls. Deeper instrumentation is on Shepherd's roadmap.

Agno is polished. The agent abstraction, model routing, and Agent.run() API are clean and well-documented. The from agno.models.openai import OpenAIChat pattern works exactly as expected.

How to Fork and Extend

The full source is at courtroom.agi/debate_demo.py. Here are the best first extensions:

Easy

[ ] Structured verdict — Use Agno's output_model with a Pydantic schema for scores per criterion
[ ] FileTools — Replace open() with Agno's FileTools for agent-managed file I/O
[ ] Git diffs — Commit verdicts to git after each run for history

Medium

[ ] Multi-round debate — Pro rebuts Con, Con rebuts back, then Judge decides
[ ] Audience agent — A 4th agent simulates audience reaction
[ ] Web UI — Wrap in Streamlit or FastAPI
[ ] MCP tools — Give agents web search or data lookup during debate prep

Advanced

[ ] Jail enforcement — Run with placement='jail' for OS-level write interception
[ ] Supervisor meta-agent — An Agno agent watches the Shepherd trace and reverts bad steps via shepherd run discard
[ ] Model A/B test — Fork the same prompt prefix across different model combos, compare outcomes

Why This Matters

Most agent demos show a single agent printing text. Production agent systems need:

Observability — what did the agent actually do?
Reversibility — how do I undo a bad step?
Settlement — how do I decouple "produced" from "applied"?

Agno handles the orchestration. Shepherd handles the record. Together they represent a pattern that will become standard as agent systems move from prototypes to production.

Code & more: https://www.dailybuild.xyz/project/187-courtroomagi