FileMaker Knowledge Delegation
Updated: 3 days ago
'Knowing every feature and function isn't the job anymore. Knowing when to delegate and confirm the answer is.' ~ my good-self, now in this Agentic Age.
Last week I built a Claude Skill for installing FileMaker Server 26 on Docker, documented at length in a separate post. Somewhere around the third certificate workaround, a different question started bothering me more than the install did: which parts of that work do I actually need to know and remember, and which parts am I allowed to let the Agent work out?
The Shelf Life of a Docker Gotcha
Three failure modes made it into that Claude Skill: a certificate import bug, publishing components disabled by default, and startup timing that varies by tens of seconds. All three are true for FileMaker Server 26, on this Ubuntu build, today. None of them are guaranteed to be true for future versions of any of these moving parts.
That's not a criticism of the skill. It's the nature of implementation detail. A flag renames. A default flips. A timeout gets fixed upstream. Memorising the list solves this release's problem. It won't solve next year's.
Two Kinds of Knowledge
Some of what I learned building that Claude Skill will still be true in five years. The rest has a shelf life measured in release notes.
Durable. FileMaker Server installs into a container's writable layer, not a volume. That's a Docker concept, not a Claris one, and it will outlast every FMS version I ever touch. Same for the general shape of a certificate trust chain, or the idea that a completely successful install can still ship with its publishing components switched off.
Perishable. The exact CLI flag, the exact error string, the exact number of seconds a restart takes. These are details an Agent can rediscover in an afternoon, working through the actual system in front of it, faster and more reliably than I can recall them from a post I wrote eight months ago.
The average FileMaker Developer already has a solid grip on the Claris Platform. That's the durable part, earned over years of schema design, relationship graphs, and script logic.
What's changed is what that depth can now reach. With an Agent handling the perishable syntax of other languages and technologies on demand, that same FileMaker judgement extends into JavaScript, Python, REST APIs, whatever the solution actually needs, without years spent becoming a specialist in each one first.
What to Delegate, What to Keep
So the practical question isn't 'how much do I need to know'. It's 'which of these two piles am I responsible for'.
Delegate the perishable pile. Syntax, current flag names, today's default state: hand it to the Agent and let it verify against the live system every time, not against my memory of the last one. Store and publish the information via the Claude Skill.
Keep the durable pile, and add one more thing to it: judgement. Whether an install is production-ready. Whether a claimed fix is actually fixed, or just looks fixed. Whether the code an Agent hands back is the code you'd want Developer Next to inherit.
Example: During that same build, fmsadmin certificate import --keyfile failed with the same cryptic error no matter what I fed it. The Agent's first three explanations were plausible and wrong. Finding the real cause meant refusing to accept a confident answer and working through the cipher and format combinations systematically. The same discipline I'd use reviewing a contractor's schema before it goes anywhere near a Production Server.
Reviewing the Agent Is the New Code Review
This is the skill that doesn't expire. Not the ability to write the fix yourself, but the ability to tell a correct fix from a plausible one. That's code review. It was always code review, whether the first draft came from a junior Developer, a contractor, or an Agent typing at three hundred words a minute.
The FileMaker Developers who struggle with this shift aren't the ones who know less about Linux or Docker. They're the ones who've stopped reviewing, because the output arrived fast and confident and it felt rude to check.
This can also be seen as a fundamental skill to be able to delegate – this is one skill that the solo FileMaker Developer did not need to embrace, and from personal experience, most would rather do it themselves, and know it was done 'their' way.
Those days are over. Let that sink in.
This Shift Is Already Playing Out
One of the Historical Requirements for our Developer Role has been Certification.
The FileMaker Essentials Certification was a 64 multiple-choice questions with an 80% pass mark: recall under exam conditions, no reference material allowed. That's a reasonable way to test whether someone has internalised the platform.
The thing is, I built a Claude Skill from the official certification markdown files, and it now holds that same body of knowledge, indexed, current, and available on demand.
The exam still proves discipline. It no longer proves that the knowledge itself has to live in my head, particularly when the knowledge is shifting at an accelerated rate.
There may seem to be a 'new' requirement – and this has actually always been the case – it's not about knowing the answers, it's about knowing how to find the answers.
When the Shelf Life Ran Out: FileMaker Server 26.0.3
A month after this post, Claris released FileMaker Server 26.0.3. The perishable pile expired right on cue.
Under 26.0.2, the Skill applied the NginxUpdate.sh patch Claris shipped, swapping Ubuntu's Nginx for a newer nginx.org build. 26.0.3 dropped that script, and its installer quietly removes the nginx.org source during the upgrade. The patch didn't break. It froze. A newer Nginx that would never receive another update.
I delegated the upgrade the same way as the install: snapshot first, back up the volumes, dry run, upgrade, verify. The Agent did the perishable work. Deciding which Nginx the server should run, and whether the result was actually safe, stayed with me.
Example: Before release, I had the Agent answer the same upgrade question twice: once with the Skill, once without. Without it, the confident answer was to put the nginx.org source straight back in. The exact opposite of Claris's own change. Plausible, fluent, and wrong.
Verification cuts the other way too. The Skill had described its rollback as 'expected to work' since v1.2. Expected is not verified. So the Agent restored the backups into an isolated test container and brought 26.0.2 back from the snapshot. Twenty seconds. Now the Skill says verified, and can prove it.
The Skill went from v1.1 to v1.5 in a single day, every correction on GitHub against a version number.
FileMaker Pro Skill, Reviewed Against Anthropic's Best Practices
The same discipline got a second workout early in October. I took the claris-filemaker-pro Skill through Anthropic's own skill authoring checklist, and it did not pass cleanly.
Three findings changed the structure:
Triggering lives in the description. A 'mandatory trigger' rule sat in the body of the Skill. Claude only reads the body after the Skill has already fired, so the rule did nothing. It moved into the description, and the body became a single routing table.
Search, don't read. The function catalog runs to 5,300 lines. The Skill now tells the Agent to search it, not load it, and hands over the exact one-liners.
Verify before answering. Nothing checked a calculation before it was handed over. The Skill now runs a checklist with a feedback loop, and where the Claris Agentic Development Toolkit is installed, every calculation is validated against the real FileMaker engine first.
Example: The engine gate earned its keep immediately. Version 2.0.0 shipped with examples that had never been run against an engine, and checking them found around 120 errors, including JSONRaw documented as 7 when the value is 0. Now every example has to pass the engine before release: 255 verified, none failed. Another 77 need record context, so they're checked against Claris's own Help pages instead, and the Skill says so.
Then the model tests. With no Skill, the baseline passed 2 of 8 cases. With it, Sonnet and Opus passed all 10. Haiku climbed from 6 to 9 to 10, and the lesson along the way is the useful part: a smaller model only obeys the rules in the checklist it copies at the start, not the ones buried in a reference file. Put the rule that matters at the top.
Version 2.1.0 shipped in early October. It's current to FileMaker 26.0.3, works with the Toolkit when it's installed, and installs as a plugin. The install steps live in the FileMaker Developer AI Coding Skill post. It also credits and links six of Andy Kear's Skills. Linked, not bundled, so the original stays the source.
The perishable pile now has a test suite.
The Documentation Discipline, Generalised
There's a companion piece to this, one I wrote about at length while building the Docker Claude Skill itself, in a separate post: FileMaker Server via Docker. The short version applies to any Agentic build, not just that one.
Approach it as a live record, not a write-up after the fact. Research with a healthy suspicion of anything that merely looks recent. And document it somewhere that carries a version number, a changelog, and a place for someone else to correct you: a Claude Skill on GitHub, not another blog post nobody will remember to update.
Takeaway
The gap isn't how much Docker you know. It's whether you can confirm that your Agent's confident answer is the correct one, and whether you've left a record honest enough for Developer Next, including future you, to trust.
Know less about flags. Know more about verification. That's the trade, and it's a good one.
More to come . . .
Note: Upgrade story 24 Sept 2026, verified against FMS 26.0.3 and v1.5 of the Claude Skill.
Comments