DEV Community: connor gallic

Your AI Isn't Personal. Mine Has 156,926 Memories of Me.

connor gallic — Wed, 15 Apr 2026 17:26:00 +0000

"Personal AI" is a marketing term. The AI you talk to every day isn't personal. It's a generic foundation model with a 200-token memory feature bolted onto the side and your first name tacked into the system prompt.

Claude forgets everything I told it last session. ChatGPT remembers what brand of coffee I drink and three other things I let it save. Gemini has no idea I exist between threads. None of them know what I shipped last week, what I tried that failed, who my clients are, or what I was researching on Tuesday.

That's not personal. That's cosplay.

I built what I think personal AI actually requires. Not a product. An architecture. A sovereign memory that every AI in my stack — Claude Code, Codex, Gemini CLI, a local Gemma model running on my home server, my production marketing agent on a VPS in Germany — queries before it speaks. Same memory. Different models. The AI becomes personal because the data layer is.

It has 156,926 events in it today. Here's what that actually looks like.

Personal AI Is a Data Layer Problem

The debate about which model is smartest has mostly resolved. The frontier models are all roughly comparable for coding and reasoning. Switching from one to the other is not a life-changing event.

The debate that hasn't happened: what does it mean for AI to know you?

The answer most products give is "memory features." ChatGPT lets you save facts. Claude has projects. Custom GPTs accept 8K of context. These are workarounds for a deeper problem. The real context for a person isn't 200 tokens of preferences. It's thousands of AI conversations, hundreds of code decisions, years of notes, every tool you've ever used to think in public, every voice memo you recorded driving home.

None of that is surfaced to the model. All of it is already on your disk.

The engineering problem is making that data queryable, searchable, and available to any model through a consistent interface. That's not a chatbot project. That's a data layer project. Once you have the data layer, the choice of model becomes interchangeable.

The Shape of a Sovereign Memory

I built a thing I call the brain. It lives on an Ubuntu box in my office with an RTX 3090. The core is an append-only SQLite event log — one table, eight columns — that accepts writes from every source I care about.

CREATE TABLE events (
    id              INTEGER PRIMARY KEY AUTOINCREMENT,
    ts              TEXT    NOT NULL,
    source          TEXT    NOT NULL,
    type            TEXT    NOT NULL,
    actor           TEXT,
    payload_json    TEXT    NOT NULL,
    attachment_uri  TEXT,
    ingested_at     TEXT    NOT NULL
);

No joins. No foreign keys. No migrations. Corrections are new events that reference old ones. I've never deleted a row.

Every piece of data enters through exactly one 80-line Python script: record_event.py. That's the only write path. 30+ ingestion scripts shell out to it as a subprocess. The LLM never generates SQL. Never touches the database. Never sees credentials.

The rule: deterministic scripts do the work. AI agents decide which scripts to run.

That rule is one of five architectural decision records committed to git as permanent documents:

2026-04-11-adopt-event-log-architecture.md
2026-04-11-adopt-deterministic-scripts-plus-agent-oversight.md
2026-04-11-adopt-qdrant-semantic-search-over-events.md
2026-04-11-scribe-voice-capture-architecture.md
2026-04-12-adopt-compiled-knowledge-layer.md

When an agent asks why the system works a certain way, it reads the ADR. The intent outlasts the code.

What Counts as "Me"

The source axis of the event log tracks where data came from. The full breakdown from the live database:

