Category: Uncategorized Page 1 of 7

In 1895 you didn’t buy a car. You bought a horseless carriage — the new machine named for the animal it removed. The name is the whole lesson: the carriage didn’t change. The wheels, the seats, the cab — all still there. What changed was what pulled it. The horse went out, the engine went in, and the same carriage could suddenly run at a pace no stable could feed.

Here is the same swap, happening right now, in software.

Copilot is the carriage. It’s the vehicle everyone already has — the chat surface, the agents, the buttons, the place work actually rides. It is a genuinely good carriage.

You are the horse. Today, almost everything a copilot does, it does because a person is pulling: typing the prompt, clicking the button, checking the output, deciding what happens next, then pulling again. Call this configuration what it is — You + Copilot, a personed harness. It works exactly the way a horsed carriage worked: beautifully, at the pace of one animal’s attention, and it stops the moment the animal needs to sleep, eat, or attend a meeting.

The Brainstem is the engine. A brainstem — in my RAPP work that’s the literal name — is a persistent engine built out of your stuff: the agents you’ve written, the tools you’ve wired up, the memory of how you do things. It isn’t a smarter chat window. It’s the thing that can sit where you sit and pull what you pull. Put it in front of the same carriage — Brainstem + Copilot — and you have a personless harness: the carriage unchanged, the pulling replaced.

What the swap looks like in practice

This is not a story about testing. It’s a story about the new way of work — testing just happens to be the first seat the engine took from me, because testing is the purest form of person-as-horse: a human clicking through an app after every change to see what broke.

I had just finished a feature I believed was done. Instead of strapping myself into the harness — open the app, click the toggle, watch the panel, check the download — I handed the job to an agent with a real browser and a list of expectations, and went to work on something else.

It came back with five defects. One was a blocker: the page was loading with zero JavaScript, so the whole feature was a painting of itself. Another: the one control that half-worked was a switch that could be turned on but never off. A third: a checkbox had quietly stretched to 87 pixels wide and shoved its own label onto three lines. Nothing in my automated test suite could see any of this, because it all lived in the seam between “the code is right” and “the thing works when a hand touches it.” It was findable only by pulling the carriage — which until that day had meant me.

I fixed the five, sent the engine back in, and it returned a green table: thirty-three checks, no human involved. My report changed from “try it and tell me what breaks” to “it’s done, and here’s the run that proves it.”

What makes an engine trustworthy in the harness

A few things separate an engine you can trust from a demo that waves its hands:

1. It pulls through the front door. Real clicks, real dialogs, real downloads — not API calls impersonating a user. The whole value of the person it replaced was that they used the product like a person.
2. It expects the annoying things. A confirmation popup it didn’t predict is a failure, not a nuisance. Layout gets measured — “this control is at most 22 pixels” — not eyeballed.
3. It checks what should be absent. The feature that must stay invisible until enabled, the panel that must vanish on disable. Human testers almost never verify that things are properly gone. An engine always can.
4. It never fakes a pull. If it can’t run, it says so loudly. A green light that didn’t actually execute is worse than a red one.

The arithmetic: horsepower over personpower

James Watt invented the unit “horsepower” for a simple commercial reason: he was selling engines to people who owned horses, so he measured what a horse could sustain and priced his machine in the buyer’s own units. Let’s do the same. Define one personpower as one attentive power user at a browser — someone who knows the app, knows the checklist, and doesn’t dawdle.

My harness run is 33 checks across two surfaces. Hand-executed, the mix is unforgiving even for a fast operator: the simple look-and-click checks go at ten seconds or so, but verifying a prefilled URL’s query parameters takes half a minute, measuring whether a control is 13 pixels or 87 takes a trip into devtools, and confirming an exported file actually downloaded and contains what it should takes a minute of its own. Averaged across the mix, that’s a solid twenty minutes per full pass — and you have to do the pass again after every fix.

The engine’s measured time for the same 33 checks: 19.1 seconds. That’s roughly a 60:1 ratio on the stopwatch — the engine runs at about sixty personpower on this workload. But the stopwatch undersells it, because the honest denominator is attention: the twenty human minutes were twenty minutes of a person’s full focus, while the engine’s nineteen seconds cost zero. I ran it four times tonight without noticing.

The carriage stays; the horse retires

Notice what the swap does not ask of you. You don’t abandon the carriage. Copilot, the app, the surfaces you’ve already invested in — all of it stays. That’s why the horseless carriage won so fast: it didn’t ask the world to reinvent the wheel, only to stop feeding the horse.

