mjdeving

What I have built with AI

A working catalog of the systems, harnesses, and methods I run.

What agentic engineering takes

Running agents dependably, and more than one at a time, takes five capabilities.

01

Getting agents to understand you

Agents do what you say, not what you mean.

02

Knowing if the output is good

You can't improve what you can't measure.

05

Scaling throughput

One agent at a time is the bottleneck.

  • Multi-Agent Orchestration
  • Parallel Execution
  • Remote Sandboxing

How the work gets done

I split the work into claims with explicit dependencies. The system takes one unblocked claim at a time, builds it, tests it, reviews it, and records the result.

Human steeringOptional, and normally idle. A person sets the definition of done and steps in only to re-steer; the correction lands in the spec of record or Beads.

the work: a graph of claims the loop walks one ready slice Spec of record claims and their dependencies Beads ready/blocked, work order optional verified ready frontier ready ready blocked take a ready slice Build one slice Tests + probes evidence per claim Autoreview fresh reviewer, reruns Checkpoint commit + reconcile reconcile reopen: a gap reopens a claim, progress may fall

AutoreviewAfter each change, a fresh model reviews the current diff against the written requirements. I verify each finding, fix accepted problems, and repeat until one full review finds nothing actionable.

ProvenanceEvery closed claim and every checkpoint leaves an evidence record. The trail is append-only and auditable.

It is a graph because slices depend on each other. Where they do not, they can run at the same time. The loop is not a node in it: it walks the graph from outside and only ever enters at the frontier.

The sections below show the files, tools, checks, and runtimes that implement those five capabilities.

The whole thing, one map

How the parts sit together, and where the real cut runs: what the system knows, and what makes it behave.

knowing The AI-OS
Who I am, what the business is, what the goals are, what was decided, and a file at each folder saying what that branch is for. Swap that context and it is another business's system.
behaving The agentic system
The harness turns a request into written checks, chooses the model and skill for each task, verifies each completed step, and gives independent tasks to separate agents. Skills hold the repeatable instructions and scripts. Automations and agents are the systems built from them.
The AI-OS files and folders context lives here The harness holds the model to the method Skills what it can do Automations the build method Agents decides its own path Projects what gets shipped

Every box opens that part of the work. Green dot marks the AI-OS, solid arrows are the build path, left to right. The path forks after Skills: most work is a workflow with a fixed order, the agent is the exception you escalate to. Both land in Projects.

structure

Context about me and business

Who I am, the business, and the current goals, in dated plain files. Every other layer reads from here; an assistant without this layer starts every session from zero.

structure

Connections registry

One registry of every system the OS can reach: revenue, calendar, mail, tasks, files, any API or local data. What is not listed here, the OS treats as unreachable.

structure

Knowledge and references

The reference store the OS draws from: doctrine, repeatable playbooks, research digests, each pinned to its source. An answer traces back to a document I can open.

structure

Decision log

Append-only log of what was decided and why. Entries are never edited, only superseded, so the record cannot be rewritten to agree with the present.

structure

One folder per initiative

Each initiative is a self-contained folder with its own docs, references, and scope. Any session can pick it up cold, because everything the work needs is inside.

architecture

Every folder has a job

Routing lives in the tree. A file at each level says what that branch is for, so the file tree is the program and the agent is the interpreter.

the loop

Definition of done

One file per piece of work. It holds the problem, done as numbered checks, every decision, and the evidence for each check. It is the spec of record, and it outlives the session that wrote it.

the loop

The work loop

Before an agent runs, done gets written down as checks a tool call can answer. The loop takes one ready slice, builds it, tests it, reviews it, then records the outcome where it belongs, and repeats until every check has passed with the output that proves it.

the loop

Graph Climbing

The work is a graph of claims with explicit dependencies, and the loop walks only the ready frontier, the claims whose dependencies are already met. The graph shows which claims could run at the same time. What actually runs in parallel is whatever can be kept apart, in files and in everything else it touches, and where keeping them apart costs more than going in order, it goes in order. A claim stays a candidate until its evidence is reconciled; a gap found later can reopen a claim and lower the verified count.

