DeepClause “Turbo DML” Agent Harness - Substack von Andreas

Substack von Andreas

AbonnierenAnmelden

DeepClause “Turbo DML” Agent Harness

Andreas<br>Mai 20, 2026

Teilen

Up until a short while ago DeepClause mostly existed as a runtime.<br>You could compile Markdown specs into DML, run them, wire in tools, and get fairly capable little workers. Useful, but still a bit headless. The runtime was there, but the thing I actually wanted to sit in front of all day was not there yet.<br>At the center of that runtime is DML, a small Prolog-based language for describing agent behavior: model calls, tools, control flow, retries, delegation, child skills. I like doing this in a real language because the behavior does not disappear into prompt soup. You can inspect it, diff it, patch it, and rerun it.<br>On top of that runtime I have now built an agent harness.<br>The harness is made from a few core components that are themselves written in DML. The conductor owns the main session. The skill creator turns repeated work into reusable workers. The compactors handle long histories. There is also a recipe layer for plain markdown guidance when you want reusable instructions without compiling a worker.<br>To match the old-school Prolog feeling, the harness comes with what I can only describe as a Borland “Turbo DML” style UI: fullscreen terminal, menus, inline editors, live execution log, and very little ceremony.

If you want a quick feel for it in motion, here is a short video:

The Harness Logic Is DML

The part I care about is not really the UI. It is that the harness logic lives in files I can open:<br>.deepclause/system/<br>├── conductor.dml<br>├── CONDUCTOR_PROMPT.md<br>├── skill-creator.dml<br>├── DML_COMPILER_PROMPT.md<br>├── default-session-compactor.dml<br>└── default-loop-compactor.dml<br>That means the agent is not a black box with a thin settings layer on top. The router is editable. The worker factory is editable. The memory policy is editable.<br>If the conductor keeps answering inline when I want a reusable skill, I can change the routing logic in conductor.dml. If the skill creator keeps generating workers that are too broad, I can change the phases and guardrails in skill-creator.dml. If compaction keeps preserving the wrong details, I can change the actual skip predicates and compaction logic in the compactor .dml files.<br>Because we use DML, the harness is unusually hackable.<br>The interesting edits are usually not prompt edits. They are program edits: add or remove a tool predicate, split agent_main into more specialized clauses, change when a worker gets created, tighten a fallback, or replace an autonomous loop with a small explicit workflow. And you can also ignore the big agent loop entirely and use DML for smaller prompt chains or semi-deterministic workflows, which is especially nice for smaller or local models.<br>Simplified Conductor

The real conductor file is longer than this, but the shape is simple. It exposes a handful of tools, loads the system prompt, and asks the model to complete the task autonomously.<br>% simplified from conductor.dml

tool(run_skill(Slug, Args, Result), "Run an existing skill.") :-<br>exec(run_skill(slug: Slug, args: Args), Result).

tool(consult_recipes(Query, Result), "Read markdown workflow recipes.") :-<br>exec(consult_recipes(query: Query, max_results: 3), Result).

tool(create_new_skill(Spec, Result), "Create a reusable worker.") :-<br>exec(create_skill(spec: Spec), Result).

agent_main(UserMessage) :-<br>param(system_prompt, "Conductor system prompt", SysPrompt),<br>system(SysPrompt),<br>format(string(TaskPrompt),<br>"Task instructions: ~w\n\nComplete this task autonomously. Store the user-facing reply in FinalAnswer.",<br>[UserMessage]),<br>task(TaskPrompt, string(FinalAnswer)),<br>answer(FinalAnswer).<br>That is a pretty nice thing to be able to edit. If I want the conductor to prefer skill creation earlier, consult recipes before touching the web, expose fewer tools, or route repeated repo work into a dedicated worker path, I am changing a real program.<br>Simplified Skill Creator

The skill creator is the part that turns “this keeps happening” into “this is now a reusable worker.” Again, the real file has more details, but the basic structure is easy to understand.<br>% simplified from skill-creator.dml

agent_main(SpecMarkdown) :-<br>output("Starting skill creation..."),<br>task("Read the spec, research dependencies, and store the result in ResearchSummary.",<br>string(ResearchSummary)),<br>task("Set up the environment from {ResearchSummary}. Store the result in EnvSummary.",<br>string(EnvSummary)),<br>task("Write, validate, and test the DML skill. Store the final file path in FinalDML.",<br>string(FinalDML)),<br>task("Deploy the tested skill from {FinalDML}. Store the result in DeployResult.",<br>string(DeployResult)),<br>answer(DeployResult).<br>I like this split a lot. The conductor does not have to become a giant do-everything prompt. It can escalate repeated work to a separate worker factory.<br>And because that worker factory is also written in DML, I can change more...