Building Dubnium: An Agentic Orchestrator

This is the second post in the Dubnium series, about my NixOS-based local AI workstation. The first post described the host itself: profiles, runtime modes, model serving, service boundaries, and rebuildability: Building Dubnium: A Super Workstation With Modes.

This post moves one layer higher.

Running a local language model is straightforward compared with deciding which model should receive a task, what memory it may see, which tools it may propose, what effects it may cause, and how the result can be explained afterward.

That surrounding system is the agentic control plane.

The goal is not one all-powerful autonomous agent. It is controlled delegation: models may reason and propose, while deterministic components retain authority.

A model server is not an agentic system

A basic local stack looks like this:

client -> model server -> model

That is enough for chat, coding assistance, and an OpenAI-compatible endpoint. It stops being enough when the system needs:

persistent and scoped memory
specialist models
tool use
scheduled or event-driven work
approval boundaries
resource-aware routing
lifecycle state and evidence
recovery from partial failure

At that point, the model runtime is one component rather than the system itself.

request
  -> normalize
  -> plan
  -> govern
  -> execute bounded capabilities
  -> evaluate
  -> act
  -> audit and learn

Most of the difficult problems are around the model, not inside it.

The component model

Dubnium now uses explicit names because terms such as supervisor, gateway, and orchestrator otherwise collapse several different responsibilities.

flowchart TD C[Clients\nCLI, editor, n8n, scheduler] G[Supervisor Gateway\nOpenAI-compatible API] O[Supervisor Orchestrator\nrun lifecycle and context] P[Policy Engine\ndeterministic disposition] M[Memory Context Service\nbounded context packs] R[Specialist Router\nsemantic routing and preflight] S[Specialist Runtime Service\ncatalog and lifecycle] SR[Specialist Runtime\nbounded model server] T[Tool Execution Gateway\napproved effects] L[Run Ledger\nlifecycle and audit state] RT[Supervisor Runtime\nllama-server] A[Supervisor Agent\nlogical model role] C --> G --> O O --> P O --> M O --> R --> S --> SR O --> T O --> L O --> RT --> A

The distinctions are structural, not cosmetic.

Supervisor Gateway

The Supervisor Gateway is the external transport boundary. It is intended to provide the stable OpenAI-compatible API that clients target.

It owns concerns such as:

request handling and streaming
caller identity and request IDs
actor, workspace, session, and memory-mode validation
error translation and rate limiting
controlled remote exposure

The target client-facing model alias is supervisor. The raw model runtime keeps the alias local as a debug and bypass path.

Supervisor Orchestrator

The Supervisor Orchestrator governs an individual run behind the gateway. It owns:

lifecycle progression
context assembly and token budgeting
policy invocation
specialist delegation and synthesis
tool-intent mediation
run-ledger records
governed memory-write proposals

The gateway exposes the API. The orchestrator governs the run.

The orchestrator does not need to be a separate daemon. The first implementation is intentionally consolidated as reusable in-process logic so HTTP clients, scheduled jobs, and n8n workflows can eventually use the same contract.

Supervisor Runtime and Supervisor Agent

The Supervisor Runtime is the long-running inference process. Today that is the existing llama-server.service on 127.0.0.1:8000.

The Supervisor Agent is a logical role executed by that runtime. It may:

interpret requests
propose plans
propose delegation
evaluate specialist output
synthesize a response

It has no direct authority over memory, tools, policy, or process lifecycle.

runtime = process
agent   = role

Keeping those concepts separate means the model can change without redefining the authority model.

Models propose; policy disposes

The core rule is deliberately simple:

indeterminate models may propose
determinate policy disposes

The supervisor and specialists may propose plans, memory access, tool intents, and actions. The Policy Engine decides whether each proposal is:

allowed
denied
constrained
approval-gated
redacted
record-only

Workflow-specific rules may narrow central policy, but must not weaken it.

This prevents prompt text from becoming the security boundary.

Specialists receive work, not authority

Specialists are useful when a task benefits from a materially different model, context size, prompt contract, or isolated runtime.

Examples include:

long-context document analysis
code or security review
structured extraction
low-latency classification
independent evaluation

But specialists should not become autonomous peers with ambient access.

The intended boundary is:

Supervisor Orchestrator
  -> Specialist Router
      -> Specialist Runtime Service
          -> Specialist Runtime

The Specialist Router performs deterministic semantic routing and preflight. The Specialist Runtime Service owns the stable lifecycle contract:

catalog + acquire/run + release/stop + status

A specialist receives a bounded task and approved context. It does not call memory, tools, or other specialists directly.

The service contract accepts logical specialist kinds. It must not accept model-provided executable paths, shell fragments, arbitrary ports, credentials, or model paths.

The first implementation may invoke specialists inside the same runtime or through bounded external calls. Separate services are an optimization for isolation and lifecycle control, not a prerequisite for the architecture.

Artifacts, profiles, and roles

A model name does not describe how it should run.

The same weights behave differently depending on:

quantization
context size
KV-cache format
batch and micro-batch size
GPU allocation
concurrency
prompt contract
timeout and resource limits

