I ended up with a twelve-panel comic, and not long after I was building Memolio.

This week I found out it won a prize. Thank you to Tirol 2050 for picking it, and to Gloryfy for the indestructible sunglasses that came with the win. As a deeply messy and unorganised person, I am intent on testing them to their limits!

I want to talk about what happened between sitting down with a single image in mind and ending up with a sequence, because I think it’s a pattern worth naming.

The original prompt was already loaded. An old man in traditional Austrian ‘Tracht’. Children at his feet. A 1950s retrofuturist palette. Solar panels glinting off alpine farmhouses. I fed it all in and got back a perfectly competent image. It was fine. It was also flat.

What was missing wasn’t quality. The model can render Tracht and solar panels just fine. What was missing was meaning. The image didn’t say anything. It didn’t have a beginning or an end. There was no question being asked and no answer being given. It was a tableau.

So I added a second panel. Then a third. Then I kept going. By the time I stopped I had twelve. Electric trams and buses threading green city streets. Cable cars climbing from town centres to mountain peaks. Mountain villages alive again because energy is nearly free. Cows resting in the shade of solar canopies. Near-free electricity moving like water from a mountain spring. Summer water pumped up to reservoirs so families could keep warm with the people they loved in winter. Eleven panels of patient build. Then the twelfth: a small child looking up at the old man and asking, “But why did you do it?” And the old man answering, “Why? Why not?”

That last exchange is the entire point of the comic. There is no single image in the world that contains it. The question only lands because eleven panels have already painted the world the question is being asked about. The answer only lands because you’ve already started caring about the old man. You need the build, the pause, and then the punch.

That was where I had a quiet realisation that has shaped the last six months of my life.

Single prompts are a one-frame medium. They can be beautiful, evocative, sometimes startling. But they are structurally unable to carry an arc. The model does not know what came before and does not know what comes after. The viewer has to do all the editorial work in their head, and most viewers won’t.

Narrative is the unlock. A handful of pictures and a handful of words in sequence can do what no single generation can. They can hold a question over a beat, then answer it. They can age a face across pages. They can let a grandfather be a child first, before he is anyone’s grandfather.

After the competition I started sketching what would become Memolio: a workflow that turns a grandparent’s life into an illustrated book. The product is built on the same insight as that twelve-panel comic. It isn’t really in the business of generating beautiful single images, although it does that as a side effect. It’s in the business of stringing them together into a story that means something to one specific family.

The Tirol 2050 brief was about renewable energy. The lesson I took away was different and, for the thing I’m building, more useful. AI gets interesting the moment you stop asking it for an image and start asking it for a story. The output is no longer something you look at. It’s something you read.

That shift, from looking to reading, is the entire game.

Safe to touch: most of it. Change a prompt, adjust a parameter, add a new branch. The workflow does what you'd expect. If something breaks, it usually breaks loudly.

Not safe to touch: a handful of specific Code nodes that I've come to call trouble nodes. These don't break loudly. They break silently, in a way that produces no error and no warning, and that you only discover days later when a tester reports that something is subtly wrong with their book.

Learning where these nodes live, why they behave the way they do, and how to build a working system around them has been one of the more useful engineering lessons of building Memolio, a personalised illustrated book for grandparents.

What Makes a Node a Trouble Node

The pattern is specific. A trouble node is a Code node that rebuilds its output by explicitly listing every field it wants to forward downstream, rather than using a spread or destructuring. Something like:

return {

book_id: input.book_id,

grandparent_name: input.grandparent_name,

birth_year: input.birth_year,

// ... 15 more lines

};

This exists for legitimate reasons. You don't want every piece of upstream data blindly propagating through your entire pipeline. At certain boundaries, you want to be deliberate about what flows forward.

The problem is that "deliberate" becomes "frozen." Every time you add a new field anywhere upstream of a trouble node, that field hits the explicit list, finds its name isn't on it, and disappears. Silently. The node doesn't throw an error. The next node down doesn't know to ask for the missing field. The failure is invisible until something downstream tries to use it.

The worst part is the pattern of discovery. You add a new intake question in Typeform. You wire it through the mapper. You test the mapper output and the field is there. You fire a test run and everything looks fine. Two weeks later a tester points out that a certain piece of their book is wrong, and you trace it back and find that the field died at a trouble node four hops back. The silence is the feature that makes it dangerous.

