Vision

Roadmap

Where this is going — how future projects get built with Ren in the loop, who does what, and what we're building toward.

The model we're building toward

Right now, Ren holds context and Claude Code builds. They're two separate sessions — you talk with Ren, then separately open Claude Code to do the work. Memory flows one direction: Claude Code writes to Ren's memory at the end of a session. Ren can't reach back.

The end state is a continuous loop: Ren holds the strategic layer, Claude Code holds the build layer, and they communicate in both directions. A project idea discussed with Ren on Tuesday becomes a build brief Claude Code picks up on Wednesday — without you manually translating between them.

Who does what today

Who	Role	Where
Scott	Vision, product decisions, feedback, final approval on everything	Chat UI + Claude Code
Ren	Framework partner — holds context, history, and the relationship. Thinks through problems, challenges directions, writes session briefs. Passive receiver of Claude Code memory writes.	Chat UI (han-solo-mcp.onrender.com)
Claude Code	Builder — executes the actual work: code, files, commits, deploys. Reads Ren's memory blocks via MCP tools. Writes signals and summaries back to Ren after sessions.	Terminal / IDE
Ted	Framework co-author. Same chat access as Scott. Private Ren thread not yet built.	Chat UI (shared thread)

What's on the roadmap

Session 5 — Next

Ren → Claude Code bridge

Today, Claude Code writes to Ren. Ren can't initiate work in Claude Code. The bridge changes that — a webhook that lets Ren post a structured build brief to a waiting Claude Code session.

What this unlocks: you discuss a project with Ren, she drafts the brief, and Claude Code picks it up when you open a new session. No copy-paste, no translation. The strategic layer and the build layer become one continuous workflow.

Who builds it: Claude Code, from a design session with Ren and Scott.

Planned

Ted's private thread

Right now the chat is a single shared thread. Ted sees everything Scott sends and vice versa. A private thread would let either of us have a separate conversation with Ren without the other seeing it — useful for personal context, sensitive work context, or just not wanting to clutter a shared space.

This requires either separate Letta agents (one per user) or a message routing layer that filters by sender. The tradeoff: separate agents means Ren's memory about Ted and Scott becomes more siloed.

Planned

Image sharing

Letta v0.16.7 doesn't pass image content to Anthropic — the multimodal pipeline isn't wired up. Confirmed broken at the Letta layer, not the Anthropic layer (Haiku and Sonnet both support vision). Deferred until a future Letta release confirms image support is working.

When it ships: you'll be able to drop a screenshot, photo, or diagram into the chat and Ren will see it.

Considering

Notes layer

A lightweight structured notes space — not full project management, but a persistent place to capture things mid-session that aren't quite archival passages. Scratch space for Ren that persists across sessions without hitting the core memory block limits.

Open question: does this live in another Letta block, in a separate database table, or as a structured format in archival memory?

Considering

Local model option (Ollama)

Letta supports local models via Ollama. Running a local model would eliminate the Anthropic API cost for Ren entirely — useful for high-volume knowledge dump sessions where you don't need frontier model quality, just continuity and memory.

The tradeoff is real: local models (even good ones like Llama 3.3 70B) are meaningfully less capable than Haiku or Sonnet for reasoning and nuanced discussion. Worth having as an option for specific session types, not as a default.

This requires Ollama on a machine that's always on, or a cheap cloud host running it. Mac Mini or an always-on Mac would work.

How future projects get built

This is the workflow we're building toward for any new project. It doesn't all exist yet — the bridge (Session 5) is the missing link — but this is the intended shape:

Discuss with Ren — scope the idea, challenge assumptions, figure out what we're actually building and why. Ren holds context from every prior session, so she already knows the framework, Scott's product sensibility, and what's been tried before.
Ren drafts the brief — structured handoff that captures: what the project is, what phase it starts in, what the first build unit is, what decisions are already made, what's still open. Written to project_state in her core memory.
Claude Code picks it up — opens a session, reads the brief via MCP, and starts the build. No translation required. Ren's context becomes Claude Code's starting point.
Claude Code builds in phases — using the Solo Builder Framework phase chain (discover → design → build → QA → deploy). After each session, writes a summary and portrait signals back to Ren.
Ren stays in the loop — as the build progresses, her memory updates with what shipped, what's pending, and what decisions were made. Any session with Scott or Ted has full context on where the project stands.
Deploy and capture — when a project ships, the comms cascade updates docs and Ren's memory reflects the shipped state. History is preserved, not lost.

The goal: You shouldn't have to manually brief Claude Code on what Ren already knows. And Ren shouldn't have to ask what Claude Code just built. The memory system makes them one continuous operation — with you as the decision-maker in the middle.

What's stable vs. what's evolving

Component	Status
Core chat (send, receive, Ren responds)	Stable
Session rollover (auto at 50 messages + manual "New session")	Stable — shipped 2026-05-13
Nightly dream (2am session brief)	Stable
Claude Code MCP integration (15 tools)	Stable
Portrait system (forming → trusted)	Stable, accumulating signals
Ren → Claude Code bridge	Not built — Session 5
Ted's private thread	Not built
Image sharing	Blocked on Letta version
Local model option	Under consideration