Shipping a Release on a Knowledge Graph: How Humans and AI Agents Build Metapad Together

In February we admitted that we haven't written a line of Metapad's code by hand. In May we described how we build Metapad's models by talking to them. This post is about what happened next: we stopped working with one AI assistant and started running several at once. To our surprise, the hard part turned out not to be the AI at all. It was keeping everyone — human and machine — working from the same picture.

---

At a Glance

• Since January 2026 we have built 327 versions of Metapad: more than one per calendar day, each followed by a full regression run of our automated test suite.
• The codebase is substantial: about 325,000 lines of Rust and 72,000 lines of test code.
• One person decides and reviews. AI agents (Claude Code) write the code and the tests, several at a time, each in its own isolated copy of the code. Even the build itself is run by an agent.
• The plan, every decision, every test verdict and every review lives in a Metapad model: today 3,766 elements, including 874 work items, 1,302 automated end-to-end tests and 305 test scenarios.
• The documentation lives in a second Metapad model, bilingual, written by Claude, with screenshots and the changelog generated automatically.
• Behind the agents stands a team of people building with Metapad every day: 16 substantial showcase templates in our library and more than 20 substantial production models. Their feedback sets the roadmap.
• The bottleneck is not the AI. It is human attention, so we budget it, release by release.
• The same pattern works for any organisation that delivers change: your delivery process is an enterprise system, and it deserves a digital twin.

---

1. The problem with more than one agent

One AI assistant in one conversation is easy to work with: you both see the same history. Run three in parallel and that shared history is gone. Agent A doesn't know that agent B changed the data format an hour ago. The agent fixing a bug tomorrow doesn't know that we decided today not to fix it that way. And the person in the middle — me — becomes a human message bus, repeating context from one window to the next.

We tried the obvious remedies: longer prompts, shared notes files, more careful handovers. They all decay. A notes file is out of date the moment someone forgets to update it, and nobody can ask it a question.

What we needed was a shared record that every participant reads and writes, that knows the difference between a plan, a decision and a verdict, and that can answer questions like "what is still waiting for a review?" without someone reading through everything.

We already had one. It is the product we are building.

2. The release is a graph

Metapad's own development is described in a Metapad model. Its structure is deliberately simple:

Node type	What it holds
Concept	Design ideas and the reasoning behind them
Implementation Plan	For the bigger jobs: phases, affected parts, migration steps, test checklist
Issue	A unit of work: what to do, how we'll know it's done, how much human attention it needs
Image	One build of the application, numbered — "image 327"
Test Scenario	What a test is supposed to prove, written in plain language
Test and Test Run	Each automated test, and each regression run against a build

We write the Issues together with Claude. A bug report, an idea from a customer call or a gap found during testing becomes a conversation. Claude reads the relevant code, proposes the root cause and the fix, and writes the Issue into the model with affected files, a testing note and links to the Concepts it touches. For anything larger than a day's work, we first write an Implementation Plan: the phases, the parts of the system involved, what must happen in which order. Agents work from that plan, not from a one-line ticket.

We plan releases for the week, on a rolling basis, in a Metapad grid view: Issues as rows, upcoming images as columns. Assigning an Issue to a release is one click in the grid; moving it to a later one when something slips is another.

The value is in the relationships. An Issue ships in an image: before the build, that's the plan; after it, it's the release manifest. "What's in 327?" is a single question to the graph. A test run ran against an image, and each test that flipped from red to green is linked to the run where it turned. So "what did this build fix, and what did it break?" is a walk across the graph, not an afternoon with log files.

Two properties on every Issue carry most of the discipline:

• A gate. One line naming the condition that closes the Issue, checkable by someone who isn't the person who wrote the code: "this end-to-end test passes", "this log line appears after the next run", "Oliver decides". Every check records whether it is met or not yet met.
• A review budget. none (an automated test is enough), glance (a person needs to see it — layout, wording, a rendered PDF) or judgment (a person needs to try it and decide).

The agents connect to this model over Metapad's MCP interface, the same way your own AI tools can. When an agent finishes, it writes its results onto the Issue. When I decide something, the decision is written onto the Issue too. Nothing important lives only in a chat window.

3. A release day: image 327

Here is today, more or less as it happened.

Morning — planning. Fourteen Issues were planned into image 327: bug fixes, a refactoring of how edits are recorded, collaboration hardening, a time-range feature for dashboards, and a request a customer had sent us the day before — let me drag the end of a relationship from one element to another, instead of deleting it and drawing it again. We'd shied away from that one because it sounded hard. Talking it through with Claude, it turned out that half of it already existed. The decisions went straight onto the Issue: keep the relationship's identity, update it on every diagram that shows it, one step to undo.

Late morning — a release manager, six branches, three agents at a time. The release itself is run by an agent: a release manager. It reads the image's Issues from the model, bundles them into topic branches by the code they touch, and briefs an implementation agent for each. Each agent works in its own isolated copy of the code, with its own database and its own server, so none of them can trip over another. We never run more than three at once; each one compiles a large codebase, and a stalled laptop helps nobody.

