DEV Community: Zimtzimt

Here’s How I Built a Global 'Sync' for My Team’s AI Agents

Zimtzimt — Thu, 16 Apr 2026 07:44:13 +0000

The AI Ecosystem is Moving Too Fast for Manual Config.

We are currently living through a "Cambrian Explosion" of AI tools. Every single day, a new Model Context Protocol (MCP) server is released, a new specialized "skill" is shared, or a better way to structure .claude.md files is discovered.

If you’re working solo, you can (barely) keep up. But the moment you bring a team into the mix? Everything breaks.

I watched my team waste hours every week manually configuring their ~/.claude/ files, hunt down the latest GitHub MCP server URLs, and ask each other "Wait, where is the most up-to-date version of our coding standards?"

I realized that 'Time-to-Agent' is the new 'Time-to-Hello-World'.

If it takes an engineer an hour to set up their local agent environment to match the team’s standards, we’ve already lost. Out of that frustration, I built Myosotis—a team-wide "Forget-Me-Not" for AI configuration. It turns AI agent setups from manual chores into global, shared infrastructure.

🚀 The Core Problem: The Configuration Gap

The problem isn't the AI; it's the glue.

Onboarding Friction: New hires spend half their first day just getting Claude or Codex to understand the project’s specific constraints.
Skill Fragmentation: One dev writes a brilliant automation script for the database; the other four devs don't even know it exists.
The "Plugin Chasing" Loop: "Did you install the new Postgres MCP?" "No, which one are we using?"

I wanted a way to push a button and have the entire team's agents instantly gain a new superpower.

🛠️ How I Built the "Team Brain" (The Myosotis Setup)

I built a framework that brings the "Source of Truth" back to the center while still respecting the local nature of the developer's machine.

1. Global Sync, Local Freedom (The Bootstrap)

Myosotis uses a platform-agnostic bootstrap setup. When an engineer joins (or a new MCP is released), they run one command. It synchronizes our Canonical MCP Profiles and Shared Skills directly into their ~/.claude/ or ~/.codex/ directories.

The beauty? It's additive. The script sets the "Team Baseline" (like our read-only DB tools and standard GitHub skills), but the developer can still add their own experimental MCPs on top without breaking the sync.