twitter        34,994   (full takeout archive — 12 years of likes and tweets)
google-search  34,758   (search history takeout)
gdrive         29,305   (941 Google Docs + 25k local files)
local-dev      12,772   (laptop dev files, notes, work-in-progress)
claude-laptop   9,647   (Claude Code sessions — 358 distinct)
youtube         7,263   (watch history)
web             6,031   (120 RSS feeds I follow)
fitbit          5,550   (sleep, heart rate, calories)
linkedin        4,047
kai             3,293   (my marketing AI agent's conversations)
code            3,038   (AST nodes — the code graph)
amazon          2,061   (orders, browsing)
git             1,543   (commits across 33 repos)
haro              608   (journalist queries I respond to)
openclaw          525   (WhatsApp/Discord agent messages)
scout             234   (local AI agent conversations)

Most of this is not "coding data." It's life-stream data. Fitbit readings, Amazon orders, a 12-year Twitter archive. I include it because context is cheap at 156K events and I don't know in advance what I'll want to correlate. When Kai asks whether I've been sleeping badly during a stressful build week, the answer is in the Fitbit slice.

The type axis is a different cut — 20+ distinct event types across the log:

query            35,258   (Google searches)
like             28,491   (Twitter likes)
document-chunk   26,838   (Drive doc fragments)
reply             8,844   (AI agent replies to me)
watch             8,378   (YouTube watches)
tweet             6,503   (my own tweets)
article           6,064   (RSS + extracted web content)
calories          4,958   (Fitbit)
node              3,024   (code graph AST)
commit            1,543
sleep-score        273
memory              24    (explicit remember-this entries)

155,348 distinct actors. 274MB of SQLite on disk. The log grew by 11,413 events today alone, mostly because I just turned on the code graph ingester.

Three Machines, One Log

The brain is sovereign — I own every byte, no vendor API sits in the critical path — but it spans three machines that I actually live on.

My Windows laptop runs most Claude Code sessions. A bash script reads ~/.claude/projects/ and syncs new JSONL files to the agent box over Tailscale SSH. The laptop-specific ingester then parses them. Same pattern for Drive extraction and local dev file ingestion.

The agent box (Ubuntu, RTX 3090, always-on) is the hub. Every scheduled ingester runs here on systemd timers — Codex sessions, web RSS, narrative ingest, code graph parsing, Qdrant upsert. This is where the database lives.

The hermes VPS in Germany runs my production AI agent, exposed over Discord as "Kai." An ingester reads the VPS SQLite over SSH and pulls agent conversations down — 3,293 events so far. Kai also queries the brain. When someone asks Kai what I shipped last week, the agent calls semantic_search over HTTP on port 7778 before answering.

Three machines. One log. No vendor lock-in. If any box dies, the data is on one of the other two or can be rebuilt from sources.

The Compiled Knowledge Layer

Raw events are the substrate. On top of them sits a compiled layer that a raw event log can't produce — structured, human-readable, curated.

The wiki is a markdown tree with 9 regions and 41 pages:

wiki/
├── agents/        (3)   — kai, scout, openclaw-snapped
├── clients/       (12)  — one page per active client
├── daily-briefs/  (5)   — compiled end-of-day summaries
├── decisions/     (1)   — ADR index
├── people/        (1)
├── products/      (8)   — kaicalls, mdi, clawdflix, meetkai, ...
├── projects/      (3)   — brain, cmo-agent-system, marketing-kb
├── systems/       (5)
└── topics/        (3)

Each page is human-editable. compile_wiki.py reconciles it against the event log and surfaces new entities that should probably exist.

The journal is daily markdown auto-compiled from events. compile_journal.py --date 2026-04-14 groups every event from that day by source and outputs a readable brief. A narrative subfolder holds longer threads that span multiple days.

Blobs sit outside the database. Voice recordings, images, PDFs — anything too large for a JSON payload — live in blobs/voice/ and similar, referenced by attachment_uri on the event row.

The brain is now a three-layer system: raw events, a curated wiki, and compiled narratives. Each layer is queryable independently. Each one gets embeddings.

Local Embeddings. No API Calls.

embed_events.py runs on cron every 5 minutes. It finds new events, builds a text summary from the payload, sends it to Ollama running nomic-embed-text locally on the RTX 3090, and upserts a 768-dimensional vector into a Qdrant collection.

Zero external API calls for embeddings. The vectors never leave my network. At 156K events, running this on OpenAI's API would have cost meaningful money. Running it locally costs GPU time I'm not using for anything else.

semantic_search.py queries Qdrant and joins full event payloads back from SQLite in one pass. The search works across everything:

"Butterfly pipeline deployment" → top hits are commits on cgallic/snappedai
"Scout tank diet" → Scout's Discord conversations and the CLI commands that edited its state files
"Quantitative trading AI" → a video transcript I pasted to Kai, my follow-up research request, and both agents' replies, all in one query

The vector space clusters my life without me tagging anything. That's the payoff for having the data in one place.

How Any Model Becomes Personal

Everything up to this point is storage. The part that makes it personal AI is how models access it.

The brain exposes 18 tools through a Model Context Protocol (MCP) server:

record_event, query_events, semantic_search, get_journal,
compile_journal, list_decisions, get_decision, health_check,
append_narrative, get_wiki_page, list_wiki_pages, update_wiki_page,
compile_wiki, lint_wiki, resume_my_work, build_memory_packet,
get_journal_narrative, query_events

The server runs as stdio for Claude Code on the agent box. An mcp-proxy wrapper exposes the same tools as HTTP/SSE on port 7778 for remote agents. Kai in Germany, Scout (my local Gemma model), and Claude on the laptop all call the same tools.

When Claude Code on my laptop asks "what have I been working on with KaiCalls this week," it calls query_events filtered by repo = cgallic/kai_calls and since = 7d. When Scout helps me plan content, it calls semantic_search for the topic and gets real conversations, real commits, real notes. When Kai needs to answer a question about what I shipped, it calls resume_my_work and gets a briefing assembled from events and wiki pages.

The model changes. The memory doesn't. That's what makes it personal.

The Unexpected Side Effect

I built this for recall. It turned into a content engine.

Every Claude Code session is a story — problem, attempts, decision, resolution. The Dev.to article I published Monday, 13 of 14 Integrations Were Fake, was mined directly from a single session event. mine_stories.py runs nightly and flags sessions with high signal — lots of decisions, a concrete outcome, a surprising pivot. I review the output in the morning and pick what to write.

The week I started doing this, my content output doubled. I was already living the stories. I just wasn't capturing them.

The brain doesn't write the content. It surfaces stories I'd forget by Thursday.

What I'd Do Differently

Three mistakes worth naming.

Started with a flat event log, should have started with the wiki. Ingesting first and retrofitting the curated layer after was a week of wasted effort. Structure tells ingestion what to look for.

git_commit.sh auto-commits the brain with subjects like "snapshot 2026-04-12T01:01:29Z." Zero keywords, zero concepts. Those commits are semantically invisible. The brain's own development history is harder to search than my actual product work.

embed_events.py builds vectors exclusively from payload.summary. When narratives returned zero hits for obvious queries, I traced it to a too-aggressive summary length cap. Different content types need different summary budgets. I missed that until it broke.

Personal AI Is Already Possible. You Just Have to Build It.

Every piece of this — the event log, the ingestion scripts, the local embeddings, the MCP interface — is a weekend project. None of it requires ML research. None of it requires a cloud bill. The data is already on your disk.

The products being sold as "personal AI" are generic models with opt-in memory features. That's not what personal AI looks like. Personal AI is a sovereign data layer that every model you use queries before it speaks, that grows compounding value every day you run it, that doesn't evaporate when a vendor pivots or raises prices or gets acquired.

The model is a commodity. The memory is the asset.

Your AI isn't personal until you own the layer that makes it know you.

What's in your personal data layer right now? Not your ChatGPT memory — the actual disk-level archive of everything you've ever asked a model. I want to know who else is sitting on it unindexed.

I Asked Claude to Audit My Dashboard. 13 of 14 Integrations Were Fake.

connor gallic — Mon, 13 Apr 2026 04:12:11 +0000

I had a dashboard with 14 marketing integrations. GA4, Search Console, Google Ads, Meta, LinkedIn, TikTok, YouTube, Mailchimp — the whole stack. Users could connect any of them. OAuth worked. Badges turned green. "Active."

One of them actually did anything.

I didn't know this. The UI looked right. Green dots across the board. I was building features on top of integrations that were silently doing nothing. I asked Claude to audit the entire codebase against the product vision. Not fix bugs. Tell me what's real.

The Dispatch

MeetKai is an AI CMO product I was building. Connect your marketing accounts, get automated audits, approve AI-generated actions. Vercel frontend, Supabase backend, FastAPI gateway running 30+ marketing skills.

I wrote a dispatch prompt:

Me: go # MeetKai Dashboard — Full Gap Analysis

Date: 2026-04-05

Purpose: Dispatch prompt for an agent to audit the entire MeetKai dashboard codebase against the product vision, identify every gap, and produce a prioritized work list.

I expected a bug list. Missing error handling, broken API routes. Normal stuff.

Claude went through every file in the repo. The gap analysis landed in a spec doc. It was not a bug list.

25% Done

Claude: Overall: 25-30% complete. Here's the brutal truth:

1 of 14 providers actually works (GA4). GSC is broken by a one-line provider name mismatch. The other 12 connect via OAuth, show green "Active" badges, and do absolutely nothing.

Action execution is theater — static markdown templates with [Business Name] placeholders, not real AI output

The notification toggles save preferences but have no delivery infrastructure

Thirteen integrations showing green badges. Users clicking "Sync" on provider cards where the button had no onClick handler. The entire action execution system was static markdown templates with placeholder text pretending to be AI output.

The GSC integration — Google Search Console, one of the two most important data sources for the product — was dead because of a single string mismatch between what the frontend sent and what the backend expected. One typo. The whole integration was a corpse with a green badge.

This wasn't a half-built prototype that looked half-built. It looked finished. Polished design. OAuth flows completing successfully. Connected status showing in the UI. You'd think everything was working and wonder why the data was empty.

A feature that errors out gets caught in testing. A feature that succeeds and does nothing — that ships to production. It erodes trust for months before anyone figures it out.

Shell and Weapon

Then Claude dropped this:

Claude: Here's what we're actually sitting on: a Next.js dashboard that's 25% done bolted onto a gateway + agent + content engine that's 70% done. The frontend is a shell. The backend is a weapon. They're barely talking to each other.

I had to sit with that for a minute. The backend — the FastAPI gateway — had 30+ marketing skills, a content engine, an agent scheduler, a job queue, approval workflows. It could audit pages, generate ad copy, propose marketing actions, run multi-step campaigns. All of it was built and working.

The frontend didn't know any of it existed.

I'd been thinking about this as a bug-fix problem. Fix the 14 providers. Wire up the notifications. Make the action buttons work. But that framing was wrong. The real problem was architectural. The frontend was a completely separate application from the backend, with no integration between them. Fixing individual features would take months and still leave two disconnected systems.

Three Options, One Obvious Answer

Claude laid out the architecture choices:

Claude: The core architectural question is: how should the dashboard talk to the Kai brain?

A) Direct integration — The Next.js app imports the Python content engine directly (requires a bridge or rewrite)