The Nodes That Keep Biting

In Memolio's workflow, the mapper is the most consistent offender. The mapper is the node that takes raw Typeform responses (or WhatsApp intake data) and transforms them into structured fields the rest of the pipeline can use. It's a complex node: it handles two intake channels, two languages, dozens of question variants, and months of accumulated edge cases.

Whenever I change a question in Typeform or WhatsApp, two things have to change: the question itself, and the mapper. If the question changes and the mapper doesn't, the field comes in with a new wording, the mapper's pattern match fails to recognise it, and it emits null downstream. No error. The field just isn't there.

This has happened several times. The mapper is a trouble node not because it hand-picks output fields in the same way as the others, but because it has an implicit field list baked into its getField() pattern matchers. Change the question wording and you've implicitly removed that field from the list.

The other consistent offenders are Prepare Book Recipe Data in WF1 (which writes the questionnaire to Supabase), and Parse Sanitized Data and Parse Story Pages (which re-emit per-page objects after LLM processing). These are all explicit hand-pick nodes. Add a field anywhere in the intake and there's a high chance it reaches one of these and stops.

The System I Built to Handle It

The first thing I did was name them. Every trouble node now has a prominent comment at the top of its code:

// TROUBLE NODE - HAND-PICK FIELD ENUMERATION

// This node explicitly lists every field it forwards.

// If you add a field upstream, add it here too or it will be silently dropped.

This sounds trivial, but it's not. When a node has that header, it becomes searchable. I can grep for TROUBLE NODE across every workflow file and immediately find all the places that need updating when I add something new. The header turns a hidden architectural constraint into a visible one.

The second thing I did was create a Claude skill that enforces the update pattern. When I'm making a change to any intake question — in Typeform EN, Typeform DE, or the WhatsApp chat engine — the skill prompts me to:

1. Update the question in the intake surface

2. Update the mapper's pattern matchers for both language variants, keeping old variants as fallbacks (historical intakes still need to parse)

3. Grep all workflows for TROUBLE NODE and check each node in the field's path

4. Add the field to every trouble node it flows through

5. Add the field to the consumer that actually uses it

6. Run an end-to-end smoke test and verify the field arrives at the consumer

The skill doesn't do the work for me. It's a checklist with context: it knows which nodes are trouble nodes, it knows the mapper has both EN and DE variants, and it knows that adding a field without updating the mapper is how we've lost data in the past.

The thing about working with AI on a complex workflow is that the AI doesn't know your architecture the way you do. I can ask Claude to add a field to the pipeline, and Claude will do it correctly at the points it can see. But it won't automatically know that Prepare Book Recipe Data needs to be updated, because that's not obvious from the code — it's institutional knowledge about which nodes are dangerous. The skill is how I've encoded that knowledge into the collaboration.

The Meta-Lesson

This is really about the gap between "works in the happy path" and "works when things change."

Any automation workflow has nodes that are fine to touch and nodes that require a ritual. The mistake is not documenting which is which, because the cost of the mistake is invisible for a long time and then suddenly very visible when a tester notices something wrong.

What I've landed on is a simple principle: if a node has an implicit or explicit field list that doesn't automatically inherit from its input, it needs to be named, documented, and covered by a checklist. The effort of maintaining the list is trivial. The effort of finding a silent data-drop bug weeks after it was introduced is not.

Building with AI tools accelerates a lot of things. The thing it doesn't automatically accelerate is the accumulation of structural knowledge about your own system. That part is still yours to do.

If you're building workflows in n8n, or anything with explicit data transformation nodes, I'd be curious whether you've hit a similar pattern and how you've handled it. The trouble node convention is working well, but I suspect there are better approaches I haven't thought of yet.

Follow the build on Substack. And if you have a grandparent whose stories deserve to be preserved, Memolio is getting close.

Memolio builds personalised illustrated books for grandparents, crafted from real memories.

My mother-in-law looked at her illustrated book and her reaction was immediate. Not “oh it’s lovely” and not “I have some notes.” Just: “I look frumpy.”

