Skip to content

SEOS

A single-user chief-of-staff that unifies a cloud control plane, a local memory engine, and an agent runtime — so one person can operate like a team.

seo-os-agent.vercel.app
seo-os-agent.vercel.app

Case preview

SEOS

A personal AI operating system with a memory that dreams.

Next.js 16SupabaseVercel

The Problem

One person running a studio, a degree, and a stack of production products generates more context than any single tool can hold. Chat assistants forget between sessions. Notes rot. The work — decisions, risks, half-finished threads — scatters across a laptop, a phone, three IDEs, and a dozen repos.

SEOS is the answer to a specific question: what would it take for an AI to actually remember, and to actually do things, on my behalf — safely? Not a chatbot. An operating layer.

The test was never "can it answer." It was "does it still know this next week, and can it act without me watching."

The System

SEOS is three planes that stay in sync. A cloud control plane — a Next.js 16 dashboard and API on Vercel, backed by Supabase — holds tasks, reminders, journal, goals, clients, and an Agent Ops schema for runtime jobs, approvals, and events. A local memory engine (Chronicle) indexes an Obsidian vault into an embedded database and exposes it over MCP. And an agent runtime bridges the two: a worker on the laptop polls the cloud for queued jobs and executes them locally.

Fig. 1 — SEOS control plane, memory engine, and the agent bridge (simplified).

VercelNext.js 16 · 50+ routes
SupabaseAgent Ops · RLS
⇄ bridge ⇄
Laptop runtimeOpenClaw · Codex
+
ChroniclePGLite · 14 MCP tools

The clever edge is the bridge. Vercel can't reach into a laptop, so the laptop reaches out: it polls Agent Ops for new jobs, runs them under a workspace allowlist, and reports heartbeats and results back to Supabase. The cloud gets a durable runtime it never has to host, and risky actions — shell, file edits, push, deploy, send email — pause for an explicit approval before they run.

The Build

The memory engine runs a background dream-cycle distiller: it reads timeline events, extracts durable facts, resolves conflicts, and writes a per-project "compiled truth" file that agents load at session start. Fourteen MCP tools expose it to any compliant agent — Codex, Cursor, Claude Code, Claude Desktop — so the same memory follows Suven across every surface he works in.

Context is redacted before it ever moves: a secret-shaped-value scrubber runs on the packet that syncs to agents, so tokens and keys never leave the machine in the clear.

The Proof

Fig. 2SEOS Mission Control — local operator console (representative).
50+
API routes
14
MCP tools
~12.5k
frontend LOC
8+
agent surfaces

SEOS runs proactive jobs on schedule — morning briefs, evening check-ins, weekly reviews — through cron, and routes operator commands through Telegram and a WhatsApp channel. It is not a demo that resets; it is the system Suven actually runs his week on.

Margin Notes

  • What's still hard: cross-machine runtime identity. Scoping secrets per runtime so a token can't be replayed on a second laptop took more care than the feature that used it.
  • What I'd redo: the earliest memory schema mixed episodic events and compiled facts in one table. Splitting append-only timeline from mutable compiled-truth was the unlock — I'd design that split on day one.
  • What shipped anyway: graceful degradation. When an upstream provider is down, the system returns a structured degraded state instead of breaking — because a personal OS that falls over the moment an API blips isn't one you'd trust.

Next — 02

GovCompanion