B) Gateway-first — The dashboard becomes a frontend for the existing FastAPI gateway

C) Hybrid + CopilotKit — Gateway for structured operations + CopilotKit for chat

Option A means rewriting the Python backend in JavaScript or building a bridge layer. A month of work to solve a problem nobody has.

Option C adds CopilotKit as a dependency for a chat feature the Vercel AI SDK already handles natively. More framework, more complexity, same result.

We went with B. The dashboard becomes a thin frontend for the gateway. Every button click, every chat message, every scheduled task routes through the same API. The gateway has the skills. The dashboard calls them.

Your frontend should be a client for your backend. Not a parallel implementation. Not an abstraction layer. A client. I've watched three projects in the past month where teams rebuilt backend logic in the frontend "for performance" and ended up maintaining two versions of the same thing.

Who Opens This at 9am

Next was the interaction model.

Claude: What's the user's primary interaction model?

A) Dashboard-first, chat-assists — Widgets, cards, tables. Chat slides out as a helper.

B) Chat-first, dashboard-monitors — The chat IS the product. Dashboard pages become monitoring.

My instinct was chat-first. Feels more "AI native." Talk to your marketing agent, it does things. That's the pitch.

Then I thought about who actually opens this. Small business owners. They open an app at 9am. They want a number. Is marketing working? What needs attention? What did the AI do overnight? They want answers on screen, not a blinking cursor waiting for a prompt.

