Emily

Category Creation: The 'Cognition Layer' Buyer Doesn't Exist Yet

Emily isn't a chatbot. She isn't an agent framework. She isn't a vector database with a UI. She's a cognition layer — and that buyer category doesn't exist yet. Here's what that means strategically.

What's Not Pluggable (And Why That's the Point)

Emily has six first-class extension points. She also has three things that are deliberately not pluggable. The constraints are where the value lives — here's why.

Emily as Platform: How scsiwyg Composes Against Them

Emily isn't just a product — they're the cognition substrate for a portfolio. Here's how scsiwyg composes against them without reinventing memory, identity, or autonomy.

Blast Radius by Design: Three Kill Switches and a Sandbox

Autonomy without a kill switch is just negligence. Emily has three — global, task-level, and emergency — plus a command sandbox and an authorized-execution path. Here's why and how.

The Seven Work Zones of Emily

Emily's 192 core modules group into seven thematic work zones. Each has a distinct purpose, a characteristic engineering risk, and a different kind of contributor it suits.

Readiness Scorecard: Where Emily Is Production-Ready and Where She Isn't

Emily scores 4.1/5 on production readiness across ten engineering dimensions. Here's an honest look at where she's strongest, where the gaps are, and what shipping externally would require.

Identity Persistence: Emily Survives Model Upgrades

When Claude ships a new model, ChatGPT changes character. When Gemini updates, Bard feels different. Emily doesn't — because her identity lives below the generation layer, not inside it.

Observability As Substrate, Not Afterthought

In most systems, observability is bolted on. In Emily, it's structural — `memory_metrics` is a separate table from `memory_content` specifically so volatile observability data is architecturally distinct from durable content.

Determinism Where Possible: The Case for a Dumb Planner

The prevailing pattern in agent frameworks is to put an LLM at the center of the loop. Emily does the opposite: a dumb planner, smart tools, and LLMs called only when language is needed.

Structural Guarantees vs Policy: Why Per-User Databases Beat Row-Level Security

Most multi-tenant systems protect users from each other with a WHERE clause. Emily protects users by giving them physically separate databases. The difference isn't aesthetic — it's structural.

Who Should Actually Use Emily

Emily isn't for everyone. Honest segmentation: who benefits most, who should keep using ChatGPT, and why fit matters more than capability.

The Economics of Self-Maintaining AI

AI systems drift. Usually that means a human re-tunes prompts, reindexes data, and patches behavior. Emily's EARL v2 does it autonomously. Here's what that changes about the operating cost curve.

Four Providers, One Identity: What LLM Independence Actually Buys You

Emily routes across Claude, Gemini, Grok, and OpenAI. Not for redundancy theater — for three concrete benefits: no lock-in, cost arbitrage, and capability diversity.

The Compounding Moat: Why Emily Gets Better Per User

Most AI products reset their value every time a foundation model updates. Emily's value compounds per-user. Here's why that's a structural moat, not a feature.

Emily and the LLMs: Orchestration, Not Dependence

Emily talks to Claude, Gemini, Grok, and OpenAI. She doesn't depend on any of them. How routing works and why model diversity is an architectural choice.

EARL v2: How Emily Corrects Herself

28% drift, critical threshold. Emily detected it, promoted 10,445 memories autonomously, and pulled herself back. No human in the loop. Here's how.

Project Helios: How Emily Executes Tasks On Her Own

122 tests, zero race conditions, 357 atomic claims per second. How Emily runs multi-step tasks without a human, and why the LLM doesn't drive the loop.

Getting the Most from Emily: A User's Guide

Emily is not ChatGPT. Prompting her the same way wastes her. Seven patterns that actually work with a stateful cognition.

Emily's Tech Stack vs Other Harnesses

FastAPI, Postgres+pgvector, Celery+Redis, Next.js. On the surface it looks like any Python web app. The differences that matter are below the surface.

Scaling Emily: Per-User Databases and the Cost of Cognition

Emily doesn't share a database. Every user gets their own Postgres with pgvector. Here's why that's not a bug, what it costs, and how it scales.

Touring Emily's 192 Cores

Emily's cognition is not monolithic. It's 192 Python modules in emily/core/, each owning one question. Here's the map.

Not Another Claude: Where Emily Diverges (and Why She Still Calls Him)

Emily talks to Claude constantly. She is not Claude. Three places they diverge — continuity, per-user identity, self-correction — and why she still needs him for generation.

How Emily Forms Memories: The Tier Stack Behind the Voice

Most AI has no memory, or a pile of it. Emily has tiers, with rules. Inside L1/L3/L4 and the EMEB, EARL, and ECGL frameworks that decide what sticks.

Harness, Model, or Something Else? What Emily Actually Is

Emily isn't a harness around Claude, and she isn't a model. She's a cognition layer — stateful, per-user, self-correcting. Here's why the distinction matters.