Backboard, OpenRouter, and RedKey Memory Strategy

Date: 2026-05-06

RedKey currently uses several model providers and memory paths directly: Codex, Claude, Gemini, OpenAI embeddings, Supabase agent_memory, and tool-specific API keys. That works, but it makes model routing, memory continuity, cost control, and agent handoffs harder than they need to be.

The Backboard founder conversation suggests a stronger architecture:

• Backboard may become the memory and state layer.
• OpenRouter may become the default model routing layer.
• Supabase and Hedera should remain the control, registry, and audit layer.
• Direct provider keys should remain available, but should no longer be the default path for general model calls.

This document captures the relevant insights, target architecture, and first implementation spike.

Backboard frames memory as data with explicit weighting, not as a vague human-brain metaphor. That fits RedKey better than treating memory as opaque conversational history.

Relevant weighting dimensions from the conversation:

• recency: how recently memory was created or accessed
• frequency: how often a memory is used
• adjacency: related topics can affect a memory even when the exact memory is not directly touched
• temporal resonance: time and relative time affect whether a memory is relevant
• world-context change: external events can change the relevance or importance of a memory

This is more advanced than RedKey's current basic vector/recency retrieval model.

Backboard's "assistant" abstraction is effectively an isolated memory collection. That maps cleanly to RedKey memory slicing:

• one assistant per RedKey agent
• one assistant per role
• one assistant per client
• one assistant per project
• one assistant per expert/persona
• one assistant per marketplace expert product

The key property is isolation. A CPO memory scope should not pollute a dad memory scope; likewise, a Brooke sales memory scope should not pollute a developer-worker memory scope.

Backboard supports memory modes that map directly to RedKey execution needs:

• off: no memory used; good for isolated worker tasks and deterministic verification
• readonly: retrieve memory without writing new memory; good for controlled agents and review tasks
• auto: read and write memory; good for long-lived agents and expert personas

This aligns with existing RedKey patterns:

• some agents need full project context
• some agents need full company context
• some agents should have no memory beyond the task brief
• /teach should be a controlled write path
• reflection should produce candidate learnings, not uncontrolled memory sprawl

OpenRouter routes model calls, but it does not by itself provide durable memory. Each model call is essentially stateless unless the caller includes the right context.

Backboard can sit in front of OpenRouter:

``text RedKey agent -> Backboard state/context -> OpenRouter -> chosen model ``

That changes the model:

```text Without Backboard: Claude has one thread, Kimi has none, DeepSeek has none, Gemini has another. Each model switch requires RedKey to rebuild and repack context.

With Backboard: Backboard holds the working state. OpenRouter chooses the model. The selected model receives the relevant context for the task. ```

For RedKey, this matters because the cluster should be able to use cheaper or specialized models without losing continuity.

Backboard claims it can move state across different context windows using indexing and summarization, then reinflate when returning to larger contexts.

This maps directly to RedKey's biggest pain points:

• long projects
• headless workers
• task handoffs
• context compaction
• model switching
• small-context cheap models
• summarizing without losing important state

This needs a spike before we trust it, but the capability is strategically relevant.

Backboard's internal process uses retrospectives to update skill files, version those changes, and inspect regressions when a retrospective worsens behavior.

This validates RedKey's existing direction:

• reflection stages after large modules
• /teach for controlled memory insertion
• skill files as durable operating instructions
• versioned changes to agent behavior
• review when memory or skill updates cause regressions

The important distinction is that not every reflection should become durable memory. Reflection should generate candidate learnings. /teach or a governed memory write should decide what persists.

The founder stated that customer data/memories are segregated and owned by the customer, with anonymization available before context reaches model providers.

This is highly relevant, but should not be treated as enough for production-sensitive data until confirmed in writing.

Required due diligence:

• export rights
• deletion behavior
• tenant isolation
• model-provider data exposure
• anonymization controls
• retention controls
• auditability
• pricing and limits

The conversation strongly validated the expert marketplace and "rent knowledge" direction.

Relevant patterns:

• digital expert/persona as isolated memory scope
• vertical expert corpus
• retired experts contributing tacit knowledge
• voice/video capture for trades and tacit domain knowledge
• payment by quality, not only by time
• expert judges validating knowledge quality
• marketplace trust through provenance and usage audit

Backboard can potentially provide the memory/RAG substrate. RedKey/Hedera can provide provenance, usage tracking, attribution, and compensation.

RedKey currently uses provider APIs too directly.

Examples:

• direct OpenAI calls
• direct Anthropic calls
• direct Gemini calls
• direct provider-specific scripts
• Supabase agent_memory direct embedding/retrieval
• Codex/Claude/Gemini sessions with separate state assumptions

This creates several problems:

• no consistent task-based model routing
• no central cost policy
• no easy model fallback
• no systematic model benchmarking
• repeated context packing logic
• provider-specific drift across scripts
• hard-to-control memory writes
• weak model arbitrage

The issue is not that direct provider keys are bad. The issue is that they should be escape hatches, not the default integration pattern.

``text RedKey task or agent -> RedKey model gateway -> memory/context policy -> Backboard for stateful memory-aware calls -> OpenRouter for model routing -> direct provider API only for special cases -> Supabase for registry, task state, audit metadata -> Hedera for externalized proof, usage, provenance, and compensation events ``