Annalea Layton

Annalea Layton · Systems designer & AI-native builder

Projects

Each project carries a status label. Labels are never upgraded: if something is a prototype, it says so.

What the status labels mean
Live per changelog
The product's own changelog says it launched. Not re-checked here.
Built
The code exists on the main branch.
Locally verified
Run on my machine. Not run in automated CI.
Prototype
Runs locally on my machine.
Behind flags
Built, and switched off by default.
Draft
A specification that is still in draft.
Counted
A number taken from the code on the date shown.

The product

JUWEL

Status: Live per changelog 2026-09-04

A persistent AI working environment that turns human intent into completed, verifiable work. Today it offers chat, private chat, memory you control, history and approvals. It runs in the browser, with voice when available. Outward actions are designed to pause for your explicit approval.

JUWEL public launch, per the changelog entry of 2026-09-04 (the entry calls it JUWEL OS 1.0). The newest entry, 2026-10-07: replies keep coming when one AI provider is down.

Mail, calendar, files, IDE, terminal and browser connectors are coming. None of them is shown here as live.

The first three screens are rendered from JUWEL's own code (main, 2026-10-28), with placeholder conversation text and no live connection. The fourth is an earlier screenshot from the product's own assets.

JUWEL's front door: the JUWEL mark above the heading "What's on your mind?", two starter buttons, Plan my week and Draft a message, and a reply box with a Quick selector and a microphone.
The front doorRendered from JUWEL's own code, main 2026-10-28
A JUWEL conversation: the question "Can you fit a dentist visit in?", two checked steps, a reply offering two options, and a "Where this came from" line saying no tool ran.
A conversation, with its steps and sourcesRendered from JUWEL's own code, main 2026-10-28
An approval card in a JUWEL conversation: a drafted weekly update to the design team with To, Subject and body shown, and equal Approve and Cancel buttons, noting it runs once and only if approved.
An approval card: it runs once, and only if you approveRendered from JUWEL's own code, main 2026-10-28
JUWEL at launch on a light desktop: a chat window greets with "I'm JUWEL." and four suggested prompts, with an app dock on the left and an ask bar along the bottom.
JUWEL · public launch per changelog 2026-09-04A screenshot from the product's own assets, not rendered today

Security and backend

Security

Status: Built Formal models: locally verified

The security model behind JUWEL's rule that machines show their receipts and humans approve. I architected and directed it with a human and agent team: I set the requirements and the test gates, and agents wrote much of the code.

Built means the code exists on the main branch, checked 2026-10-28. It is not a production audit.

  • Approval before acting

    19 tools that act in the outside world, such as sending mail or creating events, each need a single-use approval. It is bound to the exact action, lasts 5 minutes and is spent once. An agent key cannot approve its own action, and the door for outside agents enforces the same gate. If the person has left, the action is not run and is recorded as cancelled.

  • Signed receipts

    Ed25519 signatures, a hash chain, Merkle batches and signed checkpoints, with a public verify page. Production refuses an ephemeral signing key.

  • Agent keys

    Scoped, revocable and never auto-granted. Forged or unknown tokens reveal nothing about whether a key exists.

  • SSRF guard

    Web fetch re-checks the resolved address when it connects and again on every redirect, so a DNS trick between the check and the connection is still caught.

  • Rate limiting

    Limits fail closed when the store has a fault. A checker, with its own seeded-defect self-tests, proves that new endpoints cannot skip them (census 172 → 190 handlers).

  • Formal methods found a real race

    12 TLA+ modules and 18 Lean files, written by AI under my direction. Model checking found a real race in the approval decision path: two overlapping decisions could overwrite each other. The fix is specified and not merged yet. Run on my machine, not in CI.

    Locally verified
See the function that spends an approval 
async function consumeApproval(uid, tool, params, nonce) {
  if (!nonce || typeof nonce !== "string" || !uid || !tool) return false;
  const hash = paramsHash(params);
  const key = approvalKey(uid, tool, hash);
  let raw;
  try { raw = await redis(["GETDEL", key]); } catch { return false; }
  if (!raw) return false;
  let rec;
  try { rec = JSON.parse(raw); } catch { return false; }
  return approvalRecordMatches(rec, uid, tool, hash, nonce);
}

An excerpt from the main branch: the code is unchanged and its explanatory comment is left out. GETDEL reads and deletes the approval in one step, so one click cannot be spent twice, and any store fault means "not approved".

Backend

Status: Built

The server side of JUWEL: model providers, retrieval and long-running work, designed to keep answering, keep tenants apart and show where an answer came from.

JUWEL's intent trace opened under a reply: Who, What, How, True and Safe lines reading a guest, something to do, used 2 tools, kept 2 receipts and nothing sent or changed, two checked steps, and a timing trace of one turn measured on this device.
What JUWEL understood, what it checked, and how long each step tookRendered from JUWEL's own code, main 2026-10-28

  • Replies keep coming when one AI provider is down

    An ordered chain of providers, each tried at most once per turn, inside one shared time budget so a failover cannot triple the wait. If every link fails, the error is typed and lists the attempts.

    Live per changelog 2026-10-07

  • Knowledge graph and retrieval (RAG)

    Private clusters per person, learned notes marked untrusted, credential-bearing documents quarantined out of results, weak matches dropped, and every passage returned with its citation.

    Built

  • One driver per job

    A database lease with a fencing token, so exactly one driver runs each job and a replaced driver cannot take it back.

    Built

How I build

An orchestrated swarm

Status: Counted 2026-10-28

One agent orchestrates, others read and build, and a closer re-runs the claims before they count. Opus orchestrates and verifies, Haiku scouts read, Sonnet workers build one task each with exclusive files, and an Opus closer never writes production code. The lanes mix Claude, Codex and Devin.

Counted 2026-10-28 from the main branch, except the task-folder count, which is a local count. The workflow scripts that run the swarm are local too.

  • A closer re-runs the claims

    A 149-node verification graph with 921 checker scripts.

  • Receipts with honest labels

    86 swarm receipts. 81 carry a label: 71 say Built, and none claims Live.

  • Commits under my name

    1,598 of the 3,749 commits on the main branch are under my name. The repository has 660 merged pull requests: most opened from my account (agents push through it), the rest by a second collaborator and an agent integration. Agents commit alongside me: about 46% of the non-merge commits are theirs.

  • Directed at volume

    225 AI-directed task folders between 2026-07-26 and 2026-10-27.

Also built

More of the platform

Parts of JUWEL that exist in the code and are switched off or still in draft. None is shown as live.

  • Her Desk

    Built into JUWEL and shipped dark: it exists in the code and is switched off by default.

    Built

  • VKP 0.1

    An agent-runtime protocol, still in draft. A binding for the Model Context Protocol and its route are built. Production conformance is deferred.

    Draft

  • Slack, Google Workspace and Microsoft 365

    A Slack app and a Google Workspace add-on are built behind flags, with skeletons for Microsoft 365 and Teams. Not live.

    Behind flags

Games

Contact

Seeking remote roles or bounded freelance projects while continuing Vext Labs.

Email Annalea x.com/annalea_l Résumé