A dispatch from the steppe · where I've been for two weeks
I spent two weeks
building a fire
that tends itself.
A distributed AI build-laboratory, running on the machines already humming in the next room. Here is the whole arc — from a memory bottleneck to a workshop that now plans, schedules, watches, and improves itself while I sleep.
— Derek · Steppe Integrations · 2026
↓ the arc
Why any of this exists
It began with a machine that had more muscle than it could feed.
Bolted into my AM4 workstation are two Intel Arc Pro B70 accelerators — roughly 64 GB of video memory between them. But the box they live in has only 32 GB of ordinary system RAM. That asymmetry is the seed of everything that follows.
You cannot naively pour work onto those cards. Push a model past a card's safe envelope and it spills out of VRAM, back across the PCIe bus into that too-small pool of DDR4, and the whole machine locks up. I learned the number the expensive way — ~16 GiB per card, not the ~32 the spec sheet implies — after hanging the box twice.
Trying to feed 64 GB of video memory from a 32 GB pool forces you to learn things you'd otherwise never touch: how a model fills its context, how it loads and unloads, what a load actually costs versus a query. I studied all of it for one reason only — it was standing directly between me and the thing I wanted to run. That's the quiet secret of this whole depth: it was forced, not chosen.
When you have expensive capacity you can't use blindly, and cheaper capacity everywhere else, you don't have a hardware problem. You have a scheduling problem. That realization is what turned a pile of GPUs into a system.
It also turned into a discipline. I built CLI tools that expose the AM4 box's thermals and load signals and fold them back into my daily baseline — so I'm always reading the real ceiling of the hardware I already own. Before I spend a dollar on more, I want the evidence that I've actually hit the limit of what's in the room. Instrument the ceiling first; buy second.
I took that further than most people would. Before I wiped the box for Linux, I went all the way down to the Windows memory manager itself — pre-registering my predictions, then benchmarking, to prove exactly what these cards could and couldn't do on a dying OS. They couldn't do enough: Windows would involuntarily evict a model that fit, collapsing decode roughly 5×. That's a measured reason to move, not a hunch. And the work became public tooling — b70tools, because Task Manager was lying about what the cards were doing, and denning, a pre-registered study of running model state on memory-inverted, OS-arbitrated GPUs. I wasn't the only one sitting on new hardware I couldn't fully use without nuking my setup. So I wrote down what I found.
this is the part a corporate budget almost never funds: nobody with a cloud account is incentivized to understand one machine's limits this deeply. i am — it's my hardware, and my runway.
The arc, in seven movements
It started with pictures.
The first real workload was image generation — and it's still the most tangible proof of the whole idea. To place a job I had to know, precisely, how much memory a model needed, which card was free, and what was already resident. That code — a fail-closed VRAM estimator that never guesses and never evicts — taught the system its core abstraction: cards are resources, models are resident state, memory is the thing you run out of.
But the part I'm proudest of is the choreography. I stacked one image-gen workflow across every machine in the room, each matched to what it's best at: the AM4 box's two big-VRAM B70s hold the heavy models resident, OMEN's fast RTX 5070 handles the lighter prompt refinement, and OMEN's big-RAM CPU scores the results for aesthetics and prompt-fit. Consumer hardware sitting in an apartment, orchestrated into a pipeline that produces image generation to rival what you'd rent from a frontier service.
And here's the through-line to everything that follows: that hand-tuned, capability-matched placement is the scheduler, three months early. I was solving the job-shop problem by hand — this model on that card, that step on this box — long before I ever wrote it down as a constraint solver.
image-gen didn't just make art — it taught the whole system how to think about a GPU, and it was the first time I scheduled heterogeneous hardware by what each piece does best.
Then I made it observable.
Before scaling anything, I hand-wired OpenTelemetry through the fleet — so a single unit of work could be traced from the moment it's accepted, across machines, down to the agent that runs it. I built the first orchestrator in C# on Microsoft's Agent Framework (farmer): a workflow that reserves a VM, dispatches AI work over SSH, reviews the result deterministically, and archives it.
The doctrine that stuck: durable events and artifacts are the system of record; the trace viewer is second. Evidence is graded — declared → measured → stable — and nothing downstream is allowed to trust a signal until it's earned its grade.
But the technique I lean on hardest is subtler: I stamp a business ontology onto the spans themselves. A trace isn't a wall of timing data — each span is tagged as an action with intent: work.accepted, builder.assigned, promotion.held. While I'm building, that's how I actually understand and debug what the infrastructure is doing. Once it's built, it's why I never have to refactor a dashboard again — because the trace graph doesn't describe the business, it is the business ontology. The flame graph — the fire graph, on a system like this — reads as features and decisions, not CPU and latency.
observability first. you cannot schedule what you cannot see — and the span already speaks in business terms, so the dashboard never has to be rebuilt.
The move I kept repeating.
Here's the pattern underneath the whole build, and it's the part I'm proudest of. I'd use a frontier agent to stand up a local tool — then drive that tool with agents to test the next piece — and keep going until the thing was stable enough to stand on its own and the agent could step out.
The frontier model's job is to build the machine that removes the frontier model from the next hundred runs.
Scaffolding that retires the scaffold. Every cycle lowered the maintenance cost and pulled the operator — me — one step further out of the loop. That's not automation bolted on at the end. It's the grain of the wood.
One door.
Then came HEARTH — an always-on gateway that every offload has to pass through. Its first job is thrift: hand self-contained sub-tasks to a local model instead of burning frontier tokens on them. But its real job is quieter and more important.
Every call across that door is written to an append-only ledger before the result is ever returned. No updates, no deletes — just a growing record that can be replayed from zero to rebuild every downstream belief. Because there is exactly one door, the record never fragments. The system was built for one workflow, but its true shape is a laboratory: it can run entirely on local models, or stand frontier and local side-by-side and measure the difference.
the offload saves a token and records an observation in the same act. capture is the moat; the learning is downstream, and rebuildable.
A guard dog that watches meaning — and dreams.
With the fleet running unattended, I needed something watching it. Watchfire is a watchdog that goes past "is the service up?" to "does the system still make sense?" — hunting for incoherence like a job that claims to be running while its GPU sits cold, or a success reported with no artifact behind it. It heals the failures that are obvious and reversible on its own, and flags the ambiguous ones for me. And when everything is quiet and the cards are idle, the same watchdog identity spends the silence rendering images.
One night, I simply let it run. By morning the guardian had dreamed a thousand images — start to finish, driving the whole distributed pipeline from the first movement, while I slept. That's the entire thesis in one tangible outcome: a fire that tends itself, doing real work with nobody watching. Idle silicon never sits truly idle.
Eight of the thousand — dreamed overnight on idle B70s, no one at the keyboard. Stained glass and mosaics, mostly: the modular fleet, rendered in the medium it most resembles.
next slice, already designed: give it ears. Put the idle NPU to work as an acoustic classifier — so the machine can hear the fans on the AM4 box spin up and know, before any software signal arrives, that it's under real load. Today it watches thermals and utilization; the microphone is the earned upgrade.
A problem I first met in 2019.
Once you treat hardware, a model, and a slice of time as things that combine into a capability, the question "what should run where, and when?" becomes a job-shop scheduling problem — the exact family I wrote about years ago using constraint solvers. The whole career came full circle.
So the scheduler is a real CP-SAT constraint model, and its objective encodes two economies. Metered frontier tokens are priced so heavily that a local placement always wins — unless a hard deadline is physically impossible on owned hardware and forces the work onto the paid path. Owned silicon over rented tokens, by construction. And because the story started with a memory bottleneck, loading a model into VRAM is modeled as its own scheduled operation contending for that single DDR4 staging slot.
on a fair test it cut deadline misses from 19 to 0 against naive first-come-first-served — while spending the cheap economy first.
The lab studies itself.
The last piece closes the loop. I can stand up a matrix experiment — sweep planner against critic, prompt against prompt, one refinement lap against three — run every cell on the same HEARTH backends production work uses, and score the results with a held-out judge. It found things I'd have guessed wrong: that a second refinement pass helps but a third actively hurts, and that an early "concise writing wins" result was partly the judge rewarding brevity — a confound I only caught because every run was on the record.
Those findings don't sit in a report. They get baked back into the prompts the system uses. Idle GPU time is priced and auctioned to the highest-worth experiment. The workshop uses its own downtime to get better at its own job — and much of what you've just read, the system built for itself.
a local planner scoring 85 vs 65 against a weaker one on a blind judge — that's not a vibe, it's a measured result the fleet produced.
What makes it unlike the others
Plenty of people are wiring agents together. A handful of choices here are genuinely uncommon.
Capture is the moat
Most agent frameworks treat a run as exhaust — logged, maybe, then gone. Here every crossing goes through one door and is recorded before it returns. The complete, replayable dataset is the durable asset; the intelligence on top of it is downstream and rebuildable from zero.
Two economies, in the math
Not a heuristic — a constraint solver whose objective prices rented API tokens so heavily that it will always choose the silicon you already own, unless a deadline makes that physically impossible. Owned-vs-rented compute is a term in the equation, not a preference.
Idle silicon is never idle
When an owned GPU goes quiet, the system pulls the highest-value experiment and runs it — or renders art. Sunk compute is a budget to spend, not a resource to waste. Downtime is fuel.
Capable, but disarmed
It can dispatch work with no human in the loop. It ships with that switched off — earned only by passing a supervised cycle first. The scheduler advises until its own track record proves it should decide. Restraint is written down, not assumed.
Memory is a first-class cost
Because the whole thing was born from a RAM bottleneck, loading a model into VRAM is a scheduled operation that contends for a single staging slot. The solver has mechanical sympathy for the actual physics of the box.
It builds itself
The recurring move: use a frontier agent to build a local tool, until the tool is stable enough that the frontier agent isn't needed anymore. The expensive intelligence is spent making itself unnecessary for the next hundred runs.
The trace graph is the business
Spans carry business intent, not just timing — work accepted, builder assigned, promotion held. The flame graph reads as features and decisions, so the observability layer never needs a dashboard refactor. The ontology lives in the span.
Instrument the ceiling before you buy
CLI tools surface thermals and load into the daily baseline, so the true limit of owned hardware is always in view. Capital waits on evidence the ceiling was actually hit — not on the urge to buy more.
Every one of those choices is written down as a dated architectural decision — the reasoning survives, not just the code. A few, verbatim:
Where it honestly stands
The point isn't a demo. It's an instrument — and I'd rather tell you exactly what's load-bearing.
None of that reads as unfinished to me. A working instrument that knows what it hasn't earned yet is worth more than a demo that pretends it has.
The part nobody sees
The intelligence was the easy half. The distributed plumbing under it is what actually cost me the two weeks.
The glamorous part — agents planning, critiquing, writing code — mostly worked. The part that was genuinely hard, both the first time I built this and the second, was the unglamorous one: building, deploying, and debugging a distributed system with no screen to look at. A headless fleet fails at 3 a.m., on a machine you aren't sitting in front of, in a way no single log line explains — and there is no window to glance at, because there is no window.
I've shipped at real scale for years. But always somewhere I could declare scale and fan-out and let a managed platform make it true — autoscalers, replicas, concurrency I defined in a config and never had to build. This is the one corner of CI/CD and orchestration my career had never forced me to exercise myself, because the platform had always been underneath me. This time there was no platform. I was the platform — the fan-out control, the cross-machine tracing, the "is this thing actually alive or just pretending" checks, all of it by hand.
There's no dashboard glance on a system with no screen. You either instrument it — or you fly blind.
Which is exactly why two of the earliest decisions look the way they do. Observability came first because you cannot debug what you cannot see across five machines. The guard dog exists because a headless fleet has no operator watching it — so something had to, and it couldn't be me. Every hard-won hour went into that layer. It's the least visible part of the whole system and, honestly, the part I'm most changed by having built.
And here's the quiet reward for all of it: everything I just described — the tracing, the liveness checks, the guard dog — surfaces to me, day to day, as two words. /checkmcp asks whether the door is open. /checkmechnet sweeps every machine and hands back a table. The hardest layer in the whole system became the simplest thing I do — this very page began with me running both.
the second time was still the hardest part. that's not a complaint — it's the measure of how far outside the paved road this actually is.
What it's actually for
The benchmarks are the surface. Underneath, the goal is seamless collaboration — a system that watches the operator as closely as it watches the agents.
Yes, the lab can benchmark models and A/B whole workflows against a blind judge. That's the obvious use. But scaling it — even adding the gateway itself as one more node — never changes the thesis; it just extends it. Every new machine is one more place the same instrument reaches.
The deeper value shows up when I run a frontier task through the same door — a real tool call, or a /retro that writes up a working session. That isn't overhead around the experiment; it is an observation. The lab doesn't only measure small models competing on toy problems. It measures real work — frontier included — on the same ledger as everything else.
And here's the part I care about most. The same capture that profiles the agents can profile me. How I direct, where I step in, what I hand off and what I keep, when I override — the operator is in the dataset too. The lens that measures the machine can turn around and report back on the human working it.
The goal was never to remove the operator, or to babysit the machine. It's seamless agentic collaboration — a loop that gets better at working with me, because it can finally see both halves of it.
The part I'll let myself be proud of
Three months ago, this was a drawing of a system I'd only ever theorized. What runs today looks remarkably like it.
I didn't come up through distributed systems — my background is architecture and identity. To turn that sketch into something real I had to learn the parts that weren't mine yet: Linux, headless machines reachable only over SSH, Docker, a CI/CD pipeline to hold it all together. That learning was the price of admission, and I paid it — to build something I'd only ever argued was possible.
And it came out close to the drawing. The planning loop, the builder farm, the scrum master, the observability spine — roughly where I'd sketched them three months earlier. Then it grew easily: new capabilities slotted in as new nodes, not rewrites. The whole reason I could keep adding to it this fast is that the shape was right to begin with.
When the map and the territory agree — and the territory keeps taking extensions without a fight — the thinking was sound. I'll let myself be proud of that one.
This didn't appear out of nowhere. The design above is timestamped in Lucidchart; the thinking behind it is timestamped on LinkedIn, month after month, from long before there was a system to show:
- Systems thinking, learned from machinery — accountability before authority, respect the capacity limits.
- An experiment: treat models as a team, aligned by contracts and tests, not clever prompts.
- Not an experiment — a distributed system: telemetry first, the pipeline as a message bus.
- The thesis: a traceable learning loop, guardrails, humans in the loop.
- First commit. The build begins.
- The architecture in full: Planner → Builder → QA across three VMs.
- Agentic defense: specialized agents, one cross-stream correlation layer.
- Two Intel Arc B70s, 64 GB pooled VRAM — open models on Windows, no CUDA.
- Keeping a work session alive across a crash: /retro, /sup, decision records.
- The frontier model is the commodity; the structure you hand it is the value — the 2019 lesson, again.
- Every piece of information belongs somewhere: weights, retrieval, or preserved artifacts.
Ten posts, seven months, one direction — and then the two weeks that built it. Receipts over rhetoric.
So — why I went dark
Because for once, the thing I was building and the moment I was in lined up exactly.
And if you follow me, you already know: two weeks is a long time for me to be quiet. For the better part of nine months I've posted every week or two — that ledger above is the habit, not the exception. The silence was the tell, and leading with it was the honest thing to do.
I'm between roles, in a lean stretch, watching a genuinely short window in this industry. I could have spent these two weeks applying to things. Instead I spent them proving — to myself first — that a distributed, self-improving AI build system can run on consumer hardware sitting in an ordinary apartment, and that twenty years of being a solution architect actually compounds into something when you point it at this.
The scheduling problem I'm solving now is one I first wrote about in 2019. The methodology I'm running is one I've been publishing in the open. The difference this month is that I stopped typing the code and started directing the agents that write it — which is the only reason one person could build this much this fast.
That's where I was. Not lost — tending a fire, and getting it to the point where it keeps itself lit. Now I get to show you.