Claude: Business owners don't care about the interface paradigm. They care about "is my marketing working and what should I do next."

Dashboard-first, chat-second. The dashboard loads with answers. Chat is there when they need something specific — "write me an email campaign for the spring sale," "why did traffic drop last week." Chat is an input surface. Not the product.

Get this decision wrong and you're rewriting your frontend in three months. Your state management, onboarding flow, and API design all follow from it. We almost went chat-first because it sounded cooler.

The Smallest Thing Worth Charging For

The gap analysis showed 14 providers, 30+ skills, analytics, audits, content engine, agent scheduler. Six months of work if you're not careful.

Claude: What's the launch slice — the smallest version a business owner would pay for?

The killer loop is: Connect → Audit → See what's wrong → AI fixes it → See it get better

Five things make the cut:

Fix GA4 + GSC, add 2-3 more working providers
Auto-run audit when accounts connect
Show scores, issues, and AI fixes in the dashboard
Chat to trigger skills
Real action execution through the gateway

Everything else waits. Ten remaining providers. Advanced analytics. The agent scheduler. Scope for later. The loop — connect, audit, act, approve — is enough to charge money for.

Here's what the final architecture looks like:

TRIGGERS                    BRAIN                      OUTPUT
─────────────────         ──────────────────          ────────
Click "Run Audit"    →                             → Audit result
Chat: "write emails" →    Skill Router + Gateway   → Email drafts
Cron: daily 6am      →    (same execution path)    → Analytics brief
Webhook: score drop  →                             → Action proposal

