TL;DR: A prompt that worked once is not a workflow. On this site, repeated editorial work turned into named procedures carrying their own caps, order of operations and refusals, and that shift did more for output consistency than any improvement in the underlying model. The comparison to journey orchestration is useful at design time and misleading at runtime, and it is worth being precise about which.
Every organisation I work with can do the impressive thing once. In a workshop, with the right people in the room and a deadline that ends on Friday, almost any team can produce a genuinely good campaign brief, a clean segment definition, a journey that reflects real customer behaviour. The problem has never been the first one. It is the fortieth, produced four months later by someone who was not in the room, under time pressure, when the person who knew why the rules existed has moved to another account.
Agentic tooling reproduces this exactly, at a smaller scale and a faster clock. The first article I produced with a well-crafted prompt was good. The fifth was good in a slightly different way. The twelfth had drifted far enough that a reader following the series would have noticed, and I was the reader.
The first two parts of this series covered what an agentic operation actually consists of and how it fails silently. This one is about the layer that sits between those two, which is the set of named procedures that turn a set of intentions into something a stranger, including a future version of the system with no memory of today, can execute the same way.
The third time you write the same instructions
The threshold I use is unglamorous. The first time I explain how a weekly issue gets built, that is a conversation. The second time, that is a coincidence. The third time, the instructions are a thing in their own right, and they should live in a file rather than in my typing.
A procedure declares its inputs, so it is unambiguous what file it operates on. It declares what to read before starting, which on this site means the bio file, the writing rules and the most recently published issue as a structural template, plus a couple of recent graphics so the visual system stays consistent.
It states which questions to ask the operator and, more importantly, which ones to infer rather than ask, so the session does not open with six clarifications I have already answered nine times. It has an order of operations. And it has conditions under which it stops.
That last property is the one that took me longest to appreciate. A prompt has no failure state. It produces something, always, and the something is shaped by how carefully I happened to write that morning. A procedure can refuse.
Step zero, and why order of operations decides quality
The Weekly MarTech Signals procedure begins with the length cap, and it begins there for a reason that generalises well beyond publishing.
The series had settled at about 2,030 body words across thirteen consecutive weeks, which was the right size for what it does. Then Part 14 ran to 3,347 words and Part 15 to 4,345 before it was cut back. Nothing had changed in the instructions. The drift was gradual, invisible week to week, and obvious across a quarter, which is how every scope problem I have ever seen in a client engagement behaves.
The interesting part is the diagnosis. My first assumption was that sections had got longer, and that a cap on words per section would fix it. The data said the opposite. Part 14’s longest section ran to 343 words, shorter than in every earlier issue but one, and it still doubled in length, because it had eleven sections where a settled issue has five or six. Section count was the variable driving everything, and words per section was a derived number that had been swinging harmlessly between 260 and 410 for months.
So the cap is eight H2 sections as a hard limit and 3,000 body words as a second hard limit, with a target around 2,400 and an explicit allowance for one lead section to run long, because every good issue in the series has one section carrying the week’s main argument surrounded by shorter ones. A flat per-section cap would have destroyed that shape while missing the actual failure.
And the check runs on the outline, before a word of prose exists. Section count is knowable at outline time, which is the earliest possible signal. A total word count is only knowable at the end, and enforcing a limit at the end turns into shaving adjectives out of finished paragraphs, which is not editing and produces text that reads like it has been through a compactor. Putting the control at the earliest point where the variable is visible is the whole design decision, and it is the same argument I would make about validating a data contract at ingestion rather than reconciling in the reporting layer.
The measurement rule is equally boring and equally necessary: strip markdown before counting, because a naive word count over-reads these articles by seven or eight percent on image alt text and source URLs alone. A control that measures the wrong number is not a control.
Caps beat adjectives
“Write concisely” is not a control. It is a hope, and it will be interpreted differently by the same system on two consecutive Tuesdays depending on how the source material happened to read. “Maximum eight H2 sections, excluding Sources” is a control. It is checkable, it is checkable early, and it does not degrade when I am tired.
The clearest case on this site is the infographics. I rejected an entire set in July on the grounds that they were, in my exact words at the time, really too much. The rejected graphic explaining protocol scope had 56 text elements and 293 words on one canvas, which is not a graphic, it is a second reading of the article rendered in boxes. The accepted rebuild had 24 elements and 103 words. Those two numbers became the calibration, and the rule that came out of it is a hard ceiling of 27 text elements and 195 words, with an aim of 16 to 24 elements and 90 to 120 words, plus specific structural limits: one kicker and one title, two to four content cards, no nested boxes inside cards, exactly one closing callout.
Every one of those is a number or a count. None of them is a judgment I have to re-form each week. And there is a detail in that rule I like more than the rule itself, which is that when a graphic gets trimmed the alt text has to be trimmed with it, because the alt doubles as the visible caption in these series and describing elements that are no longer on the canvas is its own small lie. Heroes are exempt from the ceiling entirely, because a cover image is doing a different job.
That is the shape of every good constraint I have written here. A number, a scope, and an explicit exemption so nobody has to guess.
The refusals are where the design actually lives
Read the procedures on this site for what they automate and you come away with a misleading picture, because almost all of the design decisions in them are about what they are forbidden to do.
The internal linking procedure scans the corpus and proposes links in both directions, the ones a new article should carry and the ones existing articles should point back with, and then it stops. It never inserts anything. Every suggestion is approved individually, because internal links are load-bearing for how the site is understood by both readers and crawlers, and a plausible-looking link between two articles that are not really about the same thing is worse than no link. It also carries a rule that Italian articles link only to Italian articles, which sounds obvious until you watch a system helpfully connect an Italian reader to an English destination.
The newsletter procedure creates a draft and only a draft. Sending and scheduling both require me to say so explicitly and confirm a date and time, and the default arguments in the script make the safe path the lazy path. That is deliberate, because a default that requires vigilance is not a safeguard.
The Medium procedure has two refusals in it. It publishes a truncated teaser with a canonical link home and never the full text, which is a positioning decision about not competing with my own site for my own headlines. And it never deletes a Medium post under any circumstance, because the canonical tag on those posts is currently what tells Google which version is the original, and deleting the post destroys that signal. Truncate, always. The reason that rule is written into the procedure rather than held in my head is that the tempting action, cleaning up an old duplicate, looks like good housekeeping right up to the moment it costs you the attribution.
Every one of these gates makes the system a little less capable and considerably more deployable, which is a trade enterprise buyers have been rediscovering in every agentic pitch cycle this year. I made a version of this argument about where human judgment stayed irreplaceable in the second part of the Braze demo write-up, and the months of steady use since have only sharpened where I would draw the line.
Where the orchestration comparison holds, and where I would stop making it
It is tempting to describe all of this as journey orchestration for editorial work, and there is enough truth in that to be dangerous.
The parts that genuinely correspond are design-time parts. Naming a reusable unit of work rather than rebuilding it each time is the same instinct that produces a canvas template instead of forty hand-built journeys. Declaring the inputs a unit expects is the same discipline as defining the events and attributes a journey depends on, and it fails the same way when it is skipped. Putting the approval gate inside the artefact, so it travels with the thing rather than living in the memory of whoever built it, is exactly what a well-designed journey template does with its exit criteria and its frequency caps. And versioning the procedure so that a change is visible is the same reason nobody sane edits a live canvas in production.
The parts that do not correspond are all the runtime parts, and they are the hard ones.
A journey runs concurrently against millions of profiles, with state per profile, race conditions, timing windows and the constant possibility that the same person qualifies for three things at once. My procedures run once, sequentially, for one operator, against one file. A journey has multi-team ownership, which moves the real work into the negotiation between brand, CRM, legal and whoever owns the data contract. My rules were negotiated with nobody. A journey carries regulatory exposure through consent, preference and retention, and my worst outcome is a sentence I have to correct after publication. And a journey is measured against outcomes that arrive weeks later through an attribution model everybody in the room distrusts, where my feedback loop is me reading the thing on Friday.
So the honest position is that this is a good analogy for how to structure agent work and a poor one for estimating how hard the enterprise version will be. Anyone selling agentic orchestration on the strength of a single-operator demo is showing you the design-time half and quietly charging for the runtime half.
What survives a model change
Which brings me back to the argument I have been making about platforms for twenty-five years, and which building this operation has tested on something I own.
Everything described across these three articles is written in formats that outlive their tooling. The context files are markdown. The integrity check is a few hundred lines of Node that any runtime can execute. The procedures are prose with a declared order of operations and a set of numbers. The memory is a folder of small text files with an index. If the model underneath changed tomorrow, or the tooling around it, the substrate would need reconnecting and none of it would need rewriting, because none of it encodes anything about the model.
That is the same claim I make when a client asks me to compare two customer engagement platforms and I spend the first hour talking about their identity model instead. The vendor layer is the part that changes. The layer that determines whether the thing works in month five is the one that describes what you are doing, in what order, with what limits, and where you have decided the machine must stop and ask.
Platforms come and go. The architecture wins, and it turns out to win at this scale too, on a personal website with a readership I could fit in a meeting room.
There is a ceiling on all of this, and all three of these articles have hit it in the same place. Everything described here was negotiated with nobody. One operator, one workspace, one set of rules that never had to survive a disagreement, and in any organisation that negotiation is the work. The moment a second person can trigger the same procedure, a different set of questions opens: who the agent is acting as, what it is allowed to do while wearing that identity, whose policy wins when two of them conflict, and how anyone reconstructs afterwards what it did and on whose authority. None of those exist at the scale of one person, which is exactly why this series stops here. They are the subject of the next one.
Sources
Anthropic
- Introducing Claude Skills. The packaged-instruction format the procedures described here are written in.
Platform documentation
- Medium, API documentation repository. Archived, which is why the cross-posting procedure runs through a browser session rather than an integration.