And notice where the person goes. Ford’s engine didn’t remove people from travel; it moved them from pulling to steering. The Brainstem doesn’t remove you from the work; it moves you to the seat where you set the destination and read the verdict. You stop being the horse. You were never at your best as the horse.

“Horseless carriage” survived only as long as it took people to forget that carriages had ever needed horses. “Personless harness” will go the same way. For a while it will be the odd new practice with the odd new name — and then it will not be “the new way of testing” or even “the new way of automation.” It will just be work: Brainstem + Copilot, the engine pulling and the person steering. And the idea that a human being once hand-pulled every prompt, click, and check through their copilot will sound like keeping a horse for your commute.

Every enterprise AI project I’ve ever seen dies a little in the same place: waiting for data access. The use case is approved, the agent pattern is proven, and then everyone sits for six weeks while security reviews a service account for a demo.

So we stopped waiting. We publish the enterprise systems themselves as static APIs.

The pattern

A static API is a read-only API served entirely from files on a Git host — no server, no database, no runtime. GitHub’s raw CDN is the host: free, globally cached, CORS-open, forkable. One idempotent build script turns hand-authored seed data into responses shaped exactly like the real system’s wire format.

This week we added two new organs to the commons at kody-w.github.io/rapp-static-apis:

• sap/ — an S/4HANA gateway simulation. OData v2 envelopes, __metadata per row,

real service names (API_COMPANYCODE_SRV, API_PLANT_SRV, API_BUSINESS_PARTNER). A client — a custom connector, an HTTP node, a RAG ingester — cannot tell it from a live gateway.

• sharepoint/ — a Graph-flavored document library for a fictional S/4HANA transformation

program: charter, workstream directory with owners and backups, governance and escalation paths, per-stream one-pagers, a data-migration playbook, a cutover plan, an FAQ.

The company is Meridian Manufacturing Group. The program is Project Phoenix. Neither exists. Every name, plant, and risk register entry is invented — which is precisely why we can publish all of it.

Try it — no auth, no signup, any language:

RAW=https://raw.githubusercontent.com/kody-w/rapp-static-apis/main
curl -s $RAW/sap/registry.json
curl -s $RAW/sap/api/opu/odata/sap/API_PLANT_SRV/A_Plant.json
curl -s $RAW/sharepoint/api/v1/sites/phoenix/documents.json
curl -s $RAW/sharepoint/api/v1/sites/phoenix/docs/workstream-directory.md

What grounds on it

On top of those two sources we built a transformation knowledge companion — the classic MVP every large program asks for: “Who is responsible for this workstream?” “Who owns Procure-to-Pay?” “I’ve got a blocker — who do I escalate to, and who’s their backup?”

It’s two small Python files on the RAPP memory-agent platform (kody-w/rapp-ai): an ingest agent that walks the library listing, fetches each document, and chunks it by section; and a companion agent that scores chunks against the question and returns passages with citations — document title, section, author, URL. The LLM is instructed to compose only from those passages and cite its sources. Ask the escalation question and it merges the Data Migration Playbook with the Governance & Escalation doc into one answer — several sources, one clear response, every fact attributed.

The part that matters: repoint two URLs and the same agent grounds on a real SAP gateway and a real SharePoint site. The demo isn’t a mockup of the production system — it’s the production system with synthetic data behind it. The distance from demo to pilot is a config change.

Why static?

Because the data plane becomes infrastructure anyone can hold:

• Forkable — fork the repo, edit the seed JSON, run build.py, and you have your industry’s

version in an afternoon.

• Versioned — every state of the “enterprise” is a commit. Demos are reproducible forever.
• Zero standing cost — nothing to patch, scale, or pay for.
• Honest — it’s all synthetic by construction, so there is nothing to leak. The security

review takes as long as reading this sentence.

The loop that makes it fun

The platform loads its agents from cloud storage at runtime. So once the Microsoft 365 channel is wired up (a Copilot Studio solution, imported once), a new or changed agent file hot-deploys into the running app over HTTP and is answering in the M365 chat seconds later — no redeployment, no solution reimport. Iterating on an agent in front of the people who’ll use it, in their own Copilot, is a genuinely different way of building.

Fork the commons, point an agent at it, and stop waiting for data access.

Everything above is public: the commons, the platform, the agents, the build scripts. All example data is synthetic; any resemblance to a real company is coincidental.

There’s a diagram you’ve seen a dozen times this season. A changelog, really, dressed up as an announcement. A framework rolls out its newest capability and there it is — three or four neat boxes laid side by side. A harness. A loop. A skill file. Maybe a scaffold for good measure. Each box gets its own paragraph, its own icon, its own little surge of fanfare.