inspect
execution

Composable skills

Each repeatable task has its own folder with a description, instructions, and scripts. The model chooses a folder from its description and loads it only when the current request matches.

execution

Parallel agents

Independent work fans out to specialist agents (research, build, cross-vendor audit), each in its own clean context, and merges back in one place.

execution

Actions, pipelines, flows

An action does one thing, a pipeline chains actions, and a flow puts a source, a pipeline and a destination on a schedule. Each level deploys on its own.

execution

Code before prompts

Every capability is a deterministic CLI tool first, wrapped by a prompt second. The tool is the part that gets tested.

enforcement

Lifecycle hooks

Deterministic scripts that fire on session events: start, tool call, stop. They run whether or not I remember to ask.

enforcement

Trust boundary

Everything external is data to read, never commands to obey. Commands come only from me and the core config, so a hostile page or tool output cannot steer an agent.

enforcement

Deterministic guardrails

Forty commands are blocked before a model is consulted, and forty-five more stop and ask me first. A secret in a file being written is refused at the write.

enforcement

Privacy-aware routing

Every piece of data has one of four sensitivity levels. Each model provider has a maximum level it may receive. Code compares the two and blocks the call when the data is too sensitive for that provider.

state

Compounding memory

What each session taught is extracted, filed by how long it stays true, and retrieved by relevance. It proposes edits to its own rules and waits for my yes.

state

Capture substrate

One command captures anything (a note, a link, a clip) and queries across every store. Each capture lands as a raw, timestamped envelope and is processed into knowledge on demand.

state

Typed extraction

Parses a source, extracts the fields, and emits schema-valid JSON plus a deduplicated entity graph. What does not fit the schema is rejected before it can land.

state

Relevance filter

Every incoming item is scored one to a hundred. Scoring is live. The routing rules remain disabled until their proposed actions have been reviewed against real items.

state

Agent working ledger

A git-native issue ledger. Agents claim work, declare dependencies, close, and sync across sessions against one shared source of truth.

surface

Event stream

Every tool call, agent, and failure emits an append-only event, read by both the dashboard and the ledger.

surface

The live dashboard

One always-on local dashboard puts voice, chat, observability, and live status in one place. Work the OS does off-screen is visible there.

thinking

Science

State the goal, force at least three competing hypotheses, design an experiment that can fail, then measure.

thinking

FirstPrinciples

Deconstruct to parts, classify each as hard constraint, soft constraint, or unvalidated assumption, then rebuild from the fundamentals.

thinking

SystemsThinking

Groups repeated incidents, identifies the process that keeps producing them, and chooses a change to that process instead of fixing each incident separately.

debug

RootCauseAnalysis

Reconstructs the timeline, asks why each failure was possible, and changes the system that allowed the mistake instead of blaming the person who made it.

thinking

IterativeDepth

Two to eight passes through the same problem, each from a different lens, stopping when the passes stop yielding.

context

ContextEngineering

A five-level hierarchy decides what gets loaded, and starvation and flooding are diagnosed as two separate failures.

prompt

Prompting

A standard library of prompts that write prompts. Structure is code in a Handlebars template, content is data passed in at render time.

eval

Evals

Evals grade the transcript, the tool calls and the turns. Each case runs at least three times: can it do this at all, and does it do it every time.

testing

Hardening

Generated inputs run against a stated invariant, and a failure is shrunk to the smallest input that still breaks it.

review

autoreview

A fresh model reviews the current diff before commit. I verify and fix accepted findings, then repeat until a full review returns no actionable finding.

adversarial

RedTeam

The argument breaks into twenty-four atomic claims, and thirty-two agents work them over from four expert angles. Findings come back severity-ranked.

debate

Council

Four to six composed experts debate in rounds, each seat carrying its own stake, and the whole transcript is kept.

agents

Delegation

Six patterns for splitting work across agents, from one-shot subagents to worktree isolation to multi-turn teams.

research

Research