2. Managed Anchors (The Agent's Instruction Manual)

I moved the team's knowledge into a set of project templates. Every repository now has managed "anchors" like AGENTS.md and CLAUDE.md.

These aren't just empty docs; they are the protocol. They tell any agent that drops into the repo: "Here are the team skills you have access to, here are the MCP servers you should use, and here is how we write code here."

3. The Myosotis Control Surface

To make managing this even easier, the repo includes a Next.js application that serves as a control surface. Instead of editing raw JSON files, you can manage your MCP profiles, skill libraries, and instruction layers in one place and sync them back to your source of truth.

📉 The Result: Zero-Friction AI Onboarding

The impact was immediate.

Onboarding an agent to a new repo now takes seconds, not hours.
Pushing a new team capability (like a new specialized frontend refactoring skill) is now a simple git pull away for the whole team.
Consistency is guaranteed. If we decide as a team to use a specific MCP for documentation, it's deployed to everyone simultaneously.

💡 Stop Managing Agents, Start Orchestrating Them

If your team is serious about using AI, you have to stop treating your agent's config like a personal .bashrc file. In an era where plugins and skills release "minutely," you need a distribution system, not a manual setup guide.

Treat your agents like members of the team. Give them a shared syllabus, a shared utility belt, and a shared headquarters.

I've open-sourced Myosotis so you can stop the config madness and start scaling your team's AI intelligence. Check out the link below and let's build the future of AI-native engineering together.

shiftbloom-studio / myosotis

Team-shared Agent Harness Builder to configure MCP Servers, Skills and AGENTS.md / CLAUDE.md for your team with cross-agent setups.

Myosotis

Myosotis is an open-source control surface for AI-native workspace setup.

This is not another agent harness.

Its purpose is to solve Configuration Fragmentation and Team-Wide Onboarding in an era where AI skills, MCP servers, and best practices are releasing minutely. It provides a unified, syncable baseline for every developer on a team—ensuring every agent has the same tools and domain context while preserving local autonomy.

Why Myosotis?

Instead of hiding your agent setups behind a database or a proprietary internal tool, Myosotis keeps the source of truth in plain files you can review, diff, fork, and ship.

Instant Team Onboarding: Turn hours of manual agent configuration into a 60-second bootstrap.
Collective Intelligence: Shared domain skills (backend, frontend, devops, pr-review) that the whole team uses and improves.
File-Native: MCP configs, skills, and instructions remain regular repository assets.
Hybrid Execution: A shared stack on AWS for long-running…

View on GitHub

Open Hallucination Index (OHI): turning “Plausible AI” into “Verifiable AI” (LLMs as Gardeners of the Graph) 🌱🧠

Zimtzimt — Wed, 07 Jan 2026 10:52:16 +0000

I’m genuinely obsessed with this phase of life where you can learn so much so fast — and suddenly you notice: oh wow, there’s real potential here. ✨

And yes, AI is controversial. A lot of critique is valid and not “debatable away”.
But if you zoom in on the technical side — the architecture, the retrieval mechanics, the verification problem — it’s an insanely interesting space.

So… last night I went full hyperfocus and wrote a research paper + reference implementation for something I call:

Open Hallucination Index (OHI)

OHI is a sovereign architectural framework that tries to move us from “Generative AI” to “Verifiable AI” by adding a deterministic Trust Layer after generation.

Motto: “LLMs Hallucinate – We Verify.”

The core problem: the epistemic deficit

LLMs are optimized for plausibility, not veracity.

They can sound true while being completely ungrounded — what my paper frames as stochastic fabulation.

On the human side, there’s also a psychological trap: people tend to grant fluent systems a kind of epistemic authority, which fuels automation bias (trusting the output even when it clashes with evidence).

So the goal here is not “make models perfect” — it’s:

make truth-checking systematic, auditable, and configurable.

Why “naive RAG” doesn’t solve it

Retrieval-Augmented Generation is a good direction, but the naive version still fails:

vector similarity can fetch irrelevant chunks
the generator can still override retrieved context with parametric memory
“semantic proximity” is not “logical truth”

In the paper, I argue verification must be extrinsic and deterministic — not another stochastic step inside the generation loop.

OHI in one breath: a post-generation Trust Layer

Instead of trusting an answer as a blob of text, OHI verifies it at claim-level granularity.

1) Atomic Claim Decomposition (granularity is everything)

A paragraph can contain 9 correct facts and 1 subtle fabrication — binary “true/false” labels won’t cut it.

OHI decomposes a response into atomic claims, represented like a tuple:

(S, P, O) → subject / predicate / object

This is aligned with ideas used in fine-grained factuality metrics like FActScore:

T (text)  →  A = {c1, c2, ... cn} (atomic claims)

FActScore = (1 / |A|) * Σ 𝟙(claim is supported)

2) Hybrid evidence retrieval (Graph + Vector + MCP)

For each atomic claim, OHI uses multiple verification oracles:

Neo4j graph matching (deterministic structure: “does this relation/path exist?”)
Qdrant vector retrieval (semantic candidates, “fuzzy” evidence)
MCP evidence (live, standardized tool access — e.g., Wikipedia / Context7 docs)

3) Classify each claim + compute a Trust Score

Each claim becomes one of:

Supported
Contradicted
Unverifiable (no decisive evidence)

Then the system aggregates per-claim signals into a final OHI Trust Score (0.0–1.0) and returns a visual overlay (green/red/gray) per sentence/claim.

A mental model I like from the paper:

like nutritional labels for epistemic quality — not vibes, but a visible score.

The system architecture (sovereign by design)

OHI is designed for local sovereignty:

no external OpenAI/Anthropic calls needed for verification
local control over Ground Truth
avoids the “fox guarding the henhouse” scenario

High-level components:

vLLM hosting Qwen2.5 (paper discusses 7B + 32B variants; reference setup uses a quantized 7B AWQ)
Neo4j as ontology store (index-free adjacency for multi-hop traversal)
Qdrant as semantic store (embeddings for initial retrieval)
Redis as cache (reduce repeated lookup cost)
MCP servers as standardized “truth adapters” (Wikipedia, Context7)

In the paper I also highlight vLLM’s PagedAttention as a throughput enabler for parallel verification workloads.

The algorithmic heart: Hybrid Verification Oracle

The paper formalizes the scoring logic as a hybrid oracle + weighted scorer.

Simplified version:

For each claim c:
  S_graph = 1.0 if exact graph match else 0.0
  S_vec   = semantic similarity from vector retrieval
  S_mcp   = evidence signal from MCP tools

Trust(c) = α*S_graph + β*S_vec + γ*S_mcp
OHI Score = average Trust(c) across all claims

Default weights in the paper:

α = 0.6 graph exact match (deterministic truth)
β = 0.3 vector semantic match (plausibility)
γ = 0.1 MCP evidence (contextual grounding)

Graph can effectively act as a “veto” against misleading semantic matches.

Two tiny code peeks (from the reference implementation)

1) MCP over SSE: a clean “truth sidecar” session

OHI uses MCP to standardize tool access via JSON-RPC 2.0, and the Wikipedia adapter keeps it lightweight with SSE transport.

Here’s the fallback session context manager:

from contextlib import asynccontextmanager
from mcp import ClientSession
from mcp.client.sse import sse_client

@asynccontextmanager
async def _session_fallback(self):
    """Create a new MCP session (non-pooled, for fallback)."""
    async with sse_client(self._mcp_url) as (read, write):
        async with ClientSession(read, write) as session:
            await session.initialize()
            yield session

In the paper, I also discuss session pooling to reduce repeated SSE handshake overhead.

2) Streaming Wikipedia dump ingestion (memory-efficient)

Your “Ground Truth” is only as good as your ingestion pipeline.

To build the Neo4j graph from a massive Wikipedia XML dump, the importer uses streaming iterparse + aggressive element clearing:

from xml.etree.ElementTree import iterparse

context = iterparse(file_handle, events=("start", "end"))

for event, elem in context:
    tag = strip_namespace(elem.tag)

    if event == "start" and tag == "page":
        in_page = True
        current_page = {}

    elif event == "end":
        if not in_page:
            elem.clear()
            continue

        # ... collect title, ids, text, etc. ...

        if tag == "page":
            in_page = False

            # resume support: skip until checkpoint
            page_id = current_page.get("page_id", 0)
            if page_id <= start_after_page_id:
                current_page = {}
                elem.clear()
                continue

            if current_page.get("text"):
                yield (
                    current_page.get("title", ""),
                    current_page.get("page_id", 0),
                    current_page.get("revision_id", 0),
                    current_page.get("text", ""),
                )

            current_page = {}

        # Clear element to free memory
        elem.clear()

That’s how you survive multi-GB XML without melting RAM.

Performance reality check (what the paper reports)

The system is fast on DB queries, but the bottlenecks are:

claim decomposition (LLM inference): ~200–500ms per text segment
orchestration overhead in Python (GIL + I/O overhead accumulates under concurrency)

The paper frames a clear direction: porting core orchestration to Rust for near-real-time constraints.

Minimum “sovereign mode” hardware (paper summary)

~16GB RAM + NVIDIA GPU
~8GB VRAM for Qwen2.5-7B-AWQ
Neo4j: 4–16GB RAM
Qdrant: ~4GB RAM per 1M vectors (depends on setup)

“LLMs as Gardeners of the Graph” 🌿

This analogy is my favorite part of the future-facing discussion.

Imagine the “Graph” as a floating monolith of structured knowledge:
nodes = entities/facts, edges = relations.

LLMs aren’t “truth” — they’re gardeners:

they shape, prune, and recombine knowledge into fluent language
but they can also cross-breed the wrong things and produce believable nonsense