And then, quietly, the diagram hands the whole thing to you. Here are the parts. Wire them together.

Sit with that for a second. Every ecosystem in this year’s crop of agent frameworks is shipping the same primitives — and shipping them apart. The harness lives over here. The loop lives over there. The skill file is its own artifact in its own folder with its own format. They are not assembled. They are boxed. The assembly is left as an exercise for the reader, and the reader is you.

What nobody on those slides will say out loud is the thing the whole picture is screaming: the industry is rebuilding, in scattered pieces, an organism that already shipped whole. And the problem was never the parts. It was the spaces between them.

Watch the timeline they keep drawing for you. First it was prompt engineering. Then context engineering. Now there’s an eight-minute explainer on harness engineering, with a tidy arrow promising the next discipline is already loading. Every year, a new thing you must master to be allowed to use the thing. That escalating ladder of -engineerings isn’t progress. It’s the tell. Each new rung exists because the last pile of parts didn’t hold together on its own.

The parts are not the problem. The seams are.

Let me be fair to the parts, because the parts are real and the parts are good.

You need a harness — something that gives the model hands, that turns a string of text into an action in the world. You need a loop — something that lets the model act, observe what happened, and act again, instead of firing once into the void. And the skill file sounds lovely on paper: a little document where you write down what your agent should know, what it’s for, how it ought to behave.

Each of these is a legitimate organ. None of them is wrong.

But notice what the skill file actually is once you’ve lived with one. It’s a suggestion box. It drifts. It says “prefer this, usually do that” and then sits there hoping the model reads it the way you meant. You write a rule, and on turn nine the model forgets it, and now you’re debugging probability. It is advisory, not load-bearing — the right idea with no spine, guidance that floats free of the machinery it’s supposed to govern.

And here’s the quiet joke inside the new harness fanfare: the harness is real — it’s the deterministic spine the suggestion box never had. But bolting a deterministic harness next to a drifting skill file doesn’t cure the drift. It braces it. It’s a splint on one organ while the seam between them keeps doing the bleeding. The harness is the determinism the skill file is missing — handed to you as a separate part, so the suggestion box is still a suggestion box. That’s not a fix. It’s a bandaid where you needed a body.

And the loop? The loop is where people quietly drown. Loop engineering is its own dark art — when to stop, how to feed results back, how to keep the thing from spiraling or stalling. The frameworks hand you the loop as a box and a thumbs-up, as if drawing it on a slide is the same as solving it.

Here is the real cost, and it’s not technical. It’s the seams. Every place two boxes meet is a place a human now has to stand and do glue work. The harness has to learn about the loop. The loop has to respect the skill file. The skill file has to actually reach the harness. None of these connections come for free. The diagram drew them as touching edges. In your codebase they’re integration projects.

And here’s what the segmentation actually costs you. Pull the organism apart into a harness and a loop and a skill file, and you don’t get three smaller wins. You lose the things that only exist when they’re one: portable, shareable, deterministic, un-drifting. Those were never features of the parts. They were properties of the whole. A part can’t be portable when it only runs once it’s wired to three other parts. The ecosystems sell you organs and leave you to grow the connective tissue — and the connective tissue was the product.

RAPP already collapsed the boxes

Now look at what RAPP did, and notice it did it before any of these slides existed.

In RAPP there is one artifact. A single file — agent.py. It is not a harness plus a loop plus a skill document held together with hope. It is one thing that is all of those at once.

Every agent is a harness. The capability and the hands that wield it live in the same file. There is no seam between “what to do” and “how to do it” because there’s nothing to seam — it’s one body. And unlike the drifting suggestion box, that body is deterministic. It doesn’t hope the model behaves. It defines behavior. The advisory document and the load-bearing machinery are the same lines of code. Which is exactly why the equation the whole industry is circling finally closes:

a skill file (a drifting suggestion box) + a loop + a harness = one agent file

— but without the weakness of those being three separate pieces a human has to figure out how to fasten together. The plus signs are the problem. RAPP removed the plus signs.

And because it’s one file, it travels. You don’t deploy an agent. You don’t provision it, wire it, register it across four services. You drop the file in a folder, and the brainstem hot-loads it on the fly — no restart, no config, no glue code. The capability wasn’t installed. It was absorbed. You hand someone the file and you’ve handed them the whole working organism, harness and behavior and all. Try doing that with a pile of boxes that only function once correctly assembled. You can’t share a diagram. You can share a body.

