Intake becomes queue state
Discord and scheduled triggers become durable task records.
System
The system matters more than the model call.
A model can answer a question, but repeated work needs more than that. It needs intake, durable context, routing, tools, review surfaces, and a way to reuse what was learned instead of starting over every time.
Harness Runtime
The harness is the operating system.
My current self built model handles intelligence tasks, then hands output back to the harness. The surrounding system owns intake, queueing, routing, workers, tools, notifications, traces, and reusable memory.
View the full model animation on desktop.
Intake
Discord Bot
/code /add-task /benchmark
Task Scheduler
recurring triggers
Durable queue
Task Queue
records, priority, model tier, status
Dispatch
Worker Manager
capability map + lifecycle
Always on
Queue Worker
durable executor
Scheduler Worker
keeps cadence
On demand
Coding
repo tasks
Wiki
knowledge upkeep
Ops
review surfaces
Benchmark
model quality
Short lease
Model
intelligence task only
Workers borrow intelligence, then pull the output back into the harness.
Output row
Tools
files, scripts, APIs
Notify
output + errors
Trace
model, duration, result
Memory
next-loop context
08 queued
03 running
01 leased
21 traced
14 memories
The manager routes the work
The harness picks always-on or on-demand workers and owns lifecycle.
Workers carry the run
Queue, scheduler, coding, wiki, ops, and benchmark workers do the operational work.
The model is a short lease
A worker borrows intelligence, receives output, and continues the run.
Outputs become system memory
Tools, notifications, traces, archives, and reusable context close the loop.
How it evolved
The early version was manual: copy sources, paste transcripts, organize notes by hand, and ask a model to process the material. It worked, but it depended too much on me being at the desk and remembering the next step.
The next phase turned repeated steps into operating surfaces: dashboards for review, wiki pipelines for reusable context, and workers for scheduled or queued tasks. The model stayed important, but the surrounding system became the real leverage.
The operating loop
Capture
Give raw material a front door
Sources, notes, commands, records, and recurring triggers need a reliable way into the system before any synthesis work matters.
Normalize
Create durable context
Loose material becomes snapshots, source pages, summaries, proposal files, and structured records that can survive beyond one chat session.
Orchestrate
Make the path inspectable
Queues, registries, schedules, and workers decide where a task goes so repeated work does not live inside private memory.
Notify
Make changes visible
Digests, alerts, dashboards, and status surfaces keep background work from disappearing into logs no one checks.
Reuse
Make outputs feed the next loop
Processed knowledge should feed dashboards, topic bibles, project checklists, coding tasks, benchmarks, and new automations.
Current subsystems
Market monitoring
Turns market context into calmer review surfaces for risk, confirmation, portfolio behavior, and next actions.
Research wiki pipeline
Moves source material through normalization, proposal/apply steps, topic bibles, maintenance, digests, and reusable workflow context.
Harness Maximus
Runs a registry-driven worker harness around commands, schedules, persistent queues, model routing, and on-demand workers.
Mission control layer
Explores how run history, failures, worker activity, daily notes, and Mac Studio health can become one operational overview.
System boundaries
This public site shows the structure and intent of the system, plus selected internals where they make the work concrete. It does not expose the full raw vault, private prompts, credentials, queue data, or internal source material.
The point is to show enough machinery to make the work legible without pretending that a private working environment should become public by default.