FileMaker 2026 turned the .fmp12 into something an AI agent can read, compare, and patch. We built the pipeline: it moves the changes you approve between files, and it scaffolds whole solutions from a description, web app included. Everything you'll see runs on tools that ship today.
A FileMaker career usually starts one way: a tool that collapsed the gap between having a problem and solving it. No computer-science degree. Just screens, scripts, a database your whole team could share. You weren't hired as a developer. You were a problem solver, and the tool met you where you were.
Agentic coding collapses a new gap, the one between "I can describe it" and "it exists." Same move you already made once: a new tool that meets you where you are, no permission slip required.
Not an AI bolted into the box. The box opened up to the agent you already have. Docs it can read, connections it can call, formats it can write. The moat was never the building. It's the running. Your data, your server, the system of record your business runs on.
New tables, fields, and layouts pile up in your development copy. Production needs them. Copying between files is piecemeal and lossy, and layouts barely transfer at all. So you rebuild, click for click, and hope you didn't miss one.
Claris's documented path: export XML from both files, diff them yourself, hand-write the patch. As Soliant's Mislav Kos put it in 2025: "this has to be done manually. We'd love to see Claris develop a tool to automate that process."
No tool, from Claris or the community, turns that diff into a patch for you. Too tedious to do by hand, too fiddly for classic automation. Exactly the shape of work AI agents are good at.
Claris's help library is now fetchable as plain Markdown, the format AI reads natively. The agent taught itself the Upgrade Tool's patch format straight from these pages.
The file's complete design (tables, fields, scripts, layouts, security) exported as one structured XML document. 2026 made it catalog-selective and tool-friendly. Design only: your records never leave the file.
Applies a patch: add or change tables, fields, layouts, and scripts in a closed file. It existed quietly for years, under-documented and fragile. 2026 upgraded it and finally wrote the manual.
You never type a command. The coding agent runs these tools under the hood, the same way it built the pipeline. You just describe the change you want.
Headless Save-as-XML on a closed file. Same XML the menu command in FileMaker Pro gives you, except no app and no human in the loop. Ships with FileMaker Server's command-line tools.
Applies a patch XML to a closed file: tables, fields, layouts, scripts. Version 26 shipped with FileMaker 2026, upgraded and properly documented at last.
One question. One answer. You ask, it replies. Then you do the thinking, the work, the follow-up.
ChatGPT · Claude.ai · Gemini
It loops, in the cloud. The agent mode inside a chat tool: it browses, calls the services they've wired up, runs a task and reports back. Lives on their servers, reaches what they connect.
ChatGPT agent · Claude agent mode
It lives on your computer. Reaches your files, your network, your apps. And it writes new software when it needs something it doesn't have yet. This built and runs the whole patch pipeline.
Claude Code · Codex
Plain-English procedures, one Markdown file per job, written like onboarding docs for a new hire. Rules included: what MUST happen, what may be skipped, when to stop and ask.
Claude Code in the middle. Reads the workflow, runs the tools in order, judges the results. Proceed, retry, skip, or stop and escalate to a human.
Python scripts for the deterministic work: parse the XML, compute the diff, generate the patch. 122 automated tests. Right every time, not 90% of the time.
FMUpgradeTool reports "Patch File Applied" even when a calculation arrives silently broken. A test run caught it doing exactly that.
The learning didn't go on a sticky note. It went into the procedure. Every apply is now followed by a mandatory verify: re-export the file and prove each change actually landed. And every run ends by logging what it learned.
The agent proposes, the checkboxes decide. Anything unticked doesn't move. And the change types it can't make safely, it refuses outright. Those stay yours, in FileMaker.
Backup first, always. The patch is validated and applied on a disposable copy, then smoke-tested. Only after the rehearsal passes does it touch the real file.
Re-export, re-diff: every approved change landed, nothing else moved. The run is logged either way. And the XML is design-only. Your records never leave the file.
Every tool was written against a failing test before the code existed. 122 automated checks run the whole pipeline end to end, so a change that breaks patching gets caught in seconds, not in production.
Two files differing by six tables, dozens of fields, and several layouts. 104 differences in all. The tool found every one, applied them to a copy of production, and the verify step confirmed the two files ended structurally identical.
AI reviewers went over the finished system, each finding double-checked by others. They caught two bugs where the update reports success but is silently wrong. A formula arriving disabled. A counter that got reset. Both fixed, both pinned with tests.
A FileMaker XML export is one enormous file. A quarter-gigabyte isn't unusual. The fm-xml-export-exploder (bc-m, with Soliant's lossless mode) splits it into one file per object so it can actually be compared. The whole compare step leans on it.
github.com/bc-m/fm-xml-export-exploder
Tables before fields, fields before the layouts that show them. Objects go into the patch in dependency order, so nothing references something that isn't there yet. Forward references just fail.
Move a script that calls a field production doesn't have, and the generator stops and names exactly what's missing. It never ships a half-connected patch.
The same machinery you just watched: diff, patch, verify. Point it at an empty starter file, hand it a bigger shopping list, and the migration tool becomes a builder.
Written in conversation, saved as a file: Accounts, Contacts, Projects, with these fields and these relationships. Because it's a file, the build repeats. And the spec is the contract the result gets checked against.
The spec becomes one big patch against a starter file, and the same gates run: validate → rehearse → apply → verify, every table, field, and layout checked off against the spec. Later rebuilds preserve live data, proven with records in the file.
ProofKit deploys a React web app into a web viewer inside the same .fmp12. Modern UI, FileMaker data, one file. Nothing else to install or host.
proofkit.proof.sh
Dev-to-prod migrations on your files, with every gate you just saw. Release day stops being an afternoon of clicking and praying. It becomes a checklist run.
New modules or whole solutions scaffolded onto your standards: your base file, your naming, your security. Web app included.
Quotes, reports, data moves, document wrangling. Any procedure your team can write down, an agent can run, log, and improve. The same pattern runs our other client work.