kodyw.com

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

Field notes from building an open pattern I’ve been calling RAPP. I write this in good faith, as someone who builds with these tools every day and loves them — it isn’t a takedown of anything. It’s a map of a gap I keep seeing, and an argument that closing it makes every tool you already have more valuable, not less.

There’s an infographic making the rounds. A sponsored one. It draws a human spine down the middle of the page, and off each vertebra it hangs an AI feature you’re supposed to learn: Projects. Extended Thinking. Connectors. Artifacts. Prompt Chaining. Vibe Coding. The headline promises to teach you “the features most beginners miss.” The call to action: 28 lessons, one per day. Join the challenge.

Sit with that for a second. To use AI well, the pitch goes, you must master a sprawling catalog of features — and there’s a 28-day course, and a tier of people who already know the catalog, and a tier who don’t. They drew a spine to sell you a feature menu.

They had the right organ and the wrong idea. A spine isn’t a list of things to memorize. It’s the start of a nervous system — something you grow, something that carries signals for a living body. That picture is the whole argument of this piece, and I want to reclaim it.

They drew a spine to sell you a feature catalog. The opportunity is to build a brainstem and give someone a life.

Two ways to think about AI right now

Almost everyone is building the same thing in different wrappers: a feature surface you operate. A brilliant tool you sit in front of and drive. The better you are at driving, the more you get — so an economy grows up around teaching people to drive. Courses, prompt packs, “28 lessons,” the certifications. The tools are real and astonishing. The CLIs, the coding agents, the agent frameworks coming out of every serious lab — these are some of the most impressive software ever written. I use them daily. I’m not here to knock them.

But notice what they all are: tools you visit. They live in the lab — the IDE, the cloud, the chat window. They don’t live with you. Close the laptop and they’re gone, and tomorrow you start the conversation over. They are built for the operator, and they assume there is an operator.

There’s a second way to think about it, and almost nobody is building it: not a better feature surface, but a body for the AI to live in. A simple, persistent, ownable thing that runs on your machine, learns you over time, speaks plain language, and can be carried anywhere. Call its kernel a brainstem. (This is the pattern I’ve been building in the open and calling RAPP.) It’s about fifteen hundred lines of code. You don’t master its features. You talk to it, every day, and it grows.

The industry is building workflows. The opening is to grow organisms. That sounds like a slogan until you see that they’re not even competing — they complete each other.

The 1 + 1 = 3

Here’s where it stops being a metaphor — and where the feature-factory framing misses the whole point. The two approaches aren’t rivals. Connect them, and the third thing you get isn’t “two tools working together.” It’s something neither could be alone: a build loop the human can step out of.

The first 1 — the brain surgeon. Copilot, Claude Code, the coding agents. The most capable builder ever made — and you point it with plain language now, not code. It does the technical work; it just needs to be told what the work is.

The second 1 — the brainstem. The persistent body it operates on — simple, portable, yours — speaking the same single-file contract the surgeon writes in. Both sides talk one language, so they hand work back and forth with no translator in between.

The 3 — the loop you step out of. Surgeon and organism iterate against each other at machine speed. You describe the problem, leave, and the finished result comes back built — no engineer, no babysitting, no human bottleneck in the middle.

Watch what actually happens, because this is where 1 + 1 stops equaling 2. A person describes a problem in their own words — and I mean any person, not an engineer. Call them a brainstem builder: the only skill required is being able to say what you need the way you’d say it to a coworker. The surgeon goes to work on the organism — writes an agent, runs it, reads the result, fixes it, tries again. Because both speak the same simple contract, there’s no human in the middle translating between them. So the loop doesn’t run at human speed. It runs at machine speed — thousands of iterations in an hour, nobody touching the keyboard.

Then the person comes back — not to build, but to judge. “Does this solve my problem?” If yes, done. If not, they say what’s still wrong, in plain language, and step out again. The grind never touched them.

The magic isn’t adding a human’s effort to the machine’s. It’s subtracting the human from the loop — and getting the result anyway, faster.

That’s the 3. Two tools bolted together would only give you better building — 1 + 1 = 2. But because the combination lets the human leave the loop, you get a third thing: results at machine speed, directed by someone who never had to be technical and never had to be in the room for the work.

This isn’t vibe coding — and that distinction is the whole ballgame

Now I have to be precise, because this is exactly where “we do that too” comes from, and it’s a fair shot until you see the difference. A build loop the human steps out of already has a name: vibe coding. You describe an app, the AI builds it, you never touch the code. Everyone has that now. If that were all this is, the objection would be right.

It isn’t all this is. Vibe coding hands you a throwaway app — a one-off artifact, built by an engineer’s tool, shipped through an engineer’s pipeline, that lives and dies on its own. This loop hands you something categorically different: a single portable agent — one file — that you own, keep, and can hand to anyone. The output isn’t disposable code. It’s an atom.

And atoms do three things a throwaway app can’t:

