Back to projects

Workflow Automation

Harness Maximus

A registry-driven worker harness that turns wiki-guided context, commands, scheduled jobs, and queue tasks into visible local AI workflows.

Type: registry-driven worker harness Status: active Core loop: run.py -> resources -> WorkerManager -> workers -> queue

Why the first version changed

The project outgrew the single-workflow framing.

The early version was useful because it proved that local capture and processing could work. The current version is broader: tasks enter through commands or schedules, persist in a queue, and route to workers discovered from a registry.

The current architecture

The conductor stays thin while workers carry the workflows.

`run.py` creates shared resources, starts the `WorkerManager`, and then gets out of the way. The manager reads `.harness/registry/sub-agents/*.json`, starts essential workers, and wakes on-demand workers by task type.

Architecture Walkthrough

How work moves through Harness Maximus.

Pick a flow to see which components are active. The board shows the system as a set of explicit paths instead of one script trying to own every workflow.

Conductor

Shared Resources

Worker Manager

Essential Workers

On-Demand Workers

External Systems

How work enters the system

Discord, schedules, and queue tasks are the front doors.

`BotWorker` handles command intake for URL, YouTube, GitHub, wiki, benchmark, and coding work. `SchedulerWorker` adds recurring jobs. Both paths persist work into `TaskQueue`.

How workers run

Essential workers stay up; on-demand workers wake by task type.

`BotWorker`, `QueueWorker`, and `SchedulerWorker` start on boot. Coding, digest, lint, benchmark, dashboard, PCR, improvement, and code-eval workers start when matching work appears, then stop after the idle grace window.

How models are selected

The queue assigns model weight before execution.

Heavy pipeline and improvement work routes to `gemma4:31b`. Medium coding and digest work routes to `qwen3-coder:30b`. Intake uses `claude-haiku-4-5` through `IntakeAgent`.

What this makes possible

The same harness can run wiki, coding, benchmark, and ops workflows.

The architecture is broad enough to run multiple workflow families, but still constrained by registry entries, task types, shared resources, and worker lifecycle rules. Wiki-derived topic bibles guide the harness work, then logs, failures, and operational learnings feed back into the wiki so the next version has better context.

Worker Registry

The active worker surface.

Essential

Bot, Queue, Scheduler

Start on boot and keep the interface, pipeline executor, and recurring job scheduler alive.

Wiki

Digest, Lint

Generate daily vault digests and clean wiki pages through scheduled or queued tasks.

Coding

Coding, Coding Benchmark

Run autonomous coding tasks and evaluate models against coding benchmarks.

Ops

Dashboard, PCR, Improvement

Refresh dashboards, collect operational data, and analyze failures for candidate improvements.

Benchmark

Benchmark

Runs ingestion and pipeline quality evaluations across model choices.