The future vision in the paper is recursive:

LLMs help grow the graph (extract triples from new text into Neo4j)
OHI then audits the same models against the structure they helped build

A self-correcting loop… with one big philosophical question:
who owns the graph? 👀

Try it / read it / fork it

Research Paper (PDF)
Demo
Open Source Docker Image + API
Open Source Demo Website

Research Paper:
https://publuu.com/flip-book/1040591/2304964

Demo:
https://openhallucination.xyz

Open Source Docker-Image + API:
https://github.com/shiftbloom-studio/open-hallucination-index-api

Open Source Demo Website:
https://github.com/shiftbloom-studio/open-hallucination-index

If you’re into epistemology, verification, GraphRAG, or just building systems that refuse to hand-wave truth…

I’d love feedback, critiques, and “this will break when…” comments. That’s the good stuff. 😄🧠

Building Circadian UI: time-aware theming for React + Next.js (Open Source)

Zimtzimt — Sun, 04 Jan 2026 14:50:38 +0000

I’m starting a new open-source NPM package called Circadian UI 🌗

The idea is pretty simple — but I kept thinking:
why does this not exist as a clean, reusable default yet?
Most apps either ship a static theme or a manual Dark Mode toggle. But real usage isn’t static: morning vs late-night usage feels totally different, and so do our eyes, attention, and tolerance for contrast.

Circadian UI aims to be a small “default upgrade” for most React/Next.js projects:

Time-aware theming (Dawn / Day / Dusk / Night)
Tailwind-friendly tokens (CSS variables, HSL-based)
WCAG contrast-aware by design (not a late patch)
Next.js-ready + SSR-safe (no theme flash, clean hydration story)
User control matters: opt-in, overrides, persistence, prefers-contrast / prefers-color-scheme support

The goal isn’t “another theme library”.
It’s more like: make the UI feel calm and right at any time of day — automatically — without being creepy or complex.

Where I want to take this

I’m building this in public and I’d love to turn it into a genuinely solid open-source package: clean API, great docs, good tests, and real-world ergonomics.

If you’re into React/Next.js DX, design tokens, accessibility, or just building polished tooling:
I’m very open to collaborating 🤝

Stuff I’d love help or feedback on:

edge cases for phase scheduling and overrides
a clean SSR + hydration strategy for Next.js App Router
Tailwind integration patterns that feel “drop-in”
contrast enforcement heuristics that stay visually consistent
demo app ideas that prove the value fast

I’ll post the repo + first preview/demos soon — and if you want to co-build, feel free to reach out or drop a comment.

Let’s build something that makes people go: “wait… how was this not a standard already?” ✨

Serve the Cake First, Add the Icing Only When Safe

Zimtzimt — Sat, 03 Jan 2026 23:08:09 +0000

Building Rich Experiences That Don’t Punish Real Users: Introducing Birthday-Cake Loading

I’ve been working on a promotional site for a fantasy game project I’m developing. The hero section was meant to feel magical: floating particle embers, subtle ambient voice narration, bell-like hover sounds, and smooth animated transitions between sections. On my desktop with a fast connection, it was exactly what I wanted—immersive and atmospheric.

Then I opened it on my phone over a mediocre 3G signal.

The experience fell apart. Long blank screen, audio starting late and stuttering, particles causing visible jank, battery drain, and the whole page feeling sluggish. Even after applying the usual optimizations—lazy-loading components, reducing particle count, compressing assets—the core problem remained: the rich version was simply too heavy for many real-world conditions.

Removing the effects entirely wasn’t an option; they were central to the feel I was going for. Media queries to hide them on mobile felt like a blunt instrument. What I really needed was a way to serve a lean, instantly usable baseline to everyone, then progressively add the richer layers only when the device and network could genuinely support them—without me having to write custom detection logic for every feature.

That’s when the “birthday cake” metaphor clicked: deliver the solid, edible cake first (the baseline experience that works everywhere), and add the fancy icing, sprinkles, and decorations only when there’s budget for it.

