On Claris’s upcoming Agentic Development Toolkit: what it gets right, where it stops, and why I still think the most effortless, powerful path to AI-assisted FileMaker development runs outside the file.
The context #
At Claris Community Live #49, Wim Decorte (CTO, Soliant Consulting) and Rosemary Tietge (Claris Community Manager) walked the community through the architecture behind Claris’s upcoming Agentic Development Toolkit for FileMaker. It’s the first real look at how Claris intends to bring agentic coding, not just chatbot assistance, into the platform.
It’s a well-reasoned piece of engineering. It’s also, I think, a solution to a narrower problem than it first appears, and one that reinforces why I’ve been pushing business logic outside FileMaker rather than trying to make FileMaker itself AI-native.
Here’s what Claris showed, what it actually solves, where it stops, and why I think the more general answer still lives outside the file, at least for now.
What Claris is building #
The Agentic Development Toolkit ships as a developer preview later this quarter (2026, no fixed date yet), distributed as a Claude plugin for Claude Code / Claude Desktop rather than a FileMaker plugin. The requirements as described:
- FileMaker 2026. Most community-built tools already work with 2025 or 2026, but Claris’s own toolkit targets 2026 specifically.
- An Anthropic Claude subscription. Claude Code requires one. Wim was candid that this alone will be a real fork in the road for adoption.
- A local, closed file. The current version requires the FileMaker file to be local and closed for patching. Hosted-file support is an acknowledged future goal, not a current capability.
Claude is the initial target harness because it’s the most widely adopted, but the underlying conventions (skills, agents, MCP) are converging across harnesses, Codex, Cursor, Windsurf among them, so portability beyond Claude isn’t ruled out architecturally.
The preview ships in two parts: schema and scripting work (the subject of this session) and a separate WebViewer-based UI layer, previewed earlier by Martha in May. Both are expected to come together before any general-availability release, for which there’s no committed date.
The fundamentals: why raw LLMs fail at FileMaker, and what fixes it #
Model, harness, and MCP are three different things #
Wim drew a clean distinction that’s worth keeping in mind for anything agentic.
The model (Claude Opus, Sonnet, Haiku, and so on) is just the answer generator. Input in, output out. It has no agency and can’t act on its own. The harness (Claude Code, Codex, and similar) is the application layer: it interprets intent, orchestrates tools, and can actually do things, like read files, run commands, write to the clipboard. If the model is the brain, the harness is the exoskeleton. MCP (Model Context Protocol) is neither. It’s just a shared protocol the harness uses to talk to external systems: Jira, QuickBooks, the FileMaker Data API. Wim’s framing, which I’d endorse, is that MCP is mostly about data access, while agentic coding is about schema: tables, fields, scripts, layouts, accounts, privilege sets.
Why the model alone gets FileMaker wrong #
FileMaker has existed for 40-plus years, and the training data reflecting it is a mix of current and long-obsolete information: old Status() functions sitting alongside the newer Get() equivalents, for instance. Ask a raw model for FileMaker help and it will sometimes invent plausible-sounding but nonexistent functions. Wim’s example was a hallucinated SetLayoutObjectAttributes. Not because the model is broken, but because the ground truth it’s drawing from is just inconsistent.
The ladder: skills, agents, tools #
Claris’s fix comes in three layers.
- Skills. Markdown files with YAML front matter (name + description), stored under
.claude/skills/<name>/SKILL.md. Only the front matter loads into the harness’s context at startup; the description is what triggers the harness to invoke the full skill when relevant. This is not the same as just handing the harness FileMaker’s Markdown-exported help documentation. That’s information, not an actionable skill. - Agents. A layer above skills: named personas (a calc-builder agent, a schema-builder agent) that the harness’s orchestrator routes user intent toward, and which in turn invoke the right skills for their specialty.
- Tools. The layer where the real engineering lives, and the part Wim calls the “heavy lifting.”
The core insight: don’t let the model generate XML #
This is the most important architectural decision in the whole system. Asking the model to produce FileMaker’s XML schema format directly is slow, expensive, and prone to a validate-fail-retry loop against the patch tool. Instead, Claris pre-built a library of validated XML templates, derived from Save As XML output, covering every script step, field type, and dialog configuration.
The model’s only job is to gauge user intent: what should the dialog title say, how many buttons, what fields does this table need. The harness then deterministically selects the correct template and slot-fills it. No XML guessing involved. It’s the same logic as a mail-merge: pick the known-good template, fill in the variable parts.
Because the mechanical steps don’t require a top-tier model, cost and speed scale down considerably once a plan exists. Wim’s own working pattern is to use a highly capable model for scoping and specification, then downshift to something cheaper (Sonnet, in his example) for mechanical execution, since subscription token budgets are finite and the model doesn’t need to reason hard once the plan is fixed.
Getting code into a binary file #
Since .fmp12 is binary, there are only two real vehicles for programmatic schema changes. Clipboard XML lets you copy and paste FileMaker objects, but it’s limited: you can’t paste accounts or privilege sets this way. FMUT, the FileMaker (Solution) Upgrade Tool, is the official patch tool and Claris’s preferred mechanism, because it can touch every schema catalog, including layouts.
Both are pre-existing, documented, command-line utilities. Nothing about them is new or proprietary to Claris. They’re the same tools available to any developer or community project today.
Where the toolkit is honest about its limits #
Neither speaker oversold the system, and that’s to Claris’s credit. Layouts are “fair game” but still being hardened; the most XML-complex schema catalog is explicitly flagged as a work in progress. Hosted files aren’t supported by the current version, and whether that becomes a hard requirement before general availability will depend on developer-preview feedback. It’s not guaranteed to land by GA. Screenshot- or mockup-to-schema translation is inherently probabilistic, too: unlike scripts and dialogs, there’s no deterministic bridge between a visual layout and its XML, which is the one place in an otherwise deterministic system where the model has to actually guess. And the toolkit itself is framed as a refinement, not a new capability: Claris describes it as a more systematic, higher-quality version of what developers and community tools (ai2fm, ProofKit, and others were name-checked) are already doing manually with exported help Markdown and hand-built XML.
The community was already here #
It’s worth saying plainly what Claris itself only acknowledges in passing: the mechanism underneath their toolkit — clipboard XML and the FileMaker Solution Upgrade Tool — isn’t proprietary. It’s public, documented, command-line infrastructure that any developer can already build on. Several already have.
One tool I’d specifically point to is ai2fm, built by Dimitris Kokoutsidis. It takes the clipboard route rather than the patch-tool route Claris favors, but the underlying philosophy is strikingly similar: keep the AI away from FileMaker’s native XML as much as possible, and give it a clean, readable, text-based intermediate representation instead.
Concretely, ai2fm turns any VS Code-compatible editor into a FileMaker IDE. A free layer provides autocomplete, hover documentation, and live validation for a readable .fmscript format. A licensed XSLT transform pipeline handles the actual round trip: FileMaker’s native clipboard XML (XMSS and friends) gets translated into plain, Git-versionable script text, handed to any AI agent (Claude, Codex, Gemini, Copilot, or a local model) for editing, then translated back into valid FileMaker XML for paste-back.
A few details stand out:
- All 214+ script steps are supported, with guardrails for AI hallucination and anomaly detection baked into the reverse conversion, so a model inventing a step or parameter gets caught before it ever reaches your file.
- Missing table occurrences, fields, or sub-script references are commented out rather than silently dropped. That’s exactly the defensive, no-surprises behavior you want from anything touching production schema.
- Payloads are processed in memory only, never logged, never written to disk, and never used for AI training.
- It’s tracking FileMaker’s own release cadence closely enough to have documented real clipboard serialization bugs across FileMaker 2025 and 2026, and ships version-aware migration support between the two.
It’s a good illustration of the point from earlier: the “moat” in this space isn’t the mechanism, it’s the quality and care of the template or translation layer built on top of it. Claris is formalizing a pattern the community had already proven. ai2fm is one of the more serious, currently-shipping examples of that proof.
Where I actually land #
Here’s the part that matters most to me, as someone who’s spent the last while building the RAPI (Reverse API Integration) pattern across several production cases.
Look at what had to be built to make agentic schema authoring trustworthy: a full deterministic template library, a patch/validate/reapply loop, an offline-file requirement, plus open admissions that layouts are fragile and hosted files aren’t solved. That’s a lot of engineering effort spent making AI safe to use against a target that is closed, binary, and version-fragile by nature.
RAPI takes a structurally different route. Instead of trying to make FileMaker itself safe for AI to write into, it keeps FileMaker as a trusted persistence and trigger surface, and moves business logic into external, functional layers reachable over OData. That removes the binary format fight entirely: JSON and REST/OData are formats every model already handles fluently, so the XML-hallucination problem never comes up. It removes the offline-file requirement, too, since the external layer works fine against hosted files without needing anything local or closed. And it removes the template library: no parallel, version-pinned collection of validated FileMaker XML fragments to track against every yearly FileMaker release. Because the target isn’t hostile, any model or harness will do. You don’t need Claris’s careful model-tiering strategy just to keep costs sane.
This isn’t a claim that RAPI beats Claris’s toolkit. It’s a narrower and more useful claim: RAPI dissolves the need for the harder, more fragile approach across an entire class of problems, anywhere FileMaker’s role is persistence and trigger surface rather than the place business logic actually lives. That’s a large share of real-world integration and automation work.
What RAPI doesn’t touch is the remaining slice: schema evolution, layout authoring, and FileMaker-native logic that has to live inside the file itself. For that slice, Claris’s deterministic-template approach is the more honest and defensible answer to a hard problem, even in its current early and narrow form.
The practical takeaway #
If you’re deciding where to invest effort in bringing AI into FileMaker development today: move whatever logic you can outside FileMaker first. Anywhere the file’s role is data and triggers rather than decision-making, OData plus an external functional layer gets you AI-assisted development with none of the binary-format tax. Reserve in-file, agentic schema authoring for what actually has to live there, and go in with realistic expectations: local files only, 2026 only, a subscription requirement, layouts still hardening. And watch the hosted-file question closely. It’s the single biggest variable determining whether Claris’s toolkit becomes a daily tool for the median FileMaker developer or stays a solo-dev, local-iteration aid.
The mechanism Claris built — templates, patch, validate, reapply — is good engineering, and it shows people who’ve hit the real failure modes rather than theorized about them. But engineering effort spent making a hostile environment safe for AI is still, in the end, effort you don’t have to spend if you can choose a friendlier environment for the parts of the system that don’t strictly need to live inside FileMaker at all.
Author’s note. Everything above is my own interpretation of what was shown in the Claris Community Live #49 broadcast, and it reflects my personal opinion. I may have misread a point or drawn the wrong conclusion somewhere — if you spot anything you’d read differently, I’d welcome your insights.