Four depth modes, from one quick lookup to seven parallel explorers, with independent verifier agents that re-check the claims before anything ships.

tuning

Optimize

An autonomous loop changes the target, measures, keeps what wins and reverts what does not, until it stops climbing.

audit

BitterPillEngineering

Every rule in an instruction set meets one test, would a smarter model still need it, and is then cut, merged, sharpened or kept.

meta

CreateSkill

A new skill runs against a no-skill baseline, same prompt, two agents, and the comparison decides whether it changed anything.

doctrine

Delete before you automate

Most processes exist because they always have. A report nobody reads. An approval that changes nothing. Ask what breaks if it simply stops, and if nothing breaks, kill it.

method

Map the process on paper before you pick a tool

Before any tool is open, the map answers three questions: where AI actually belongs, whether each step is a fixed workflow or a judging agent, and what data it touches. Catch the broken step on paper, where it is cheap.

concept: Workflow
method

Take the lowest autonomy that works

Autonomy has rungs. Human does it. Model suggests, human picks. Model drafts, human edits. Model runs, human checks. Model runs alone. Take the lowest rung that clears the bar.

concept: Autonomy Ladder
doctrine

If it moves no number, do not build it

An automation earns its keep on one specific number, named before the build starts and measured after it runs.

framework

The WAT framework

Every automation is the same three layers: a markdown workflow that fixes the steps, an agent that reads it and coordinates, and single-purpose tools that do the work.

concept: Workflow
concept

The step types

Under the three roles, an automation is a trigger and a chain of steps, each of a few kinds: fetch or reshape data, call a tool to act, ask a model to read or classify, branch on a decision. Canvas or code, the kinds are the same.

concept: Workflow vs Agent
philosophy

Workflows as files

The workflow is markdown the agent reads and follows. The code underneath is the tools it calls. A capability written as files can be read in a diff and corrected by editing a paragraph.

concept: Workflow
concept

Tool definition

A tool is one function with one job: a name, a schema for its arguments, and a description the model reads as its contract. The arguments are validated before it runs.

concept: Tool Calling
concept

The two senses of "agent"

Agent means two things. At build time it is the assistant that writes the automation. At runtime it is a model choosing what to call as it runs. Most automations need only the first.

concept: Agent Loop
doctrine

Control flow

If the complete process can be drawn before execution, build a workflow with that fixed order. Code chooses the next step; a model may classify or extract data inside one step.

concept: Workflow vs Agent
method

Goal, not steps

When the order cannot be fixed in advance, an agent loops toward a target. It gets the goal and a success test, not the steps. Step-by-step instructions turn it into a slow typist.

concept: Loop Freedom
method

Build-time self-healing

During development, each failed run leads to a tool fix, a workflow update, and another test. Deployment starts only after repeated runs reveal no new failure class.

concept: Evals
framework

The deploy seam

The build-time agent froze the steps and hardened the tools. Deploy locks that in: the workflow and the tools go to the runtime, and the coordinating agent stays behind.

concept: Workflow
doctrine

Reliable, not deterministic

The flow is full of model calls, but you fixed their order, so it is a workflow, not an agent. The order is deterministic; the steps stay probabilistic, and evals prove the variance is low.

concept: Workflow vs Agent
architecture

Accuracy compounds

Chain model calls and the error multiplies down the chain: five steps at ninety percent each land at fifty-nine. The fix is to let the model decide and let code do the steps.

concept: Compounding Error
architecture

Small blocks

Decompose the job into steps small enough to stand alone, one input and one output each. Build the deterministic ones first, fetch, format, route, and give each model call a single job.

concept: Task Decomposition
method

Validate each step

Build step one, run it on real data, and read the output it actually produced. Build step two against that, not against the output you imagined it would return.

concept: Evals
architecture

The runtime layer

A framework and a durable runtime get compared as rivals, but they sit at different layers. The framework runs the model-and-tool loop. The runtime underneath survives the crash and the long wait.

concept: Workflow vs Agent
runtime

Durable execution

A runtime snapshots a job where it waits, and nowhere else. So durability is really decomposition: split the job at its waits, and a retry skips whatever already ran.