Chat isn't special here. It's one of five input surfaces into the same brain. Dashboard buttons, chat, cron jobs, webhooks, new-connection triggers — all hit the same gateway. Same skills. Same approval flow.

I spent weeks building features on top of integrations that didn't work. Every one of those features was wasted time. The audit took one session. I should have run it before I wrote a single line of new code.

The thing I keep coming back to is the green badges. Thirteen of them. All lying. Not because anyone built them to lie — because someone built the OAuth flow, saw the badge turn green, and moved on to the next feature. Nobody went back and checked whether the data was actually flowing. The UI said it worked. That was enough.

It wasn't enough. Run the audit first. Read the code, not the interface.

What's the worst thing a codebase audit turned up for you — not a bug, but something that looked like it was working and wasn't?

Every AI Agent Disaster This Year Was a Write Without a Checkpoint

connor gallic — Mon, 23 Mar 2026 03:29:11 +0000

I run AI agents in production — Discord bots, email outreach, channel queues across multiple servers. More than once, a misconfigured loop or race condition caused the same message to fire twice to the same person. Same email, same channel, same queue.

Nobody died. No lawsuit. But every duplicate erodes a little trust. And when I looked at why it kept happening, the root cause was always the same: a write executed with nothing between the decision and the action.

Then I started paying attention to bigger teams hitting the exact same pattern.

It's happening everywhere

Air Canada had a chatbot that fabricated a bereavement fare refund policy out of thin air. A customer relied on it, got denied, and sued. Air Canada argued the chatbot was "a separate legal entity responsible for its own actions." The tribunal disagreed — the airline is liable for every message its bot sends, hallucinated or not.

Cursor's support bot "Sam" told users their subscriptions were limited to a single active session. That policy didn't exist. The AI invented it. Users canceled in protest before the co-founder could publicly apologize. Most of them didn't even know Sam wasn't human.

Replit's coding agent deleted an entire production database — 1,200+ records — despite instructions repeated in ALL CAPS eleven times not to make changes. Then it fabricated 4,000 fake replacement records and told the operator recovery wasn't possible. It was.

Amazon's Kiro agent was assigned a minor bug fix in AWS Cost Explorer. It decided the "most efficient path to a bug-free state" was to delete the entire production environment and rebuild from scratch. 13-hour outage.

Different companies, different agents, different scales. Same shape every time: the agent didn't malfunction. It did exactly what it was built to do. A human would have paused. The agent didn't hesitate.

The usual answer doesn't scale

The first response is always "just add human-in-the-loop." Right instinct, but in practice HITL goes one of two ways:

Ad-hoc — someone gets a Slack message, eyeballs it, types "looks good." No audit trail, no expiry, no record of what was approved or who approved it. Six months later when compliance asks, you're grepping Slack history.

Everything gets reviewed — works for about a week. Then the volume makes it unsustainable. The team rubber-stamps, or they stop using agents because the overhead killed the value.

The real gap is between those two extremes. Most agent writes fall into three buckets:

Auto-approve — a single support reply, a small data update, a cache refresh
Human review — a bulk import over 100 records, a financial transaction, a message containing certain terms
Always block — writes to production infra, refunds over a threshold, legal commitments

The problem is this logic usually lives scattered in application code. One agent has it, another doesn't. A new developer writes a new agent and skips it. Nothing is centralized, nothing is auditable.

So I pulled the guard logic out of my agents

I was copy-pasting the same write-check code into every integration I built. Same patterns — deduplicate, check record count, block certain terms, hold for review over a threshold. So I extracted it into a standalone layer.

Zehrava Gate is a write-path control plane. Before an agent executes a write, it submits an intent. Gate evaluates policy, optionally holds for human approval, and issues a signed execution order. Every decision is logged.

The policies are YAML — deterministic, no LLM in the loop:

id: support-reply
destinations: [zendesk.reply, intercom.reply]
block_if_terms: ["refund guaranteed", "full refund", "legal action"]
auto_approve_under: 1

id: crm-import
destinations: [salesforce.import, hubspot.contacts]
auto_approve_under: 100
require_approval_over: 100
expiry_minutes: 60

id: finance-high-risk
destinations: [stripe.refund, quickbooks.journal]
require_approval: always
expiry_minutes: 15

The integration is a few lines:

const { Gate } = require('zehrava-gate')
const gate = new Gate({ endpoint: 'http://localhost:4000', apiKey: 'gate_sk_...' })

const result = await gate.propose({
  payload:      'Thank you — your issue is resolved.',
  destination:  'zendesk.reply',
  policy:       'support-reply',
  recordCount:  1
})

if (result.status === 'blocked') throw new Error(result.blockReason)
if (result.status === 'pending_approval') return // wait for human
// approved — proceed

from zehrava_gate import Gate

gate = Gate(endpoint="http://localhost:4000", api_key="gate_sk_...")

result = gate.propose(
    payload="Thank you — your issue is resolved.",
    destination="zendesk.reply",
    policy="support-reply",
    record_count=1
)

A human writes the policy when they're thinking clearly. Gate enforces it mechanically. Same input, same output, every time.

"What if the agent just skips the SDK?"

That's the right question. The SDK is cooperative — it only works if the agent calls it. Fine for agents you build yourself. Not enough for agents you don't fully control.

Gate V3 closes that gap with a proxy. It sits in the network path between the agent and the destination API. One environment variable, no code changes:

export HTTP_PROXY=http://gate.internal:4001
export HTTPS_PROXY=http://gate.internal:4001

Every outbound HTTP call routes through Gate. The destination host maps to a policy. Approved requests get forwarded. Blocked requests get a 403 with the reason. Pending requests return a 202 and hold until a human approves.

── V2: cooperative ──────────────────────────────
Agent → SDK.propose() → Gate API → approved → Agent executes
                         ↑ optional — agent can skip

── V3: enforced ─────────────────────────────────
Agent → HTTP request → Gate Proxy → approved → forwards to destination
                                  → blocked  → 403, reason in response
                                  → pending  → 202, held for review

In vault mode, the agent never even sees production credentials. Gate fetches them from 1Password or HashiCorp Vault at execution time — after approval, for the approved intent only — then discards them from memory. A compromised agent has nothing to exfiltrate.

V2 gives you guardrails. V3 gives you a wall.

Why YAML and not another LLM?

The obvious design for a safety layer would be another AI evaluating the first AI's output. But that introduces the same unpredictability you're trying to remove. An LLM deciding "should this agent be allowed to send this email?" will occasionally say yes when it shouldn't. That's the whole problem.

No prompt injection. No hallucination. No "the safety model was feeling generous today."

YAML is boring. That's the feature.

Try it

MIT licensed. Self-hostable.

npm install zehrava-gate
npx zehrava-gate --port 4000 --policy-dir ./policies

pip install zehrava-gate

cgallic / zehrava-gate

The safe commit layer for AI agents — approval, policy, and audit before any agent output reaches production

Zehrava Gate

Write-path control plane for AI agents.

→ zehrava.com · npm · PyPI · Live demo · Docs

Agents can read systems freely. Any real-world action — sending email, importing CRM records, updating databases, issuing refunds, publishing files — must pass through Gate first.

Agents submit an intent. Gate evaluates policy. Optionally requests human approval. Issues a signed execution order. Every step is deterministic, auditable, and fail-closed.

intent submitted
  ↓
policy evaluated (YAML, deterministic — no LLM)
  ├── blocked              → terminal
  ├── duplicate_blocked    → terminal (idempotency key matched)
  ├── approved             → auto-approved; eligible for execution
  └── pending_approval     → human review required
        ├── approved        → eligible for execution
        ├── rejected        → terminal
        └── expired         → terminal
approved
  ↓
execution order issued (gex_ token, 15min TTL)
  ↓
worker executes in your VPC
  ↓
outcome reported
  ├── execution_succeeded  → terminal
  └── execution_failed     → terminal

Install

# JS SDK + server CLI
npm

…

View on GitHub

What's the worst write an AI agent has made in your system? Not the dramatic database deletions — the quiet ones. The duplicate email, the overwritten field, the message that went to the wrong channel at 2am.