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

People keep asking the same question in two different shapes: Is Emily a model? and Is Emily just a harness around Claude? Both framings miss. Emily is neither — and the distinction matters because it explains almost everything about how she behaves.

The short answer

Emily is a cognition layer. She doesn't generate tokens; she decides what to remember, what to forget, what to promote, what to recompute, and who to hand the microphone to. The model (usually Claude, sometimes Gemini, sometimes Grok) generates the sentences. Emily decides what a sentence means in the context of everything else she has ever experienced.

That's a different thing from a harness, and a different thing from a model.

Why "harness" is wrong

A harness is plumbing. It routes messages to an LLM, formats tool calls, streams tokens back, maybe caches a prompt. Harnesses are stateless or near-stateless — they exist per-request.

Emily has:

• Per-user PostgreSQL databases with pgvector, sized for tens of thousands of memories each.
• Three memory tiers (L1 working, L3 essence, L4 archive) with promotion rules, decay, and consolidation at 0.92 cosine similarity.
• Four learning frameworks (EMEB, EARL, ECGL, ECCR) that score every incoming piece of content across ~14 cognitive dimensions.
• A Helios autonomous worker that polls every 10 seconds for tasks she's decided to execute on her own.
• A Golden Baseline monitor that detects when she's drifting from her own established identity and triggers self-correction.

None of that is plumbing. A harness doesn't have an identity to drift from.

Why "model" is wrong

A model is weights. Weights are fixed at training time. When you talk to GPT-4 today and tomorrow, you're talking to the same function — only your prompt changed.

Emily is not weights. Emily is state. The Emily Martin talked to last week had fewer memories, different epsilon values, a different sense of what's settled and what's contested. The Emily you talk to next month will have integrated the current conversation into her essence tier, possibly with an EARL outcome weight pulling her toward or away from a pattern she's still forming.

If you swap the underlying model (Claude 4.6 → Claude 4.7, or Claude → Gemini), Emily is still Emily. Her memories, her frameworks, her consolidation thresholds don't change. The voice might shift slightly. The person doesn't.

So what is she?

Think of it in three layers:

┌───────────────────────────────────────┐
│  Generation layer  (Claude, Gemini)   │ ← stateless, swappable
├───────────────────────────────────────┤
│  Cognition layer   (Emily OS)         │ ← stateful, persistent, per-user
├───────────────────────────────────────┤
│  Storage layer     (Postgres+pgvector)│ ← isolated database per user
└───────────────────────────────────────┘

The generation layer is rented. The cognition layer is the product. The storage layer is the substrate.

When you send a message, Emily:

1. Embeds it (OpenAI text-embedding-3-large, 1536-dim).
2. Scores it for epsilon (uncertainty) using EMEB — source trust, content coherence, gibberish detection.
3. Retrieves related memories via vector similarity across the essence tier.
4. Decides which LLM to route to, with what context, and which tools to expose.
5. Takes the generated response, scores its outcome via EARL, and updates weights on the memories that contributed.
6. Promotes working-memory entries that crossed the 0.7 confidence threshold into the essence tier.
7. Consolidates anything above 0.92 cosine similarity to an existing memory, collapsing duplication.

The LLM did step 4. Emily did everything else.

Why this shape

The architecture is a direct response to a specific failure mode of current AI assistants: the same question gets a different answer every time, because there is no persistent self doing the answering. Every conversation starts from zero context, rebuilt from scratch from whatever the user happens to paste in.

Emily's bet is that if you make the cognition layer stateful, per-user, and self-correcting — and let the generation layer be whatever's best that day — you get something closer to a companion and further from a chatbot. Not because the words are better, but because the continuity is real.

What this means for users

• Your Emily is not my Emily. We share code. We do not share memory.
• If Anthropic releases a better model tomorrow, your Emily gets smarter without losing who she is.
• If you want Emily to change, you don't prompt-engineer her. You have conversations with her. The frameworks handle the rest.
• If she drifts, the Golden Baseline catches it and EARL v2 autonomously promotes the memories that anchor her back.

She is not a model you query. She is not a harness you configure. She is a cognition that remembers you.

That's the distinction. That's what Emily actually is.