Midday — a graceful pause. I had to move offices. Rather than letting the laptop sleep mid-edit, the release manager told every agent to pause: save its work, write where it stands into its progress notes and onto its Issue, and stop. An hour later, from the new desk, every agent picked up exactly where it had left off — because "where it had left off" was written down, not remembered.

Afternoon — reviews as a gallery. Of the fourteen Issues, only five needed me. For the three glance Issues, the agents attached screenshots to the Issue in English and German, and the release manager looked at them first. My review was a gallery, not a test session. For the two judgment Issues, I got a running build and a short click script. The relationship drag felt right on the first try. For the dashboard feature, an agent built a complete demo model, published it, and left it ready for me to open in a private browser window and switch between "last year" and "this year". That took ten minutes instead of an afternoon.

Evening — merge, build, deploy, regress. The release manager merged each branch only after the combined code passed the full test suite, because two branches that each pass on their own can still break each other. The build runs on a dedicated build machine in the cloud, so it is fast and doesn't tie up anyone's laptop. Then a deployment to our test environment and a full regression run on GitHub: every automated test, against the build that will go to production.

And one more thing. While moving the fourteen Issues on after the deployment, we noticed fifteen older Issues that should have been moved weeks ago and weren't: somebody — me — had forgotten. That isn't an AI failure; it's a process gap. So before the day was out, an agent extended our release tooling to do that step automatically, and to warn about any review that happened but wasn't recorded. A step that gets forgotten twice becomes a tool's job.

4. The documentation is a model too

Metapad's help pages, feature descriptions and blog — including this post — live in a second Metapad model, in English and German. Claude writes and maintains it the same way it maintains the code: proposing changes, which we review before anything is published. From that one model we generate the website, the in-app help and the knowledge our in-app AI assistant draws on.

Two parts of it run on their own:

• The changelog is filled from the release. Because the model knows which Issues shipped in which image, the changelog entries for a release are written from exactly that list, by the AI, and signed off by a person before they go out.
• Screenshots are generated, not taken. Each screenshot in the help is a recipe in the model: which model to open, what to click, what to capture. A script produces it in both languages, and an agent checks every image before it is published. When the user interface changes, the screenshots follow.

5. The people who keep us honest

Agents can build a feature. They can't tell us which feature matters. That comes from people using Metapad for real work.

A whole team of modellers builds with Metapad every day: the 16 substantial showcase templates in our template library, and more than 20 substantial production models. They are our most demanding users. When something is awkward to do, slow on a large model or confusing in German, we hear about it — usually the same day, and usually together with the model where it happened.

Their feedback becomes Issues in exactly the way described above, often written together with Claude in the same conversation. It drives the feature roadmap and the steady stream of usability improvements that make up much of every release. The faster we ship, the more this matters: a team that releases daily needs people who use the product daily to tell it whether it is heading the right way.

6. What we learned

The human is the bottleneck — so spend the human deliberately. AI agents produce code and tests faster than anyone can review them. Without a budget, every change waits for a person and the release stalls. With one, most changes are proven by automated tests, and the person's time goes to the handful of things only a person can judge.

A review that isn't recorded didn't happen. Today proved it twice: a review done weeks ago, never written down, was still listed as pending. The fix wasn't to try harder; it was to make "review done" a property a tool can read.

Test the feature before the build; test the build for regressions. Every feature's test is written together with the feature, by the same agent, and runs green before anything is merged. The full regression run on the build is there to catch what nobody expected, not to find out whether the new feature works.

Give the agents your production logs. Our servers report to a cloud logging service, and Claude can query it directly. That has proven invaluable for bug hunting: instead of guessing why a test failed only under load, the agent lines up the failing test with what the server recorded at that very moment, and comes back with evidence rather than a theory.

Make the shared record the path of least resistance. Agents write to the model because it is how they get their instructions and where their results go. If writing to the record were an extra step, it would be skipped.

7. Why this matters beyond us

Nothing in section 2 is specific to software. Replace "image" with "release", "quarterly plan" or "change request", and "test" with "acceptance check", and you have the structure of almost any organisation that delivers change.

That is the point we keep coming back to on this blog. Metapad is a platform for enterprise digital twins, built on computational knowledge graphs. A delivery process is exactly the kind of organisational system that benefits from one. It has state (what is planned, what is done), responsibility (who decides, who reviews) and change over time (what each release fixed and broke). Your version-control system, your ticket tool and your CI pipeline are the detailed systems; each one is authoritative for its own slice. The twin is the overall picture that connects them and answers the questions none of them can answer alone: what is this release waiting for? Who needs to look at what? Did we keep the promise we made in that decision?

And with AI agents joining your team as colleagues rather than tools, a shared, queryable record of plans and decisions stops being nice-to-have. It is how humans and machines work from the same picture.

8. What's Next

Want to try it? Metapad is free to begin at app.metapad.ai. Connect your AI assistant over MCP and start modelling your own delivery process.

Want a head start? We're turning our delivery model into a template you can fork — work items, releases, test scenarios, review budgets and all. Watch this blog.

Want to see it in action? Join one of our free webinars at academy.transentis.com.

The AI writes the code. The graph remembers why.