The Core Idea: Capability-Based Tiering

Birthday-Cake Loading (BCL) is a small runtime that:

Collects best-effort signals (device memory, CPU cores, network type/speed, Save-Data header, prefers-reduced-motion, etc.).
Derives a conservative tier: base → lite → rich → ultra.
Exposes feature flags (motion, audio, rich images, smooth scrolling, etc.).
Provides declarative components to gate content based on those flags or tiers.

The tiering is intentionally defensive: if there’s any doubt, it stays in a lower tier. This avoids the common pitfall of optimistic enhancements that end up hurting users on constrained devices.

How It Works in Practice

Here’s a simplified example from my game site:

import {
  CakeProvider,
  CakeLayer,
  CakeUpgrade,
  CakeWatch, // optional jank guard
} from "@shiftbloom-studio/birthday-cake-loading";

function HeroSection() {
  return (
    <CakeLayer feature="motion" fallback={<StaticHero />}>
      <ParticleEmberHero /> {/* Only mounts if motion is allowed */}
    </CakeLayer>
  );
}

function AmbientAudio() {
  return (
    <CakeUpgrade
      strategy="idle" // wait for idle time
      loader={() => import("./AmbientNarration")}
      fallback={<SilentVersion />}
    >
      <FullAudioExperience />
    </CakeUpgrade>
  );
}

export default function Page() {
  return (
    <CakeProvider>
      <CakeWatch /> {/* Opt-in runtime jank detection */}
      <HeroSection />
      <AmbientAudio />
      {/* rest of the page */}
    </CakeProvider>
  );
}

With this setup:

On a low-end phone with Save-Data enabled → static hero, no audio, instant paint.
On a high-end desktop → particles, narration, smooth upgrades after idle.

Core Web Vitals improved noticeably, and the site finally felt fast across the board.

Next.js Integration

Since the game site uses Next.js App Router, I added server helpers to read Client Hints and bootstrap the tier on the server:

// app/layout.tsx
import { headers } from "next/headers";
import { getServerCakeBootstrapFromHeaders } from "@shiftbloom-studio/birthday-cake-loading/server";

export default function RootLayout({ children }) {
  const bootstrap = getServerCakeBootstrapFromHeaders(headers());

  return (
    <html lang="en">
      <body>
        <CakeProvider bootstrap={bootstrap}>
          {children}
        </CakeProvider>
      </body>
    </html>
  );
}

This ensures the initial HTML already reflects the expected tier, avoiding flash of incorrect content.

A Note on the Development Process

I used several AI assistants (GPT, Grok, Gemini) extensively during research and early prototyping. They were invaluable for quickly surveying browser APIs for device signals, comparing tiering strategies, and stress-testing edge cases. The speed of iteration was genuinely higher than working entirely solo. That said, every architectural decision, API shape, and line of production code was mine—I treated the AIs as knowledgeable pair programmers rather than code generators. The result feels like a very human library because it is.

Why Not Just Use Existing Solutions?

I looked at libraries for feature detection, reduced-motion hooks, and lazy loading. None quite offered the full progressive-enhancement loop I needed:

Declarative gating tied to a unified tier.
Conservative defaults.
Server-side bootstrap for Next.js.
Opt-in runtime jank guard (CakeWatchtower).

BCL fills that gap without pulling in heavy dependencies.

Current State & What’s Next

The library is still young (v0.2.x as of this writing), but the core is stable and already powering my game site. It’s Apache-2.0 licensed, fully typed, and tree-shakeable.

If you’re building anything with rich media—games, portfolios, marketing sites, dashboards with heavy animations—I’d love to hear whether this approach resonates. Issues, PRs, and war stories are all welcome.

GitHub: https://github.com/shiftbloom-studio/birthday-cake-loading
npm: https://www.npmjs.com/package/@shiftbloom-studio/birthday-cake-loading
Live demo in the repo (examples/next-demo)

Thanks for reading. 🎂

react #nextjs #performance #accessibility #webdev #javascript #opensource #progressiveenhancement