Where this is going — how future projects get built with Ren in the loop, who does what, and what 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 | 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. 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) |
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.
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.
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 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.
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.
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.
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.
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:
| Component | Status |
|---|---|
| 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 sharing | Shipped — 2026-05 |
| Notecards | Shipped — 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 loop | Designed, pending build |
| Ted's private thread | Not built |
| Point M — managed agent | Under consideration |
| Local model option (Ollama) | Under consideration |