TL;DR: Vendor agentic demos show one task finishing in one session. What determines whether an agentic operation survives is what it looks like on month five, and by then almost none of the work is prompting. It is a written context layer, a memory that expires, and a workspace with one unambiguous source of truth.
Every agentic demo I have sat through this year has the same shape. A prompt goes in, a column of tool calls scrolls past, and something appears at the end: a segment, a journey, a set of subject line variants, a campaign brief. The demo is real, the output is usually decent, and the room is impressed. Then the demo ends, and the question I am actually paid to ask on a client’s behalf never gets asked in that room, which is what the same system looks like on month five, after it has run two hundred times, after three different people have touched it, and after nobody in the building remembers what the original prompt said or why it said it.
I have started answering that question from my own experience rather than from vendor material, for the straightforward reason that I have exactly one agentic operation I control end to end and can publish the internals of.
In March 2026 I rebuilt this site over a weekend with Astro, Vercel and Claude, and I wrote it up as an experiment in getting back to building after two decades of drifting from the keyboard toward the whiteboard, in What a Weekend with Astro and Claude Cowork Taught Me About Building Again. That piece was honest about what it was, which was a build story. Five months on it is also slightly misleading, because the build was the cheap part and it was finished in three days. What came after is a publishing operation that runs every week, and the operation turned out to have very little to do with the build.
The demo ends exactly where the interesting problem starts
The reason single-session demos are so persuasive is that they remove every variable that makes agentic work hard. There is one task, so there is no question of consistency across tasks. There is one session, so nothing has to be remembered. There is one operator, who happens to be the person who designed the demo, so the instructions are perfectly calibrated to the request. And there is no archive, so nothing that was produced last month has to stay coherent with what is produced today.
Real operations have all four. The weekly cadence on this site produces work that has to look like the work from twelve weeks ago, in two languages, using a house format that a reader would notice the absence of. Nothing about that is difficult in a single session and all of it is difficult in the ninetieth.
This is the part of agentic marketing claims I find least well covered, and I have written before about how to read those claims sceptically in Judging Agentic Marketing Claims. The scepticism I want to add here is narrower and more practical. Ask a vendor what their agent reads before it starts, what it writes down when it finishes, and what happens when those two things disagree. The answers tell you more about whether the thing will survive in production than any number of demo runs.
How the operation is actually built
Here is the operation as it stands in August 2026, described in the boring way, because the boring description is the useful one.
The site holds ninety-six articles under the writing collection, sixty-four in English and thirty-two in Italian, alongside fourteen dated MarTech Watch records, four AI Watch records and five Architecture Literacy nodes. Four series run in parallel, each with its own structural spine: Field Notes on CEP with its fixed vendor sequence, The Architecture Behind the Acronyms with its four movements, Weekly MarTech Signals with its digest format and its length cap, and Weekly AI Tools with a narrower scope. Every published article carries a hero image with companion formats, a Sources section in one house shape, and a set of internal links woven into the prose. New issues go out as a newsletter draft, and a truncated teaser version goes to Medium with a canonical pointing home.
None of that is impressive engineering. What matters is that it is all recurring, and that recurrence is what breaks agentic work.
The weekly session almost never begins with me describing what I want. It begins with me naming a procedure and pointing at a file, and the procedure carries the rules: the length cap, the voice review, the em dash strip, the Sources conformance check, the image generation in three formats. I will come back to how those procedures are built in the third part of this series. The point here is that after five months, the ratio has inverted. In March I was prompting and the system was executing. Now the system is executing rules I wrote down weeks ago, and the prompting is a thin layer on top of a much larger written substrate.
A collaborator that remembers nothing needs a specification
The single most useful thing I did on this project was accept, early and without arguing about it, that my collaborator starts every session from zero.
That sounds like a limitation and it is, but it forces a discipline that turns out to be the whole trick. If nothing survives the session, then anything I want to persist has to be written into a file that gets read at the start of the next one. Three files carry that load here. CLAUDE.md holds the operational contract: where edits are allowed, the known filesystem hazards, the build workflow, the conventions that would otherwise get rediscovered painfully every time. writing-rules.md holds the style contract, from sentence structure to the exact shape of a Sources section. about-me.md holds who I am and what I do, so that architectural interpretation stays recognisably mine.
The thing I did not expect is what writing those files did to me rather than to the system.
I have had opinions about punctuation for twenty-five years. I have never once had to state them. Writing the rule down turned a preference into something testable, which meant I had to decide what it actually was, and the first draft of the em dash rule was wrong because it banned a character rather than describing the behaviour I disliked, which was inserting side thoughts mid-sentence instead of restructuring. The same happened with the Italian rules. “La CEP” is feminine and I have always said so, but until I wrote it into a file I had never noticed that I could not explain the rule that produced it, only the instance.
Anyone who has run a platform selection knows what this is. It is the client whose segmentation logic lives entirely in the head of the one analyst who built it, working perfectly right up until she takes a job elsewhere. In an agentic setup the written model is the working system, because there is nothing else holding the logic between one session and the next.
Memory is state, and stale state is worse than none
Alongside the three context files there is a persistent memory, a set of small notes with an index that gets loaded at the start of a session. The rule I settled on for what goes in it is simple to state and irritating to apply: write down only what cannot be derived from the repository.
Code structure does not go in, because the code is right there. Fixed bugs do not go in, because that is what history is for. What goes in is the judgment layer: the numeric ceiling that keeps an infographic readable, the structural cap that holds the weekly series to the size it should be, the small vocabulary rules that make the Italian sound like Italian rather than like decoded English. Where those numbers came from, and why they are numbers rather than adjectives, is the subject of the third part of this series. What matters here is that none of it can be inferred from the files, and all of it is expensive to work out a second time.
The harder problem is not what to write. It is expiry.
A note written in June that names a component which has since been merged into another one will send today’s session confidently to a path that no longer exists, and it will do so with exactly the same tone as a note that is still correct. I have had to delete memories that were true when I wrote them. There is now a standing instruction that if a note names a file or a flag, the session verifies it still exists before acting on it, which is a check that only exists because the failure happened.
If that sounds familiar it should, because it is the oldest problem in customer data wearing different clothes. A “recent purchaser” flag from fourteen months ago is a fossil, and a system with no way to tell a fossil from a live signal will personalise against it with total confidence. Every CDP implementation I have worked on has had a version of this argument, usually late, usually after somebody sent a win-back campaign to people who had bought last week. Building an agentic operation put me back in that argument from the other side of the table, and I have more sympathy now for how easy it is to postpone.
There is a second rule on the memory that is worth stating, which is that some things are deliberately never written down. Credentials obviously, but also anything about other people that they did not hand me for that purpose. A memory layer is a data collection surface, and it should be governed like one from the first day rather than the day somebody notices.
Ambiguity is the failure that costs the most and announces itself the least
When I opened the project folder that first weekend it was not empty. It held foxi-astro-theme, astro-paper, astrofy and a folder called simply site, which were four evenings of evaluation I had started and not finished. I picked foxi, created personalSite, and started working.
Every one of those other folders will happily accept an edit. None of them will complain. A change written into foxi-astro-theme looks exactly as successful as a change written into personalSite, right up until you rebuild and nothing has moved.
So the first line of CLAUDE.md is a rule about which folder is real, and it exists because I had to say it out loud more than once. What interests me about it now is not the rule but what it reveals. An agent will not tell you your workspace is ambiguous. Given four plausible locations and no declared source of truth, it will choose one, act decisively, and report success. The failure is not in the reasoning. The failure is in the environment, and the reasoning faithfully reproduced it.
What transfers, and what only works because I am one person
I want to be careful here, because the failure mode of articles like this one is a practitioner generalising from a setup that has none of the constraints that make enterprise work hard.
Three things transfer. Written context beats better prompting, and the effort is better spent on the files a system reads than on the sentences you type into it. Memory needs an expiry policy from day one, because a stale note is not a smaller version of a correct note. And a workspace needs one declared source of truth, stated somewhere the system actually reads, rather than assumed by everyone who has been there long enough to know.
Three things do not. I am a single operator, so my rules file never had to be negotiated, and in any organisation that negotiation is not overhead on the work, it is the work. I have no approval chain and no regulatory surface, so my worst failure costs me a correction and an embarrassed evening rather than a regulator’s letter. And I can publish my own mistakes, which is a freedom no brand has, and which is most of the reason there is so little honest material about what agentic operations actually look like once the demo is over.
That is the part I can do something about, so the next piece in this series is the failure list: six failures from this site, none of them wrong answers, including three articles that carried dead source links for months while every automated check reported green.
The demo shows you the model. Month five shows you the architecture.
Sources
Anthropic
- Introducing Claude Skills. Background on the packaged-instruction format the procedures described here are built on.
Astro
- Content collections. The schema layer behind the article, watch and literacy collections described above.
