Skip to content
Small team, full backlog, zero orders dropped. Support replies are slower than we’d like. Read our status update → Zero orders dropped. Status → 📬 Check your spam folder — most of our replies land there. We do answer. Status update → 📬 Check your spam folder. Status →
1325 Rue Bergar, Laval, QC support@d-central.tech 1-855-753-9997 Mon-Fri: 8:30 - 18:00

Agentic Engineering — D-Central Technologies

Agentic Engineering: The Five Disciplines of Building Software With Agent Fleets

Prompt engineering was the first rung, not the whole ladder. Once an agent can act, observe the result and act again, and once you can run several of them at the same time, the job stops being about wording a request and starts being about designing a system. This is the reference stack we run every day: prompt, context, harness, loop and graph — plus the two loop patterns that do the actual grinding.

Start With Prompt Engineering See the Environment
5
Disciplines in the Stack
2
Named Loop Patterns
7
Full Reference Pages
0
Tools You Must Buy First

Why It Is a Stack and Not a Bag of Tips

These five layers sit on top of each other, and the order matters because a failure at a lower layer is invisible at a higher one. A brilliant orchestration graph built on a starved context produces confident nonsense in parallel, faster and at greater expense than one agent could manage alone.

The single most useful diagnostic skill in agentic development is telling these layers apart when something goes wrong. An agent that produces the wrong thing usually has a prompt problem. An agent that produces a plausible thing that contradicts the codebase usually has a context problem. An agent that produces the right thing and then cannot apply it usually has a harness problem. An agent that gets close and never lands usually has a loop problem — no real feedback signal to converge against. And a fleet that produces seven excellent pieces of work that do not fit together has a graph problem.

None of this requires our software. Every method on these pages runs on tools you already have — a terminal, a git repository and whichever coding agent you already pay for. We build DCENT_ADE because operating these patterns by hand across a fleet is tedious, not because the patterns need a product to work.

The Five Disciplines

1. Prompt Engineering

The instruction itself: objective, constraints, worked examples, acceptance criteria and output contracts that survive a forty-turn run rather than a single chat reply.

2. Context Engineering

What the agent knows: which files, which conventions, which decisions, which memory. Curating the window rather than dumping into it, and understanding what compaction destroys.

3. Harness Engineering

Which agent, which model, which tools, which files it owns, visible or headless, under what permission boundary and in what isolation. The harness is an engineering decision, not a default.

4. Loop Engineering

Turning single turns into act, observe, correct cycles. Designing the observation step so it returns real evidence, and knowing when the loop has converged or is just burning tokens.

5. Graph Engineering

Many agents as a dependency graph: fan-out, joins, conditional routing, retries, quality gates, claims, isolation and explicit exit conditions. Where a fleet becomes an organisation.

The Diagnostic

Find the lowest broken layer before fixing anything above it. Most agentic failures blamed on the model are context or loop failures wearing a convincing disguise.

The Reference Pages

Prompt Engineering

Writing instructions that hold up across many turns, tool calls, compaction and sub-agents. Acceptance criteria, output contracts, and treating prompts as versioned project assets instead of disposable chat messages.

Loop Engineering

The general theory of act, observe, correct. Termination conditions, oscillation detection, cost ceilings, and why a loop without a real measurement is just expensive repetition.

Context Engineering

Deciding what enters the window and what stays out. Repo maps, conventions, persistent memory, retrieval versus stuffing, context rot, and why a bigger window is not the same thing as better context.

RALPH Loops

The brute-force pattern: the same prompt in an infinite shell loop, fresh context every iteration, with the repository itself acting as memory. Not ours — credited to its author — and startlingly effective on well-defined work.

Harness Engineering

Choosing the agent, the model tier, the tool set, the permission boundary and the isolation strategy per job. Interactive PTY agents versus headless workers, and what each one costs you in attention.

Gauntlet Loops

Named by Matt Shumer and run here as standing build doctrine. A builder makes a real artifact, an independent critic with fresh context judges the artifact rather than the story about it, and the largest gap goes back for another round. The critic must be able to reject.

The top rung is graph engineering: tasks, agents, dependencies, branching, synchronisation, retries and gates, where you stop writing prompts and start designing the relationships between work.

Why a Bitcoin Mining Company Writes This

It is a fair question. D-Central are Bitcoin mining hackers. We repair ASICs, write firmware and build open hardware. We are not a developer-tools company and we are not pretending to be one.

We write this because we ran into it. Keeping an open-source firmware, an MCP harness that gives agents real hands inside KiCad, a hardware line and a large web estate moving at once meant operating agent fleets daily, in production, on work where being wrong has a cost. The patterns on these pages are what survived that. They were not designed at a whiteboard, they were what was left after the approaches that did not work got thrown away.

That is also why the honesty rules keep showing up. When an agent reports success on a firmware flash that did not happen, you find out with a brick on the bench. Mining teaches you very quickly that a self-reported result is not a result, and that lesson transfers directly: the critic must judge the artifact, the evidence must be real, and a green light nobody verified is worse than a red one.

Everything here is free to take. Nothing on these pages requires our software, our hardware or our permission. If it earns you something, send some back — that is the whole arrangement, and it is the same one that keeps the rest of the DCENT suite open.

Agentic engineering is the practice of designing the whole system around an AI coding agent rather than only the message sent to it. It spans five layers that build on each other: prompt engineering (the instruction), context engineering (what the agent knows), harness engineering (which agent runs it and with what authority), loop engineering (act, observe, correct cycles) and graph engineering (many agents as a dependency graph). A failure at a lower layer is usually invisible at a higher one, so diagnosis starts at the bottom.
No, it is the first rung rather than the whole ladder. Wording still matters enormously, and a badly specified objective fails no matter how good the orchestration above it. What changed is that prompting alone stopped being sufficient once agents gained tools, long runs and the ability to spawn other agents. Prompt engineering is necessary and no longer sufficient.
Both are loop patterns but they solve different problems. A RALPH loop is brute force: the same prompt re-run in an infinite shell loop with fresh context each iteration, using the repository as memory. It is cheap and effective at grinding through well-defined work. A Gauntlet loop is adversarial: a builder produces a real artifact and an independent critic with fresh context judges it against a quality bar, with authority to reject. RALPH grinds, Gauntlet judges.
No. Every pattern documented here runs on a terminal, a git repository and whichever coding agent you already use. DCENT_ADE exists because operating these patterns by hand across a fleet is tedious, not because the patterns depend on it. Take the methods and ignore the product if that suits you.
Look at what the agent produced. Output that misunderstands the goal is usually a prompt problem. Output that is coherent and confident but contradicts how your codebase actually works is usually a context problem, because the agent reasoned correctly over information it never received. Output that is right but cannot be applied points at the harness, and output that gets close over and over without landing points at the loop.

Start at the Bottom of the Ladder

The disciplines build on each other, so the fastest route through is in order. If you are debugging a fleet that is already running, jump straight to the layer your symptoms point at.

Prompt Engineering See DCENT_ADE

Related products, repair, and setup paths

Last reviewed August 13, 2026.