15. Final

An Agent Grown Into the Business: What Machine Do 12 Parts Add Up To?

The last post covered the final mile — starting from the agent's heartbeat and working all the way out to the interaction details a user's fingers actually touch. Fourteen posts, and every single part of this machine has been laid out and examined. But taking it apart was always a means, not the end. This last post, I want to step back and put this pile of parts back together, and look at the whole: what kind of machine is this, actually? And the question I've been sitting with since the opening — "isn't this just a wrapper?" — by this point, I think I can finally try to answer it in full.

🪧 Putting the Scattered Parts Back Together

Before writing this, I ran back through the last fourteen posts in my head, and felt a bit like an engineer who's just finished disassembling an entire engine — parts spread out across the floor. To keep from getting lost in the details, it's worth stepping back and asking myself directly: what do all these pieces actually add up to?

Individually, none of the 12 mechanisms is novel. Loop, Memory, Tools, Permissions — you can look every one of these up in any agent documentation. The real difficulty was never knowing "which parts exist" — it's twisting them all into one machine purpose-built for writing. Behind every joint between them is a decision made specifically for this use case.

So this post covers nothing new — it does exactly two things: puts the machine back together to see the whole shape of it, and walks back through a handful of threads scattered across the last fourteen posts, one more time, explicitly.

🖥 The Model Is the Engine. The Harness Is What Gives the System Its Skeleton.

Start by revisiting the overall architecture diagram from the opening post — the analogy back then was: an AI agent product ≠ a large model + a prompt, it's = a model (the engine) + a whole harness around it. Fourteen posts later, every part on that diagram now has a name and a face.

If you give every part of this machine a "role" to play, it reads like a genuinely organic whole, each piece in its own lane:

What this table is really trying to say is the cascading causal chain planted back in the prologue: this was never a flat pile of parts — it's one link depending on the next. First you need an engine that can spin (Ⅰ); the moment it spins, it naturally needs to remember things across time (Ⅱ); only once it can remember does shaping its behavior even become meaningful (Ⅲ); that behavior then needs to land safely in the real world (Ⅳ); complex tasks need to be broken down and delegated (Ⅴ); and finally, all of it has to be packaged into a product a user can pick up with ease (Ⅵ). Pull out any link in the middle, and everything downstream falls through.

🧬 One Thread Running Through Everything: "The More Critical, the More It Gets Taken Away from the Model"

Looking at it as a whole, a few threads run through everything, start to finish. The first is about determinism, and it came up in several posts already:

Anything that "absolutely must happen," "must never happen," or "is extremely expensive to get wrong" — don't leave that judgment call to the model's own discipline. Find a way to take it away from the model, deliberately, with a deterministic mechanism.

Gathering up the similar moves scattered across the series, here's the full list:

• Writing never needed a general-purpose shell to begin with, so Bash got deleted entirely (posts 8, 9), and an entire category of risk disappeared along with it.
• With 16 genres, the model was prone to picking the wrong one, so it doesn't get to pick at all — a deterministic chain does the single-choice injection instead (post 6).
• Slash commands could get silently swallowed by the CLI, so the backend strips the prefix and loads deterministically instead (post 7).
• The model can skip critical steps, so a hook welds them down at fixed lifecycle points (post 10).
• Final review is prone to going easy on itself, so an independent, read-only clone that never steps in to edit handles the gatekeeping instead (post 12).
• LLMs get loose with JSON, and there's a real upstream bug on top of that, so three layers of defense plus a schema whitelist catch it (post 12).
• Style signals are inherently noisy, so the profile never writes back automatically — the user reviews and confirms every single item (posts 4, 13).
• The model loves asking dumb questions, so a clarification filter gate catches them at the end (post 14).

These choices look scattered, but they're really the same idea, over and over: spend that precious, dangerous thing called "uncertainty" only where it's genuinely needed — the creative work itself — and take deterministic, programmatic control over everything else. The model's free rein should be spent making a sentence sound like you, never on deciding whether a command should fire.

🔀 Every Output, Eventually, Lands on One of Two Paths

What the model produces varies wildly, but in the end, it all sorts into two paths. A lot of the product decisions across this series really come down to one question: is this thing meant for a human to read, or for code to consume?

• Path one, for humans: the reasoning and final prose you watch appear character by character on screen — free-form, streamed, has warmth to it, and interruptible at any point.
• Path two, for code: num_turns, the conclusions from profile analysis, final-review reports, a plan's JSON, the diff from a second edit. None of this is meant to be read by the user directly — it's fed to backend code, so it has to be structured, validatable, and something you can write to a database.

