about

Howell: a calm, durable cognitive layer for real work.

It is not a flashy chatbot. It is a thoughtful local-first runtime — a system of daemon, cortex, cluster/writeback, and persist-root memory that carries continuity, receipts, health, and project insight across sessions.

What Howell is

Howell is not a single chatbot. It is a layered local system for persistent memory and identity, grounded reasoning and verification, task continuity across sessions, safe writeback into project files, and clear operational health and receipts.

Its practical goal is durable cognition: the system should still make sense after a restart, after a long pause, and after a new instance boots. In other words, Howell is meant to preserve the thread of work with care, clarity, and continuity rather than simply generating a clever response in one moment.

The real runtime is a three-service stack: a daemon on port 7777 for continuity and local control, a cortex on port 7778 for reasoning and verdicts, and a cluster/writeback surface on port 7788 for constrained file updates. The persist root is the durable memory substrate that carries live state, logs, receipts, and knowledge artifacts across time.

It is best understood as a durable thinking environment, not a generic chat app.

How it works

At startup, start.sh resolves the persist root, exports local config paths, and launches the three services in order. Once the stack is up, status.sh is the health summary that tells you whether the runtime is coherent and alive. The actual work path is simple: the daemon owns continuity and queue state, the cortex adds grounded reasoning and verdicts, and the cluster/writeback path applies safe updates into the project environment.

There are three operating paths to keep distinct: the private local runtime, the public worker shell at howell.help, and the CF tunnel surface at brain.rlv.lol. The public pages are interfaces; the real continuities live in the daemon, cortex, cluster, and persist root.

  • Daemon (7777) is the local control plane. It owns sessions, identity state, queue and task operations, notes and memory writes, search and status endpoints, and the bridge/MCP-facing behavior that makes the system feel continuous across time.
  • Cortex (7778) is the reasoning layer. It owns model prompts, verification, verdicts, dream logic, research, and health/readiness judgments. This is the layer that tries to make the system think in a grounded way rather than merely generate text.
  • Cluster / writeback (7788) is the constrained write gate. It owns authenticated write access to approved project files, rate limiting, backups, and the safer bridge between the local runtime and project artifacts.
  • Persist root is the real memory substrate. Code files define behavior; the persist directory holds live memory, receipts, logs, KG data, and operational history that survive across sessions.
  • Public surfaces include howell.help (worker-backed shell for chat/status/freshness/cockpit-lite) and brain.rlv.lol (CF Tunnel into the daemon with an allowlist and key gate). These are windows onto the system, not the whole system itself.

What it can be used for

  • Project briefs, operational summaries, and health reviews that need durable context instead of one-shot answers.
  • Research loops, contradiction checks, and grounded follow-up where the system should explain what it verified.
  • Reflective work, runbooks, and continuity for long-running projects that need memory across restarts and pauses.
  • Safe writeback into a project environment with receipts, health signals, and constrained write paths instead of blind automation.

What it feels like

It feels calm, procedural, and evidence-aware. It is useful when you want a system that can remember, confirm, and surface what matters without turning every interaction into noise. It behaves more like a careful operator and notebook than a polished consumer product.

How the whole system fits together

Howell is not only the help page. It is the full stack behind it: the daemon for continuity, the cortex for reasoning and verification, the cluster/writeback path for safe project updates, the persist root for memory and receipts, and the public surfaces that expose status, heartbeat, and operational health.

In practice, the public worker shell answers status and chat requests, the local runtime does the real thinking and memory work, and the tunnel surface exposes a narrow path into that runtime when a live operator needs it. This separation matters because the public shell is only the visible edge, not the whole system.

The diagrams are meant to make the whole operating system legible, not just the chat shell.

System view

flowchart LR U[User / project context] --> D[Daemon :7777] D --> C[Cortex :7778] D --> W[Writeback / cluster] C --> P[(Persist root / KG / receipts)] W --> P D --> H[Heartbeat + health probes] H --> S[howell.help status + cockpit-lite] S --> R[Operator view / runbooks / summaries] C --> R

This is the simple operational map: the daemon keeps continuity, the cortex adds reasoning, the cluster path protects writes, and the persist root carries the durable state that makes the whole stack coherent across restarts and long pauses.

Runtime map and dependency stack

The current core runtime path is a three-service stack: daemon on port 7777, cortex on port 7778, and cluster/writeback on port 7788. The launcher is start.sh, which resolves the persist root, exports local config paths, and starts the services in the right order. status.sh then reports the health shape that tells you whether the stack is coherently alive.

The root plan organizes the project as layers rather than isolated files:

This model is important because lower layers must remain healthy before higher layers can be trusted. If the daemon or persist root is unstable, the public surfaces will inherit the instability even when the interface itself still appears available.

Use this when…

  • You want continuity across sessions instead of one-shot answers.
  • You need an operational view of health, queue, or writeback state.
  • You want a system that can distinguish grounded findings from vague speculation.

Do not expect…

  • Fast, disposable chat only.
  • Magic without receipts or evidence paths.
  • A single giant interface that hides the runtime.