I found it funny, honestly. It wasn’t the kind of feedback I was expecting from a user test. But then my wife looked over her shoulder and agreed. And at that point I stopped finding it funny and started paying attention, because two people who know this woman well had the same reaction to how the AI had drawn her.

I went back and looked at the code.

The problem was hiding in plain sight

Every grandparent in every Memolio book — regardless of their actual age, regardless of anything the user had told us about them — was being described to the image model as “an elderly woman” or “an elderly man” in “age-appropriate casual clothing.”

Those two phrases together. That’s basically a prompt recipe for someone hunched in a cardigan.

The “how did I not see this” feeling hit pretty hard. I’d been so focused on getting the faces right, the illustration style consistent, the story prompt producing the right scenes, that I’d never stopped to think about what the model was actually being told about how this person dressed. It had never been an explicit decision. It was just a default that crept in, and I’d never questioned it.

The thing is, I had an image of “older people” in my head that came from my own grandmother. Her generation. Her clothes. And I’d just... baked that into the product without realising it.

A generational shift I’d completely missed

Here’s the thing about someone who is 65 or 70 right now: they grew up in the 60s and 70s. For a lot of people that age, fashion wasn’t just something they wore. It was a core part of their identity. They had a look. They had opinions about it. Some of them still do.

The “age-appropriate casual clothing” default had no way of knowing that. It was treating every grandparent as a generic category of person rather than as an individual who has spent decades figuring out how they want to present themselves to the world.

The fix was straightforward once I saw it: ask the user. What’s this person’s clothing style? We added a simple preference input — smart and polished, casual and relaxed, sporty, artistic, that kind of thing. Now a woman in her late 50s who describes herself as “smart and polished” gets illustrated in tailored trousers and crisp shirts instead of shapeless knitwear. Four files, about thirty minutes of work. The kind of change that probably matters more to customer satisfaction than anything else I’ve shipped this month.

But the real lesson is bigger than the fix

What I keep coming back to is how the model ended up with those assumptions in the first place. It didn’t make up “elderly in age-appropriate casual clothing” from nowhere. It learned from images. And images, across decades of media and stock photography, have a very specific idea of what an older person looks like. Dignified. Soft. Comfortable. Sensible shoes.

AI reflects the assumptions baked into the culture that produced the training data. That’s obvious when you say it out loud. It’s much less obvious when you’re in the middle of building something and just trying to get a feature to work.

This is why talking to actual users matters so much. Not surveys, not analytics, not me reviewing test books on my laptop. My mother-in-law looking at a picture of herself and saying “I look frumpy” is information I could not have generated any other way. My blind spot about what “older” looks like is a human blind spot, shaped by my own experience. The model has the same blind spot, at scale, shaped by decades of the same cultural assumptions.

The only way to find those gaps is to put the thing in front of real people and let them tell you what’s wrong.

The harder problem is still ahead

The fix I shipped is good but not complete. Asking people to describe their clothing style works when they have a clear sense of their own aesthetic. A lot of people don’t, or they describe themselves in ways that don’t map cleanly onto what the image model thinks “smart casual” or “artistic” looks like. Most people don’t neatly fit into a box.

The ideal version of this is probably more granular: specific items, specific eras, specific references. But that’s a longer form to fill in and a harder prompt to write. For now, having any preference at all is a massive improvement over a universal cardigans-for-everyone default.

Small change. Meaningful impact. One mother-in-law who might now look like herself in the book her family is making for her.

If you’re building something where AI has to represent real people, I’d genuinely like to know how you’re handling this. It feels like an unsolved problem across a lot of products. Drop a reply or find me on the blog.

And if you have a grandparent whose story deserves to be told, join the waitlist for early access when Memolio opens up properly: https://blog.memolio.io/subscribe

Memolio creates personalised illustrated books for grandparents from real memories and photos. Not yet publicly purchasable. Join the waitlist: https://blog.memolio.io/subscribe

The problem itself was boring: I’d deployed a small AWS Lambda to process PDFs as part of our book printing pipeline. It worked perfectly when I tested it inside the AWS console. The moment I called it from anywhere else — my own computer, our automation tool, anywhere that wasn’t the console itself — it returned 403 Forbidden. Locked out by its own configuration.