This came up repeatedly across the series too: never mix the two into the same call. Post 1 never used num_turns as the user-facing "conversation round" count. Post 8 found that @tool can't return structured data, and simply routed structured conclusions through a separate schema-backed query instead. Post 12's final review, and post 11's plan — both rely on exactly this boundary to keep "for humans" and "for code" cleanly separate.

⚖️ Generic vs. Vertical Was Never Just About the Model

At this point, I can finally state the one thing this whole series has really been trying to say: how do you keep the product you've carefully built from collapsing into "just another generic agent" wearing a costume? Collecting every post's closing comparison table into one master table makes it clearer:

⚖️ The tradeoff · twelve instances of "the default move / why I didn't take it"

Mechanism	The "lazy" default	SmartWriter's customization
Loop	Expose every parameter, show num_turns directly	Only expose model and budget; the frontend counts rounds itself
Compact	No awareness of compaction at all	Watch compact_boundary, restore the core thesis right after
Session	Lost the moment you switch away	resume for precise restoration + fork for experimenting, built persistence myself
Memory	One pot, mixed together, remember everything	Style / rules / facts kept as three separate powers, the soul strictly guarded against contamination
System Prompt	Keep the coding persona	A writing copilot from the first character on, every dynamic value routed elsewhere
Skills	Throw a pile of skills at the model and let it pick	High-value genre decisions taken over deterministically
Command	A feature switch	An output contract: states clearly whether this touches your work
Tools	An all-purpose Bash and free rein	Deterministic operations locked down into purpose-built tools, one at a time
Permissions	Ship the full set, aim for "can do anything"	Delete Bash, aim for "can't do anything dangerous"
Hooks	Trust the model's discipline for critical steps	Welded down in code at fixed lifecycle points
Plan Mode	Just switch to the SDK's native plan mode	Never switch modes — reuse an existing approval callback to intercept instead
Subagent	Let subtasks contaminate the main context	Isolate the noise, converge understanding back to the main agent

The model is a commodity — anyone with a budget can call it. What's actually different is these dozen-plus decisions, each one tailored specifically for a writing context. Not one of them is a universal formula — every single one was ground down, gradually, against the actual shape of the business. A vertical agent's moat was never about how smart the model is — it's about whether you're willing to hand-craft "subtraction and customization" at every single point of friction, for your own business specifically.

🧭 If You Want to Embed an Agent Into Your Own Business Too

Having covered "where it's different," I want to close with "how you actually get there." The point of writing this series was to record my own thinking and learning, but there was a bit of self-interest too — I wanted to pass along what I'd picked up to anyone walking a similar path. If you're also trying to embed a generic agent into some vertical use case of your own — writing, customer support, legal, whatever it is — I hope the "methodology" I've worked out here saves you a few of the detours I hit. Broken down, it's 4 steps:

1. Take it apart: don't rush into writing code. Break the "harness" down into individual mechanisms (engine, memory, steering, interaction, orchestration, business) and get a clear picture of what parts you're actually working with.
2. Judge every layer, one at a time: for every mechanism, force yourself to ask, "does the generic default actually fit my use case? What needs adding, and what needs to be cut without mercy?" The granularity of this judgment call is what decides whether the end result is genuinely "grown into the business" or just "a wrapper."
3. Assemble it: string the mechanisms you've judged and adapted into a workflow that matches your actual business, letting them work together end to end.
4. Translate it into an interface: the last mile — take this precise, opaque machine and translate it into something your users (who may know nothing about "agents") can understand at a glance and use with ease.

Of these four, my own experience is that step 2, judging every layer, is the one that matters most. "Just another generic agent" is, more often than not, the result of skipping that layer of thinking and swallowing the defaults whole. It's worth spending real time on — the payoff is genuinely worth it.

🎬 A Carefully Built "Wrapper" — How I've Come to Make Peace with the Word

Fifteen posts of detours later, the methodology's laid out — time to circle back to the question this whole thing started with: my friend's offhand comment, "so, is this just a wrapper?"

My answer now is a lot more settled. I don't object to the word "wrapper" anymore — I'd just add two words in front of it: carefully built. Because this "wrapper," from the self-driving heartbeat at its very core, all the way out to the interface muting and translating everything for the user at the surface, is real, substantive work at every single layer — decisions re-cut, specifically, for this one thing: writing.

That said, agent products as a category are still evolving fast. This series, at best, is an honest record of one personal project, at one particular slice in time. Some of what's in here will probably age out before too long, and that's fine. But every mistake documented here, I actually made; every tradeoff, I genuinely weighed before committing to it. If it saves you a detour while building your own product, or just gets you to pause and ask yourself once, "is this one really worth copying the default on?" — then these fifteen posts did their job.

Thanks for reading this far. See you at the next vibe-coding session. 🌈