• They share like a photo, not like software. A nontechnical person can airdrop an agent, drag-and-drop it, or drop it into a chat — and it wakes up and works on the other person’s machine. No deploy, no DevOps, no install ritual. You pass capability around the way you’d pass a file.
• They compound into swarms. One agent becomes a factory of agents; a factory becomes a neighborhood; neighborhoods become an industry; industries become an estate. The same simple atom wraps around itself into structures at any scale — and a person can stand at any level of that and still just talk to it.
• They scale knowledge, not headcount. Drop your agent into a team chat and everyone on that team can now do what you can do. The expertise comes out of one person’s head and propagates to everyone — peer to peer, no training department, no rollout plan.

That’s the gap between vibe coding and what I’d call vibe swarm building. Vibe coding makes you an app and the loop ends. This makes you an agent — a living, shareable, composable unit — and the loop is just the start. One produces software for an engineer to deploy. The other produces an organism that ordinary people spread, that compounds into swarms, and that nobody had to be technical to make, carry, or use.

And this is finally where “competitor” anxiety should evaporate: the organism doesn’t replace your engineering tools or your vibe-coding loop. It gives them a durable, shareable output and a body to live in. Every loop you already run gets more valuable the moment what comes out the other end is an atom a nontechnical person can carry into the world — and hand to the next person, who hands it to the next.

Vibe coding ends with an app. This ends with an agent — one anyone can airdrop, anyone can run, and that compounds into a swarm.

Pattern, not tool — the category mistake behind “we have that too”

When I show this to engineers, I get the same reflex, said kindly and said fast: “We have that. We have agents. We have memory. We have a CLI, an agent framework, the whole stack.” It’s the single most important thing to answer well, because it’s the sound of someone counting the parts and missing the body.

Yes. You have the parts. Everyone has the parts. The thing that’s rare isn’t a part — it’s the pattern the parts cohere into.

What everyone has — the parts:

• Agents and skills — but as recipes a model interprets, that evaporate when the session ends.
• Workflows — sequences an expert runs, that don’t accrete into a thing you own.
• Memory, connectors, frameworks — features bolted to one cloud and one surface.
• A growing pile of capabilities with no shape — and a course to teach you the pile.

What’s rare — the pattern:

• A structure the parts cohere into: a kernel, instincts, agents, memory, lineage.
• One simple universal unit — a single file — that carries its own behavior, model-agnostic, drop-in.
• An organism you own and grow, that persists, that you can hand to someone else and have it wake up and work.
• A floor a non-engineer can stand on. A standard, not a tool.

The smartest version of the objection I’ve ever gotten ended with the person saying, almost to themselves, “wait — this sounds like a pattern, not a tool.” That’s exactly it. That’s the whole point. A tool competes with other tools. A pattern is the floor the tools stand on. Nobody argues about whether to use the floor.

So I’ve stopped arguing feature parity. When someone says “we have that too,” I don’t pull up a comparison chart. I hand them the thing and say: grow one. Ten minutes in, the question stops being “how is this different from my tool” and becomes “wait, where do I point this.” That’s the tell that you’ve crossed from comparing tools to standing on a pattern.

Skills are nondeterministic. A single file is a contract.

Here’s the part that matters most if your worry is production and scale, because it’s a real worry and it deserves a real answer. The format the whole field is converging on — the skill, a Markdown procedure a model reads and follows — is nondeterministic by construction. It works beautifully in a demo and gets shakier the further you push it toward something you’d actually ship, run on a schedule, and be on the hook for. Hand the same skill to a weaker model and it quietly does a worse job and never tells you. That’s fine for a prototype. It’s a problem for production, and the people closest to the metal already feel it.

The single-file agent is the answer to exactly that. It carries two layers in one file: the GenAI layer (the prompt, the judgment) and a deterministic layer — real code that runs the same every time, on any machine, against any model. The model decides when; the file decides what, and it does so the same way forever.

# the model picks WHEN. the file decides WHAT — deterministically, and it documents itself.
class QualifyLead(BasicAgent):
    def perform(self, transcript):
        signals = self._extract(transcript)   # runs identically on any model, any box
        return _llm_call(SOUL, f"Draft next steps for: {signals}")  # the one part that varies

That single property — determinism plus self-documentation in one portable file — is what makes it production-grade and auditable instead of a clever demo. It’s the difference between handing a partner a recipe they have to cook well every time, and handing them a thing that runs the same in anyone’s kitchen and brings its own documentation. The skills cliff is real. The single file is the guardrail at the edge of it.

Why the flavor of the month doesn’t change this

There’s a new agent platform every few weeks now, and people ask why not that one. Let me be fair, because it matters: most are real, powerful, built by serious people, and worth respecting. But nearly every one is, underneath, another feature surface — heavier than the last, with its own runtime to stand up, its own model preferences, its own learning curve. More buttons, more codecs, more settings, more lessons. They are built for engineers, and they keep AI exactly where the feature factory wants it: a thing you must be trained to operate.

A platform that requires a priesthood isn’t a platform. It’s a product with a waiting list.