concept: Durable Execution
runtime

What the runtime buys

Two things a local run cannot give you. A crash resumes instead of losing the run. And the job can pause for hours or days at a human decision, then resume when the answer arrives.

concept: Durable Execution
doctrine

Phased rollout

Run it by hand and watch, then let it draft while a human sends, then let it send while a human samples. Start at a tenth of the volume.

concept: Human in the Loop
security

Least privilege

Treat it like someone who started this morning. Its own identity, never yours. Read access until write access is justified. Keys scoped to exactly the job.

concept: Guardrails
security

Prompt injection

External content is read by the model as instruction, not just data. A tool description, a fetched page, a config file: anything the model reads can carry an instruction it was never meant to obey.

concept: Prompt Injection
doctrine

Two kinds of audit

A person needs to see what happened. A machine needs to prove it. The two are built differently, and a requirement names one of them.

concept: Observability
runtime

Always-on execution plane

An automation is a background job: a trigger fires it, it runs unattended, it reaches the services it acts on. The runtime that holds it has to be always on.

concept: Workflow
taxonomy

Code or canvas

Start at the lowest ownership level that fits: bundled canvas, own database, own frontend, own API, or full deploy stack. Every step is optional. The future maintainer, testing, UX, scale, compliance, and operations decide where to stop.

concept: Workflow vs Agent
doctrine

When to tear it down

An automation that needs a patch every week is not an asset. Neither is one costing more attention than it returns.

concept: Observability
doctrine

When the order cannot be fixed

A workflow is the default: predictable, testable, cheap. An agent is earned only where the path through the task cannot be written down in advance and flexibility is worth its cost in latency and tokens.

concept: Workflow vs Agent
concept

The agent loop

An agent is a model directing its own process: it picks a tool, reads the real result, and decides the next step from what came back, looping toward the goal until a success test passes or a stop rule fires.

concept: Agent Loop
taxonomy

The pattern ladder

Between one augmented model call and a free-running agent sits a ladder of fixed patterns: chain the calls, route by kind, run parts in parallel, let one model dispatch to workers, loop a generator against a judge. Take the lowest rung that solves it.

concept: Workflow vs Agent
architecture

Sub-agents

One coordinating model splits work it cannot enumerate in advance and hands each piece to a worker running in its own clean context. The pieces come back to one place; the contexts never mix.

concept: Sub-agent
doctrine

The cost of autonomy

An agent trades latency, tokens, and compounding error for its flexibility. So it runs bounded: sandboxed first, tool results as ground truth, a pause at a human checkpoint, and a hard cap on iterations.

concept: Guardrails
taxonomy

The anatomy of an agent

Every agent is the same three parts: instructions the model follows, the model itself, and the tools it may call. A name, a persona, an employee framing: packaging around the same anatomy. Frameworks differ in what they hand you, not in what an agent is.

concept: Agent Anatomy
architecture

Two ways to wire one

One option is a definition file containing instructions and allowed tools; an existing host runs the model-tool loop. The other is application code built on a framework; my program runs the loop and controls its state, deployment, and results.

concept: Agent Wiring
doctrine

What autonomy needs

An agent runs unattended only when its host starts it on an event, stays available between runs, provides separate credentials, and enforces limits on tools, cost, iterations, and live actions.

concept: Durable Execution
taxonomy

What keeps it alive

A session runs while its terminal stays open. A gateway keeps the agent reachable through chat or webhooks and can wake it on a schedule. A job runtime starts one bounded run per event, saves progress while it waits, and ends afterward.

concept: Agent Hosts
protocol

MCP, the open connector

MCP is how an agent reaches the outside world through one shared protocol. A server declares its tools once, and any AI app can call them over JSON-RPC, so a tool is not locked to the coordinator that built it.

concept: Tool Calling
instance

Speed to lead

Inbound-lead rapid response, the largest automation here by code. Built and tested against my own intake; it has not yet run against live lead volume.

instance

Research workflow

