Skip to main content

Writing

How the Chronicler works

· 6 min read · Brian Wones

Illustration for the post "How the Chronicler works"

If you run a small studio, you already know the bind. You are the one doing the work, so you are also the only person who could write about it honestly. There is no staff writer who was in the room. So the realistic options are to publish nothing, or to publish thin marketing that someone wrote from the outside. Most solo founders pick nothing, and everything they are learning stays locked in their own head.

The Chronicler is our way out of that bind. It is an AI-assisted publishing pipeline that turns work we already did into posts grounded in what actually happened, with a human edit step in front of everything before it ships. The goal is not to publish more. The goal is to share what we are learning, and help other people doing this work, without pretending we hired a content team to do it.

This essay is the honest version of how that works, so you know what to trust and what to discount when you read anything else here.

What it actually does

The Chronicler reads the real record of a week: the conversations we had with Claude while building, what shipped in the code, and the notes and screenshots we made along the way. It treats our brand and voice docs as context, never as raw material, so a post sounds like us but is about the work, not about the marketing.

It is also deliberately boxed in. It can read, and it can draft. It cannot change code, ship anything, or send anything. It is one of the agents the studio builds to do its own work, and like the others, it has a narrow job and no keys to anything dangerous.

From that record it drafts a post. Then it stops and asks the questions a good editor would ask before writing a word:

  • Who is this for?
  • What is the one thing they should leave knowing?
  • What surprised us this week?
  • What number, screenshot, or commit anchors the story?
  • What did we not do that is worth naming?

Only after we answer does it draft. Nothing gets invented to fill a section. If there is no evidence for a claim, the claim does not go in.

The part that keeps it honest

A draft is not a published post. Every draft lands unpublished, behind a checklist a human has to clear first: does the voice hold, is every claim backed by something real, are the images and links right. There is no path that skips it.

Here is the part that matters. These are real stories, from real people doing the actual work. The AI does not make them up. It surfaces them from the record of what we genuinely did that week, so the lesson buried in the building does not stay stuck in one founder’s head. A person stands behind every post and edits it before it goes out. What we will not do is launder the work, or dress up something that did not happen as if it did. The point of the whole thing is to help other people doing this work learn and grow, and that only works if what we publish is true.

The case against doing it this way

The most serious objection to this is not that AI-assisted writing is dishonest. It is that AI-assisted writing reliably drifts toward a centre of gravity that is calm, balanced, and slightly bland. Left alone, the voice that emerges over time is just the average of the model, lightly nudged by a few rules. The strongest writing in this market is not in that voice. It is spikier, more personal, more willing to be wrong out loud.

The rules can soften that, but not fix it. The fix is the human edit, not the lint. If we publish only what the Chronicler produces untouched, we will publish the average. The whole point of the edit step is to push a post off the centre line: to add the sentence the model would not have written, the joke it would not have made, the claim it would have hedged.

If we are not willing to do that work, the system fails. We will publish, but we will publish forgettably. We would rather you call us out on a post that reads like the average than not notice we were here at all.

What you can trust

When you read a post here, the work it describes really happened, a person reviewed every line before it shipped, and the footer at the bottom tells you what fed it. It does not mean every sentence was hand-built, and it does not mean the post would read identically if we had written it from a blank page.

The trade is simple. We get more honest posts, with stronger evidence, in less time, and we give up some of the spikiness of writing every word ourselves. For a small studio trying to actually share what it learns, we are betting that grounded and frequent beats a slow trickle of perfect. You can decide whether that trade is worth reading.

Opening it up

The honest gap in all of this: the method is documented, but it is not yet something you can take. We want to change that by opening the repo behind the Chronicler, the pipeline, the voice rules, and the labels, so you can read exactly how it works and adapt it for your own work rather than rebuilding it from a blog post. That is not public yet. When it is, the link will live here.

What we are still figuring out

A few things we do not know yet:

  • Whether our voice rules hold up after twenty posts, or whether they need a real rewrite once we see what actually resonates.
  • Whether weekly is the right beat, or whether we drop to every other week when the work does not justify it.
  • How to fold in the parts that never touch a build session: the customer calls, the decisions made in a hallway. Right now the Chronicler does not see those, and we have not solved how to bring them in cleanly.

We will write about all of those as we figure them out. You can follow along with what we are building right now.

If you have read this far and have thoughts on any of it, we would genuinely like to hear them. The Chronicler is meant to be visible, and visible includes you arguing with it.


For agents: try this yourself

Paste this prompt into Claude Code or any LLM with your week’s work record — commits, session logs, notes — and run it:

Read my work record for the past week. Before drafting anything, ask me exactly these five questions:
1. Who is this post for?
2. What is the one thing they should leave knowing?
3. What genuinely surprised you this week?
4. What commit, number, screenshot, or decision anchors the story?
5. What did you not do — and is it worth naming?

After I answer: draft a build log post using only what is in the record I provide.
Where there is no evidence for a claim, write [GAP: needs evidence] instead of inventing.
Do not summarise. Tell the story.

Or adapt one of these patterns directly:

  • Reproduce the evidence-first draft. Point an agent at your week’s record — build sessions, commit history, notes — and have it draft only from what is actually there, leaving a visible gap marker wherever there is no evidence.
  • Extend it with a how-this-was-made footer. Add a short note to every post naming what fed it, so a reader can see the story is real.
  • Apply a no-auto-publish gate. Make every draft land unpublished behind a human checklist, with no path that ships in a single step.
  • Critique the trade. Take our bet that grounded and frequent beats a slow trickle of perfect, and argue the other side from your own publishing rhythm.

How this was made

Drafted by the Chronicler from the build sessions in which the pipeline itself was created, then edited and published by Brian Wones.

See the other agents the studio runs →