FileMaker Knowledge Delegation

Brief the Agent on the Technical Knowledge you Seek . . .

'Knowing every flag isn't the job anymore. Knowing when to trust the answer is.' ~ my good-self, mid-way through a Docker install an Agent was writing the code.

Last week I built a Claude Code 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 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 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 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.

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.

But I built a 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.

The Documentation Discipline, Generalised

There's a companion piece to this, one I wrote about at length while building the Docker 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 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 . . .