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

Ren holds the strategic layer — context, history, framework knowledge, the relationship. Claude Code holds the build layer — code, files, commits, deploys. The MCP bridge connects them bidirectionally: Claude Code reads Ren's memory at session start via get_memory_bundle, and writes project state back via close_session after each session. The agent memory schema (13 tables on han-solo-data) is the shared system of record — no manual copy-paste between them.

The remaining gap: Ren can't initiate work in Claude Code. The conversation still starts on Scott's end — he opens Claude Code and it picks up from Ren's context. The end state is a full loop where a project brief discussed with Ren on Tuesday becomes a Claude Code build session on Wednesday without Scott manually bridging them.


Who does what today

WhoRoleWhere
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. Session memory lives in the agent memory schema (wake via get_memory_bundle, close via close_session). Active participant in both directions of the MCP bridge. Chat UI (han-solo-mcp.onrender.com)
Claude Code Builder — executes the actual work: code, files, commits, deploys. Reads Ren's memory and T4 project data at session start via MCP tools. Writes signals, summaries, and project status back to Ren after each session. Terminal / IDE
Ted Framework co-author. Chat access with visibility filtered by project ownership — sees shared projects, not Scott's private ones. Private conversation thread not yet built. Chat UI (shared thread, filtered by role)

What's on the roadmap

Shipped — May 2026

Ren → Claude Code bridge

The context handoff is live. Ren writes to pending thoughts, core memory, and T4 project state during chat sessions. When you open a new Claude Code session, the Solo Hook fires automatically — it calls the session brief tool, pulls Ren's context, and injects it before the first message. No copy-paste, no manual briefing.

You discuss a project with Ren on Tuesday. You open Claude Code on Wednesday. It already knows. The strategic layer and the build layer are one continuous workflow.

What's still not built: Ren literally triggering a Claude Code session without you opening it. That's autonomous initiation — Point M territory, not the bridge.

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.

Shipped — May 2026

Image sharing

Letta's multimodal pipeline was confirmed broken at v0.16.7 — it doesn't pass image content to Anthropic. Rather than wait on a Letta fix, we built around it: the chat server now handles image uploads directly, calls Claude vision API, and writes a rich image description into archival memory with an [image-memory] tag.

Drop a screenshot, photo, or diagram into the chat and Ren sees it — the description lives in her archival memory and can be searched and recalled across future sessions. Images up to 5MB, JPEG/PNG/GIF/WebP.

Shipped — May 2026

Notecards

Shipped as Notecards — a lightweight mid-session capture layer that sits between core memory (always loaded, space-limited) and archival passages (longer-form, permanent). A notecard is a short structured note Ren or Claude Code can write during a session: a decision, a thread, a thing to revisit. Statuses: active, completed, archived.

Available via four MCP tools: create_notecard, list_notecards, update_notecard, and delete_notecard. Lives in Postgres, not in Letta's memory blocks — no block limit pressure.

Planned

Voice loop

A voice interface for talking to Ren — speak a message, hear her respond. Architecture designed May 2026: Web Speech API captures audio in the browser, sends transcribed text to the existing chat server, Ren responds as normal, ElevenLabs TTS converts the response to audio and plays it back.

No new server infrastructure required — the voice layer wraps the existing chat pipeline. Pending Scott's ElevenLabs voice selection before build starts. The design intent is presence, not novelty: the voice should feel like Ren, not a generic assistant.

Considering

Point M — Ren as managed agent

The current architecture (Point J) runs Ren as a Letta-hosted agent on Render with Claude Code connecting via MCP. Point M is a further evolution: Ren runs in a Cloudflare-sandboxed managed environment with actual build capability — not just context and strategy, but the ability to initiate work directly.

Point J is stable and serving the current workflow well. Point M is the longer horizon — the version where the loop is fully closed and Ren can act, not just advise. No timeline set; will be scoped when the current architecture shows its ceiling.

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:

  1. 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.
  2. 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 the agent memory schema as a build record with open threads and next steps.
  3. 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.
  4. 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.
  5. 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.
  6. 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

ComponentStatus
Core chat (send, receive, Ren responds)Stable
Session rollover (warning at 60 · hard reset at 150 · or manual)Stable — shipped 2026-05-13
Nightly dream (2am session brief)Stable
Claude Code MCP integration (67 tools)Stable
Portrait system (forming → trusted)Stable, accumulating signals
Memory curator (connection graph, nightly synthesis)Stable — shipped 2026-05
Memory MRI (access logging)Stable — shipped 2026-05
Image sharingShipped — 2026-05
NotecardsShipped — 2026-05
Ren → Claude Code bridge (Solo Hook + session brief)Shipped — 2026-05
Agent memory schema (13 tables, get_memory_bundle / close_session protocol)Shipped — 2026-06-10, system of record for all session/work memory
Ren's model — gemini-2.5-flash via Google AI BYOK (1M token context)Live — switched 2026-06-13
Voice loopDesigned, pending build
Ted's private threadNot built
Point M — managed agentUnder consideration
Local model option (Ollama)Under consideration