Claude’s suggestion was confident and clear: “Just re-add the permission, it’s a 2-minute fix.” I did. It didn’t work. “Try deleting the old permission first, then re-adding it.” I did. It didn’t work. “Let’s use the CLI instead of the console.” I did. It didn’t work. Every fix came with the same breezy certainty, and every failure was met with a new suggestion delivered in the same breezy certainty.

At some point I noticed something that should have been obvious from the start: we were going in circles. Claude wasn’t tracking what had already failed. It was pattern-matching each new attempt to a different prior problem, confidently prescribing solutions that I had already tried, sometimes twice. I was the memory. I was the thing keeping the debugging session coherent, and I was terrible at it because I was tired and it was 1am and I wanted to go to bed.

Eventually I got genuinely annoyed and typed something I don’t usually type at a computer:

“you really need to get better at recording what HASNT worked when debugging because we are just going round in circles”

That single sentence flipped the entire session.

What changed when I forced the step back

Claude wrote a file called DEBUG_403.md. Inside it: every attempt, every result, every hypothesis still alive. It read the actual error messages character by character instead of skimming them. It did a proper web search. And within about ninety seconds it had the real answer.

Turns out AWS quietly changed how Lambda Function URLs work in October 2025. They used to need one permission (lambda:InvokeFunctionUrl). They now silently require two (lambda:InvokeFunctionUrl AND lambda:InvokeFunction). If you only have the first one, every public request returns 403, forever. The AWS console had actually been telling me this the whole time — there was a little blue banner explicitly stating both permissions were needed. I read it nine times over the course of the debugging session. Claude generated a response to it nine times. Neither of us actually understood what it said, because we were both too busy pattern-matching to similar-looking past problems.

The fix was one CLI command.

The thing I keep relearning

I’ve been working with AI coding agents intensively for almost a year now. I build Memolio almost entirely with them — most days I don’t write code directly, I describe what I want and review what comes back. And I keep learning the same lesson in different forms: AI agents will loop on an approach forever if you let them. Sometimes the most valuable thing a human can do is force a step back.

It’s tempting to read this as “AI is unreliable, don’t trust it.” That’s not quite right. Claude wasn’t being lazy or malfunctioning. It was doing what large language models do: generating the next most plausible response given the state of the conversation. The problem was that the state of the conversation kept looking like a problem it had almost-seen-before, and “almost-seen-before” is a bad foundation for debugging something you haven’t actually seen at all.

What the model needed was a different kind of context: not more suggestions, but an enforced structure. A file on disk listing what had been tried. A requirement to read the error message literally before guessing. A rule that says “on the second failed attempt, stop guessing and start researching.” None of this is beyond the model’s capabilities — it did all of it brilliantly once asked. It just wouldn’t do it on its own.

I think this is the actual skill of working with AI agents in 2026. Not prompt engineering. Not picking the right model. Not even building clever evaluation loops. It’s knowing when to interrupt. Knowing when the confident-sounding next step is actually the fourth iteration of the same wrong step, dressed in different words. Knowing when to stop letting the machine drive and make it justify itself.

When I did that last night, Claude wrote me a memory file — literally, a permanent note to its own future sessions — called feedback_record_what_hasnt_worked.md. The rule: “On the second failed attempt at any fix, stop guessing. Create a debug log. Read error messages literally. Do proper research before suggesting more button-clicking.” It will remember this next time I start a new session. I don’t know if that’s exactly what machine learning researchers mean when they talk about AI that learns from feedback, but it felt like something.

The thing that actually shipped

Oh, right. The Lambda works now. The entire print pipeline for Memolio is automated end-to-end for the first time. When a grandparent finishes their WhatsApp interview and approves their book in the review page, everything from “interview complete” to “physical book printed and shipped” now runs without a human touching it. A webhook fires, PDFs get generated, the Lambda adds the tiny invisible printer metadata that commercial presses require, real MD5 hashes get computed, the order lands in CloudPrinter’s system, and forty-five seconds later there’s a confirmed sandbox order waiting to go.

And it happened in ninety seconds once we stopped pretending we knew the answer.

Memolio turns a grandparent’s stories into a personalised, illustrated book — captured over WhatsApp, illustrated by AI, printed and shipped in hardcover. We’re currently in closed user testing. If you want early access or just want to follow along as we build, you can reply to this email or sign up at memolio.io.