The System I Was Already Selling

A few weeks ago I wrote about the week I chose to fix the foundation instead of shipping a feature — separating conversation from turn, giving every LLM call somewhere real to live instead of storing it as an isolated snapshot. That decision is what made this next part possible to even notice.

This time the gap wasn't in the foundation. It was in a feature that helps me write LinkedIn comments — and getting that feature wrong has a real cost. Commenting is where a lot of the relationship- building and thought leadership actually happens for me. A comment that reads generic doesn't do that work. And if I have to rewrite every draft from scratch by hand to make it personal, the tool isn't saving me anything — I'm just doing the writing twice.

To be clear about what that means: the tool drafts candidates. I still decide what's worth saying, and I rewrite until it's actually mine. What follows is about why that process kept falling short of that — not about outsourcing the writing.

The first version of this feature wasn't turn-based. The flow was: say what resonated with me about a post, get a handful of candidate comments back, and pick one. The candidates were genuinely good — well-argued, on-topic, in my voice at the level of ideas. What they consistently missed was the personal story, the specific detail that makes a comment sound like it came from someone who actually lived through the thing being discussed, not just someone who agrees with it.

That's a real gap, and there was no way to close it inside the tool. I could pick the best of the candidates, but I couldn't say "this is close, now let's get the personal part right" and have it actually iterate with me. So every time a candidate needed that missing layer, I was back to hand-editing outside the loop the tool was supposed to provide — the exact thing that makes an AI-assisted feature not worth having.

Fixing it meant giving the feature what the earlier foundation work had made possible: turn-based storage, so a comment could actually be refined across several exchanges instead of regenerated from nothing each time. That solved the backend half of the problem. The interface still needed to be rebuilt to actually expose that interaction — storage that supports iteration doesn't help if the screen in front of you still only shows one shot.

So I rebuilt the interface around a timeline instead of a single response — every turn, what was asked and what came back, laid out in order, editable and re-enterable at any point. That's what let me actually work a comment toward the personal detail it was missing, turn by turn, instead of regenerating and hoping.

It also surfaced a problem I hadn't had to deal with yet: once you can have a real back-and-forth, you naturally start asking it things — why did you phrase it that way, what's this angle missing — and a system built to always answer in one fixed, structured shape has no good way to handle that. It either forces the question into fields that don't fit, or answers it as if it were a new instruction to revise the draft. Either way, the answer you get isn't the answer you asked for, and you lose trust in the tool exactly at the moment you're trying to lean on it more.

The fix was one flag, two modes. Structured is the system acting on my behalf — something to render, store, build on. Chat is me interrogating the system — why did you decide that, without disturbing what it already decided. The mechanism is simple. What it replaced wasn't: without it, iterating on a comment meant fighting the schema as much as improving the draft, every time.

What made this worth writing about wasn't the fix. It was what the fix was actually made of: partial structured input from the interface, and a response, laid out together on a timeline the frontend renders the same way every time.

I'd built that shape solving one feature's very specific problem — getting a personal comment right through iteration. It turned out to be exactly what the commercial drafting feature needed too, built completely separately, with its own reasons for existing. And then it turned out to be what the contact notes summarizer needed as well — a feature I'd shipped earlier, on a different data model, a different API shape, different UI components entirely, with no relationship to the other two beyond both involving an LLM call.

Three features. Three different data models, three different APIs, three different sets of UX components, each built to solve its own specific problem. Once all three were working reliably enough that I could stop firefighting and actually look at them side by side, what had emerged wasn't three unrelated solutions. It was the same shape, independently arrived at three times, because it's what a reliable, explainable interaction with an LLM actually requires — regardless of which feature is doing the asking.

Three different features didn't need three different answers to the same question. They needed the same answer, because it was the same question the whole time — I just hadn't recognized it as one question yet.

Here's the part I didn't expect to be writing. Trustable AI output and explainable AI behavior are literally what I tell clients their production systems need to take seriously. I hadn't taken it that seriously in my own tool. I built the comment feature, then the drafting feature, then the notes summarizer, the way you build things when you're moving — pragmatically, one working thing at a time, solving whatever was in front of me.

I want to be precise about what actually happened, because it isn't "keep iterating and eventually you arrive at explainable, trustable AI." That's not what this is. The first version of the comment feature got iterated on plenty — different prompts, different phrasing, different candidates — and it never got more reliable, because the thing wrong with it wasn't the prompt. It was the structure underneath: no turn history, no way to separate a question from a directive, no representation of what had already been decided. No amount of iterating on the surface was going to fix a gap that lived in the foundation. Reliability didn't arrive because I iterated harder. It arrived exactly when, and only when, I made the structural change — the same kind of change I tell clients to make on purpose, that I'd made here without quite admitting that's what it was.

I sell explainable, trustable AI as something production systems can't afford to skip. I hadn't required it of my own tool on purpose — but every time a feature actually became reliable, it was because I'd finally done exactly that. Iteration never got me there on its own. The principle did, whether or not I was calling it one at the time.