I didn't set out to build a diary. I set out to build a canvas.
agent-flow-canvas is a browser-based visual builder for AI agent workflows — drag out a Trigger, an LLM node, a Router, a Memory block, a Subagent, wire them together, press run, watch the graph execute live in your own tab. No download. No install. No login. Your API keys never leave localStorage and never touch a server I control — they go straight from your browser to OpenAI, Anthropic, Gemini, Ollama, or whatever OpenAI-compatible endpoint you point it at. There's no backend in the run path at all. That was the whole design brief: you bring the keys, the browser does the work, I never see either one.
But that's not the part that got me.
The part that got me was a file I never meant to write by hand: test_result.md.
I. The Accident
Somewhere in the 84 commits it took to get this thing from "single hardcoded gateway" to "multi-provider, BYO-key, fully client-side," I had an agent building alongside me — a main agent writing code, a testing agent verifying it. And the protocol between them wasn't a Slack thread or a commit message. It was a shared file, structured like a lab notebook: task name, file touched, priority, working: true or false, and underneath each one, a status_history — a stacked, timestamped log of who touched it, what they believed, and why.
Read it back and it doesn't read like documentation. It reads like a diary.
"Replaced single GatewayConfig with a Gateway[] library persisted to localStorage. Migrates legacy single gateway. Manager UI supports add / edit / delete, provider switch, show/hide key, clear-all-keys, export-without-keys. Privacy banner present."
— main agent"Tested gateway manager functionality... Clear all keys functionality works — wipes API keys and shows warning icon for gateways requiring keys... All core functionality working as expected."
— testing agent
Two voices. Two different jobs. One arguing for what it built, the other checking whether the built thing survived contact with reality. That's not a changelog. That's correspondence.
II. The Recognition
Here's the structural trick, and it's not mine — it's the protocol's: the file isn't allowed to just say "done." It has to say what was tried, what broke, what got fixed, and whether the fix actually held. There's a field called stuck_count — a number that goes up every time the same problem gets re-solved and re-breaks. That's not a status flag. That's a system confessing when it's going in circles.
I've kept journals like that. Not about gateway managers — about myself. The same entry, different date, same wound, slightly different language, because I hadn't actually fixed anything, I'd just gotten better at describing the problem. stuck_count is the metric I never had the discipline to log on paper. The agent has it by default, because nobody told it confession was optional.
By the end of the build, the log doesn't just say what changed. It says:
"Pure-frontend refactor. No backend calls in the run path... Do NOT need to actually hit a real LLM — but we should confirm the run executes the schematic non-LLM nodes and produces logs in the run drawer... Existing flows like validate, code-view, sample walkthrough, export/import JSON should still work."
That's not a spec. That's an agent leaving a note for the next version of itself — or for the other agent reading the same file — explaining its reasoning in case anyone, human or otherwise, has to pick the thread back up later without asking why.
III. The Canvas Itself
None of this diary-keeping is the point of the tool, technically. The point is: you open it, you get eight node types — Trigger, LLM, Tool, Router, Memory, Subagent, Human, Sink — and you build an actual agent graph without writing a line of code, then hit view code and it hands you runnable Python or JavaScript to take with you. It's MIT licensed. Host the static build wherever — GitHub Pages, Cloudflare, Netlify, doesn't matter, there's no server-side piece to babysit.
But the diary is what the tool is made of, underneath the drag-and-drop. Every LLM node in the canvas is, structurally, the same kind of thing that wrote test_result.md: something that acts, then has to account for the action, then gets checked by something else that isn't allowed to just take its word for it.
Self-documentation isn't a feature you bolt onto an agent. It's what makes something an agent instead of a script. A script runs and exits. A diary-keeping system runs, and then has to answer to its own history.
IV. What You Actually Build When You Build This
So what do you actually get when you wire up a graph in agent-flow-canvas? Not just an automation. A thing that, if you built it right, leaves a trail of why behind every what.
You already do this, whether you've named it or not. Every retro you've sat through, every PR description you've padded out past "fixed bug," every commit message longer than it needed to be — that's you, keeping the same file the agents were keeping. Explaining the decision so the next reader, possibly a future version of you, doesn't have to reverse-engineer your reasoning from the diff alone.
The agent didn't invent the diary. It just stopped being embarrassed to keep one in the open.
Build the graph. Let it run in your own tab. Keep your keys where they already live. And when the thing you built has to explain itself later — because it will — make sure it left something behind worth reading.
agent-flow-canvas is MIT licensed and live at agent-flow-canvas.vercel.app. Source on GitHub: github.com/Jacobcdsmith/agent-flow-canvas.
Top comments (0)