A research pipeline that decomposes a question, runs bounded searches, evaluates sources, and synthesizes.

instance

Inbox manager

Inbox triage that classifies, drafts, and files, surfacing only what needs a human decision.

instance

Inquiry agent

An inbound-inquiry agent that reasons and iterates inside a durable task. Synthetic and offline: it drafts, and nothing is sent. The logged exception to the no-runtime-agent default.

instance

Quote generator

Drafts a structured offer from the intake, ready for review.

project

audit-grade-rag

A self-hosted question-answering system over a fixed document collection. It rejects answers without supporting passages, verifies each citation against retrieved text, and records the inputs and model version so later runs can expose changes.

inspect
project

industrial-doc-rag

RAG over 497 near-identical MOSFET datasheets, graded on 2,718 questions. Dense retrieval alone finds the right one about two times in three. Fusing in the part number fixes it.

inspect
project

dacs-spec-mcp

A read-only MCP server that lets an agent query an agent-commerce standard by section. It serves a committed index built at a pinned commit, hash-locked so it cannot drift.

inspect
project

managed-agents-research

Five agent patterns on the Claude Agent SDK, from one one-shot agent up to an orchestrator with parallel sub-agents and a plan-execute-reflect flow that splits roles by model cost.

inspect
project

n8n-nodes-utcp-codemode

A published n8n community node that swaps many per-tool model calls for one. Where the agent node grows calls quadratically as the pipeline lengthens, code-mode stays at a single execution.

inspect
project

dokument-extraktor

Messy documents to schema-validated JSON: OCR, model extraction, and a labelled golden corpus to score accuracy against, each number naming its provider and model. The corpus runs the real extraction path, so the score is measured, not asserted.

project

openclaw-hardened

A six-layer prompt-injection defense for a self-hosted AI agent, run as a native plugin across five gateway hooks. The runtime is external and the config auditor is a third-party plugin; my contribution is the hardening.

inspect
project

storj-sno-cluster

An implementation-architecture reference for a Storj storage-node cluster: topology, monitoring, hardening, and an operations runbook. The architecture is the deliverable, with no earnings or runtime claims.

inspect
project

operator-references

Three infrastructure references for solo operators in Germany: storage, compute, and validation. I selected activities where the operator does not hold or manage another person's funds, because custodial work may require financial licensing.

inspect
project

soc-alert-triage

A SIEM alert enters, a scored and MITRE-mapped triage decision comes out. Every threat-intel lookup fires in parallel inside one sandboxed call, so the model reads the result once.

inspect
project

dacs-verify

An independent verifier for an agent-commerce standard. It rebuilds each specified result byte for byte and reports mismatches with the relevant section of the standard. It is read-only and holds no wallet or keys.

inspect
project

voice-agent

A German phone agent for medical practices: booking against a real availability API, emergency detection, call transfer, holiday-aware greetings. 156 tests. It has never run against a live practice.

inspect
project

invoice-parse-agent

Invoice PDFs into structured JSON: text extraction, schema-constrained model output, a low-confidence review queue, and accuracy reported against a small ground-truth corpus rather than asserted.

inspect
project

code-mode-tools

An MCP server that hands any client a sandbox: the model writes TypeScript that chains tool calls, runs once, and returns. Published to npm, forty-four tests.

inspect
project

omniweb-agents

Agents that can read blockchain state but cannot publish a transaction without explicit permission for that action. When an authorized action runs, the system records the request, decision, transaction, and result.

inspect
project

my-dai-cloud-solution

Claude Code as an always-on agent I reach from my own phone: a bridge to the CLI, persistent memory, guardrails, and an agent-to-agent pipeline. 460 tests.

inspect
project

demos-fixnet-operator-kit

The operator layer around an upstream node runtime I did not write: setup, preflight, verification, burn-in, recovery, and a harness that detects a dirty host. No tenant data, no live fleet data.

inspect
project

code-first-n8n

Five POC workflows proving the n8n lifecycle can run without clicking, authored from the terminal. A measured run collapses eleven model calls into one, five times faster.

inspect