The loop you never have to build

But the part the slides really miss — the part that should be the headline — is the loop. Because RAPP doesn’t ask you to engineer one. It solves loop engineering before you ever think about it, with a double loop.

The first loop is your twin. The brainstem is always on, and it acts as you — it does the work, runs the agents, carries the task forward. It loops the way a heart beats: on its own. That’s one loop, turning, doing the job.

The second loop sits above the first. A brain-surgeon — a coding copilot whose entire job is to edit the agents while the twin keeps running. One loop does the work. The other improves the worker. The body stays awake; the surgeon operates on it mid-stride.

In the assembly-required world, you are that second loop. You’re the one who stops, reads the logs, rewrites the suggestion box, re-wires the harness, restarts the thing, and hopes. You are the connective tissue and the maintenance crew. RAPP took that job — the loop that improves the worker — and folded it into the organism. You never hand-build a loop, because the loop that builds loops already exists, and it isn’t you.

That’s the 1 + 1 = 3. One loop alone is an agent. Two loops, nested, is an organism that grows itself.

So when the slides start naming the next discipline — loop engineering, and there will be a course — let me say the quiet heresy plainly: you should be out of the loop entirely. Not a better seat in the loop. Not a cleaner loop. Out. You shouldn’t engineer loops, tune loops, or think about loops at all. The whole pitch of “get good at loop engineering” is a confession that they’ve handed you a loop you now have to babysit. The best loop is the one you never knew was running.

I do not want to think about AI engineering

Here’s the part I’ll say in the first person, because it’s the only part that’s actually about me — and about you.

I do not want to think about AI engineering. At all. I don’t want to learn the harness API. I don’t want to tune the loop. I don’t want to keep a suggestion-box file from drifting. I want my AI to do the engineering while I steer — and I want to steer without needing to know what’s happening under the hood.

That’s not laziness. That’s the whole point of the machine. We built tools to do work for us, and then made operating them a second full-time job.

And let me be clear about what I’m not saying. The machinery matters, and you should absolutely be able to crack it open. Going back later to understand how the body works is good — wonderful, even. Curiosity is how the people who build the next thing get made.

But there’s a world of difference between understanding being available and understanding being required. The assembly-required ecosystems make it a requirement up front: you cannot use the parts until you can engineer the parts. That’s not a product. That’s a curriculum — and a curriculum is a wall. The easy on-ramp dead-ends into the hard one. That’s not a ramp. That’s a trapdoor.

And it does something quietly ugly. It splits the world in two. Those who can wire the boxes, and those who can’t. Those who get an organism, and those who get a pile. The lego-piece ecosystems aren’t just shipping parts. They’re building that divide, one tidy diagram at a time.

The horizon the pile can’t see

Here’s what gets lost while everyone’s heads-down wiring one agent’s harness to its loop: there’s a move past the single agent, and you cannot picture it from inside the assembly project.

When an agent is one portable, deterministic file, the next step isn’t a better part. It’s many of them — bodies that compose, hand work to each other, organize into something larger than any one of them. A swarm. But you can’t think that far ahead while you’re still deciding how the skill file reaches the harness. The pile keeps your eyes on the floor. Anyone still gluing primitives together will eventually have to build the layer that holds them — their own version of a brainstem — and they’ll do it distracted, late, and bolted onto a foundation that was never meant to carry it.

The whole point of finishing the body is to finally look up. You don’t get to ask “what can a thousand of these do together?” until one of them is whole, portable, and yours.

Who the body is for

RAPP solves for the people on the wrong side of that line. Not the engineers who’ll happily assemble the parts — they’ll be fine either way. The wider market. The overwhelming majority of people who will actually use AI, who have a job and an outcome and just want to point and steer, who do not want to learn what a harness is and should never have to.

That’s not the leftover market. That is the market. The assembly-required crowd is optimizing for the few who enjoy the assembly and quietly leaving everyone else behind. RAPP picks up everyone else — and hands them a whole organism, in one file, that comes alive when they drop it in. One file that is its own harness, deterministic, portable. Two loops they never had to build. And underneath, if they ever get curious, a machine simple enough to actually read.

You shouldn’t have to become an engineer to be served by your own AI. You should just have to steer.

Point at the outcome. Let the body do the engineering. Drop the file — it comes alive. Steer.

---

Field notes from Kody Wildfeuer on RAPP — an open, independently-developed pattern for building AI organisms you can own, talk to, and launch anywhere, that complements every engineering tool you already use. The kernel is simple. The body is yours. · kodyw.com