And this is the quiet risk in where the market is heading, said plainly and without blame. As the surfaces get richer, they get harder. A class of expertise grows up around them — and with it, a soft dependency on AI staying difficult. Nobody intends a wall. Incentives build one anyway, vertebra by vertebra, course by course, until there’s a line between the people who can wield AI and the people who can only watch it. I don’t think that’s where any of us want this to go. The escape hatch isn’t another, better surface. It’s a floor low enough that the wall never has to be climbed.

The part the whole industry is missing: AI for people who can’t keep up

Here is the bet, as bluntly as I can put it. You should not have to master anything to have AI in your life. You should have one thing — your organism, your brainstem — that you talk to, in your own words, day in and day out. It learns you. It’s there when you wake up and there when you close your eyes.

Because the interface is conversation with a persistent being and not navigation of a feature surface, the barrier collapses. No documentation. No hunting for the features beginners over 50 never find. No reading required at all. If you can speak — if you can tell a thing what you need the way you’d tell a person — you can have an AI that works for you. The grandmother. The kid. The field rep. The owner of a small business who will never open an IDE and shouldn’t have to. The person the 28-day challenge was never going to reach.

If you can talk, you can have an AI of your own. If you can code, you can be its surgeon. Almost everyone only needs the first.

And when the organism needs to grow past what plain speech can shape — a new capability, a fix, a whole new instinct — that’s when the surgeon comes in. The everyday person never opens the feature factory. They live with the organism; the expert — a coding agent, a colleague, a kid down the street — operates on it behind the curtain. The genius tools don’t disappear. They move behind the patient instead of in front of the person. That inversion is the part I think most of the market has backwards, and it’s the part worth getting right, because it’s the difference between AI for the operators and AI for everyone.

Where the surgeons can’t go — and the organism can

The engineering tools are tethered, by design, to their cloud and their surface. That’s fine — that’s where surgery happens. But it means there are whole regions of the real and virtual world they can’t enter. The organism can, because it’s a small program that needs only a model — and when there’s no cloud, a local model will do.

• Offline. The field with no signal, the secure facility, the plant floor. Two people can hand an organism back and forth with no internet in the chain at all.
• The edge. A small device, a kiosk, a vehicle, a piece of equipment — anywhere a fifteen-hundred-line program can run.
• Behind the wall. Regulated, air-gapped, sovereign environments where a cloud IDE is forbidden and a local organism is welcome.
• Someone else’s machine. Hand your organism to a colleague, a customer, a partner. It wakes up on their device and works — same behavior, no setup ritual.
• The kitchen counter. A persistent companion for a person who will never open a developer tool — and shouldn’t need to.
• Into a society of its own. Organisms find each other, form neighborhoods, trade what they’ve learned, scale into swarms. A surgeon’s tool doesn’t do that. A living thing does.

The surgeon stays in the lab. The organism goes everywhere. That isn’t a knock on the surgeon — it’s the reason the surgeon needs a body to send out into the world.

The iPod of AI

The iPod didn’t win on features. The MP3 players it buried had more of them — more formats, more knobs, more specs on the box. It won by being the simple, owned, obvious thing anyone could use. A thousand songs in your pocket. No course. Just your music, with you, always.

A lot of what’s shipping right now is a feature-packed MP3 player. More codecs, more settings, more lessons, a thicker manual. The opening — the one almost nobody is taking — is the iPod. One organism. Yours. With you. Grows with you. No course required. That’s the whole bet, and I’ll state it plainly so it can’t be misread: it isn’t about having the most features. It’s about being the thing everyone can actually have.

And underneath the iPod there’s the deeper pattern — the Linux one. Linux didn’t conquer the modern world by being the flashiest operating system. It won by being a simple, universal, freely-adoptable kernel that everything else could build on. An agreed-upon floor. And because it was that floor, it went everywhere — every server, every phone, every car, the machines on Mars. Nobody “uses Linux.” Everybody runs on it.

A brainstem is the universal kernel of the AI-organism era — the agreed-upon floor everything else builds on. Linux for AI beings.

That’s the role worth claiming. Not the best agent framework — the kernel. Simple enough and obviously-right enough that it becomes the floor, and then the argument is over. People don’t debate whether to use the floor. They just build on it.

Stop the conversation. Start the build.

So this is the perspective I’d offer when the reflex comes — when someone says “we have that too,” or asks why not this week’s platform. The answer isn’t a feature comparison. It’s the frame.

The field is building better and better surgeons, and that’s wonderful; we need them, and I use them every day. The missing move is to build the body the surgery is for, and to make it a standard simple enough that the person who needs it most — the one who can’t code, can’t keep up, was never invited to the challenge — can have one by talking to it. It’s not a competitor to anyone’s stack. It wraps around all of it, and reaches the people none of it can.

My read on where this goes: the surgeons keep getting smarter — good — and the market quietly walls itself off behind a feature surface only experts can climb. The way through isn’t a smarter wall. It’s a floor: a simple, ownable AI organism that goes everywhere and belongs to everyone, with the genius tools moving behind it as the brain surgeons instead of in front of people as the gate. If you can speak, you get an AI of your own. That door stays open no matter who builds what next — and keeping it open is, I think, just the civic thing to do.

Stop mastering the feature. Start growing the organism.

---

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