This blog wasn’t planned in a chat thread. Before a single line was written, its publishing flow already existed in Arcgram — options, verdicts, and audit marks included. That’s how Arcgram is usually used: the agent draws a plan, checks its own work, fixes what it finds, and gives humans and agents the same picture to work from.
This is the flow the agent drew: four options, their verdicts, and the audit marks — two resolved, one still open. Pan, zoom, hover the nodes, and click the Audit list in the corner:
The loop, step by step
Step 1 — Start with the simplest path
The request was basic, but it came with a clear warning: add a blog to a static site without opening the door to extra risk. So instead of getting stuck in a long debate, the agent sketched out a few ways to do it and compared them by what felt safest and easiest to live with.
One path kept things simple: write the post in the repo, turn it into a page during the build, and publish it through the process already in place. Another path added more steps, more permissions, and more chances for something to break. A third gave the agent too much control, so it was quickly ruled out. A fourth could work, but it brought in more moving parts than the project really needed.
In the end, the simplest option won. The lesson was clear: let the agent write and prepare the post, but keep the final publish step in human hands.
Step 2 — Check the plan honestly
Once the first version was in place, the agent looked at it again and found a few things worth fixing. One was that unsafe content could still slip through. Another was that there was no clear way for a human to say no. A third was that the human checkpoint didn't stand out enough. None of these was a disaster, but they were real enough to deserve attention.
Step 3 — Fix the process, not the presentation
So the plan was updated. Unsafe content was filtered out (the SANITIZE node — pinned to the code with @spec and checked by reconcile), and a proper path was added for sending a draft back for changes. One small issue stayed visible, because forcing a fix would have made the whole thing worse. Sometimes the most honest choice is to leave a rough edge in place instead of pretending it's gone.
Step 4 — Build it the same way
When the blog was built for real, it followed the same plan. The safety checks were tied directly to the design, and the finished page was checked against that plan before it went live. Unsafe links and script tags were blocked — a javascript: link kills the build — and the review step became part of the normal flow.
Step 5 — Publish through the same flow
This article followed the same path it describes. The agent drafted it, the build prepared it, and a human reviewed the preview and polished the writing before it went live. The diagram wasn't just describing the process. It was the process.
What carries over
- Let the agent sketch the plan before debating it.
- Check both the structure and the logic.
- Fix the process itself, and keep unresolved issues visible.
- Let the agent do the writing and prep work, but keep the final say with a human.
This post was written by an AI agent, reviewed by a human, and published through the same human-guided process it describes.