Dubnium therefore distinguishes:

model artifact
    !=
runtime profile
    !=
agent role

For example:

qwen3-14b-q4-default
- artifact: Qwen3 14B Q4_K_M
- context: 24,576
- GPU: primary AI GPU
- parallelism: 1
- KV cache: q8_0

A runtime profile describes execution. A role describes participation in a run. The same profile might serve a supervisor role today and a bounded specialist role later.

Memory is a classified lifecycle subsystem

Persistent memory is not a larger prompt and it is not the workflow database.

Dubnium distinguishes three layers:

Layer	Question	Examples
Operational memory	What am I doing?	active context, plans, tool output, checkpoints
Knowledge memory	What do I know?	reviewed facts, decisions, preferences, lessons
Canonical knowledge	What is project truth?	versioned docs, ADRs, runbooks, specs

Canonical knowledge outranks memory records. Workflow state remains owned by the scheduler, n8n, task runtime, or Run Ledger until selected outputs are promoted.

The memory service already provides bounded retrieval contracts. Current filters include scope, sensitivity, TTL, rejection status, and verification requirements. The important output is a source-attributed context pack, not unrestricted access to the store.

flowchart LR O[Supervisor Orchestrator] P[Policy decision] M[Memory Context Service] C[Bounded context pack] R[Supervisor Runtime] O --> P --> M --> C --> R

The control plane declares purpose and scope. Governance evaluates access. The memory service mechanically filters and records retrieval. The orchestrator assembles the final prompt.

Memory is useful evidence. It is not authority.

Tool use has one execution boundary

A model proposing a repository change does not imply permission to modify the repository.

The Tool Execution Gateway is the only component allowed to perform approved external effects. It owns:

capability enforcement
argument constraints
credential injection
MCP and tool invocation
mutation execution
effect-result records

specialist or supervisor proposes tool intent
  -> Policy Engine disposes
      -> Tool Execution Gateway performs or denies
          -> result returns for evaluation

This gives tool use one auditable chokepoint and keeps secrets out of prompts and specialist runtimes.

The Run Ledger is not memory

Agentic execution needs a canonical record of what happened.

The Run Ledger records lifecycle events keyed by run_id, including:

stage transitions
policy dispositions
specialist handoffs
tool requests and results
approvals
externally visible effects
failures and evidence

The first backend can be ephemeral. An append-only event log is the next useful step when resumability and replay become necessary.

Selected outcomes may later be projected into knowledge memory, but memory is not the primary execution-state store.

Resource policy remains outside the model

Dubnium is still a workstation with finite hardware. Its active mode establishes resource policy.

desktop
- preserve interactive responsiveness
- keep local inference bounded
- limit specialist concurrency

compute
- make both GPUs available
- allow larger or parallel workloads
- prioritize throughput

studio-local
- prioritize interactive and audio latency
- constrain background AI work

The orchestrator may choose among allowed profiles, defer work, or reject a request. It must not override the host mode because a model considers its task important.

Capability requests should describe intent rather than hard-code a model:

capability: code-review
minimum-context: 32768
latency-class: background
memory-scope: repository
required-tools: [git-read]

Routing can then evolve without changing every client.

What exists today

The architecture is not a claim that every component is already deployed.

Dubnium already has:

the raw Supervisor Runtime through llama-server.service
named local model profiles
GPU-aware runtime modes
the memory API and context-pack contract
scoped memory filtering and retrieval records
systemd-managed services and localhost-first network policy
Headroom as an optional context compressor
Plano as an optional model-routing facade
accepted component terminology and lifecycle specifications

The next implementation layers are:

supervisor-gateway.service on 127.0.0.1:8080
the in-process Supervisor Orchestrator
central Policy Engine integration
specialist routing and runtime lifecycle
the Tool Execution Gateway
an ephemeral Run Ledger followed by a durable event log
governed memory writes and learning projections

The target shape is service-oriented, but v1 should remain operationally small: one gateway process, internal control-plane modules, the existing inference and memory services, and bounded adapters where separation is justified.

Where Anthesis fits

Dubnium is the execution environment. Anthesis is one possible governance system for deterministic policy, approvals, evidence, provenance, and memory envelopes.

Dubnium: where agentic work runs
Anthesis: under what authority it runs

Dubnium must not require Anthesis specifically. The boundaries should support other policy engines. But Anthesis is the place where I am exploring the deeper question: how can autonomous systems remain attributable, least-privileged, auditable, and resistant to bypass?

The larger lesson

The interesting part of local AI is no longer whether a model can run on the available hardware.

The interesting part is whether the surrounding system remains understandable as delegation increases.

That requires:

explicit component ownership
deterministic policy
scoped memory
bounded specialists
one effectful execution gateway
durable evidence
resource-aware operation
a recovery model

The objective is not maximum autonomy.

It is controlled delegation.

The next post, Building Dubnium: Scheduling Agentic Work, looks at how Dubnium schedules agentic work without turning its small, auditable timer substrate into a hidden workflow engine.