Why FileMaker Needs a Real Text Standard for Humans, IDEs, and AI Agents
I recently gave another presentation about ai2fm.com, .fmscript, and the future of FileMaker development in the age of AI agents.
This one was different.
The first presentations introduced the idea: yes, we can copy FileMaker scripts out of Script Workspace, work with them in VS Code, let AI agents inspect or improve them, and paste the result back into FileMaker.
That alone is useful. But it is not the real story.
The real story is deeper:
FileMaker needs a deterministic text bridge between Script Workspace and the modern software world.
Not a toy exporter.
Not a lossy printout.
Not raw XML dumped into an LLM.
Not “AI, please guess what this FileMaker script should look like.”
A real bridge.
A bridge that humans can read.
A bridge that IDEs can understand.
A bridge that compilers can validate.
A bridge that AI agents can use without hallucinating the shape of FileMaker scripts.
A bridge that can round-trip back into FileMaker.
That bridge is .fmscript.
And this is why we built it.
The First Rule: Do Not Confuse AI With Deterministic Software
Before talking about AI in FileMaker, we have to draw a hard boundary.
AI is probabilistic.
Classic software is deterministic.
These two things are not enemies. They are not mutually exclusive. They are not competing religions. But they are different tools, and when we confuse them, we create bad systems.
A calculator does not need an LLM to tell us that 2 + 2 = 4.
A deterministic program can calculate that instantly, cheaply, and reliably. An AI model has to reason, predict, generate, and return the most probable next tokens. That is not the correct tool for simple calculation.
This matters because a lot of “AI for software development” discussions begin from the wrong place. They treat AI as if it should replace every part of the system.
It should not.
The right pattern is simpler:
Use AI where probability helps. Use deterministic software where correctness matters.
Use AI to help reason about a script.
Use AI to propose improvements.
Use AI to document logic.
Use AI to detect missing error handling.
Use AI to explain legacy code.
Use AI to suggest a transaction-safe structure.
But when the final output must become a valid FileMaker script, do not ask the AI to guess XML.
Use deterministic software.
That is the heart of ai2fm.
AI can help create and refine the intent.
The compiler must produce the valid FileMaker result.
The Problem With “Just Print the Script”
When FileMaker developers first started using LLMs, the natural instinct was simple:
“Let me copy my FileMaker script and paste it into ChatGPT.”
The problem is that FileMaker Script Workspace is not a plain text editor. What we see visually in Script Workspace is only a rendered representation of a much richer internal structure.
So developers tried the available options.
Print the script.
Export the DDR.
Copy whatever text could be seen.
Paste that into an LLM.
The result looks readable, but it is not complete.
Important information is missing.
Some script steps look flat when printed, but internally they contain much more configuration. Steps such as Go to Related Record and Import Records are good examples. What appears visually as a simple line may hide window options, target behavior, file references, field mapping, import settings, or other internal details.
If that information is not present in the text, the AI cannot reason about it.
It does not matter how powerful the model is.
A model cannot preserve information it never received.
That is the first dead end:
Printed FileMaker script text is useful for humans, but it is not enough for deterministic round-tripping.
The Problem With “Just Copy the Visible Text”
There are newer tools that can copy the text rendered by FileMaker Script Workspace. That is better than nothing, and for some workflows it is useful.
But it still has the same structural limitation.
It copies what FileMaker is rendering.
It does not necessarily copy the complete internal script definition.
If FileMaker displays a simplified form of a step, then the copied text is also simplified. The missing data is not magically restored.
For a human reading the script, that may be acceptable.
For an AI agent editing the script, it is dangerous.
For a compiler trying to reconstruct the original FileMaker XML, it is not enough.
That is the second dead end:
Visible text is not the same thing as complete script data.
The Problem With “Just Use XML”
The next obvious idea is to use the actual FileMaker clipboard XML.
This seems correct at first.
The XML contains the real structure. It is what FileMaker expects. It can preserve the hidden information that printed output and visible text lose.
So why not just give that XML to an LLM?
Because XML is the wrong working surface for humans and AI agents.
FileMaker clipboard XML is verbose. Very verbose.
A script that is readable as 100 lines of human-oriented text may become hundreds or thousands of lines of XML. The model has to read it, parse it, maintain the structure, understand the user’s request, preserve all required tags, modify the correct part, and then return valid XML again.
That is expensive.
It is slow.
It is hard to review.
And because the structure is large and fragile, the chance of losing a tag, corrupting a reference, changing an attribute incorrectly, or returning invalid XML increases as complexity grows.
The human also has a serious problem: reviewing the result.
If an AI returns 500 lines of XML, how many FileMaker developers can confidently inspect that and say, “Yes, this is exactly the script I intended”?
Almost none.
Not because FileMaker developers are not capable, but because XML is not the language they use to think about FileMaker logic.
FileMaker developers think in script steps.
They think in transactions, layouts, fields, variables, loops, finds, commits, reverts, and error handling.
They do not think in raw clipboard XML.
That is the third dead end:
XML is structurally complete, but it is the wrong interface for human and AI development.
The Token Tax of XML
There is also a practical cost.
When we built ai2fm, we had to create what I call “monster scripts”: scripts containing all possible variations of all FileMaker script steps and their options.
This was not a toy test.
This was how we tested whether the transformer could handle real FileMaker complexity.
One monster script had around 1,320 steps. As .fmscript, it was large but still readable and manageable. As XML, it exploded in size.
That size matters.
Every extra token sent to an AI model has a cost. It costs money, but it also costs time. The model has to read it. It has to hold more context. It has to reason across a larger structure. It has to generate more output. And with each increase in size, the risk of structural error increases.
This is not theoretical.
In the presentation, I showed the difference using a token cost calculator. The same script represented as readable .fmscript had a tiny cost compared with the XML form. The XML version became dramatically more expensive for just one iteration.
Now imagine an agency doing this all day.
Copy script as XML.
Send XML to LLM.
Ask for a change.
Receive XML back.
Paste into FileMaker.
Find a problem.
Repeat.
That is not agentic development.
That is burning money to move text through the wrong format.
The point is not that XML is bad. XML is necessary. FileMaker uses it internally. We respect that.
The point is that XML should be the machine interchange format, not the human and AI working language.
Humans and AI agents need a better surface.
That surface is .fmscript.
What .fmscript Is
.fmscript is a universal textual representation of FileMaker scripts.
It is designed to be readable by humans, strict enough for compilers, and clear enough for AI agents.
It is not a casual pretty-print.
It is not just a Markdown representation.
It is not “whatever text the AI feels like writing today.”
It is a standard.
The goal is simple:
Represent FileMaker Script Workspace logic as deterministic text.
That means the text must preserve the information needed to reconstruct the FileMaker script. It must be stable. It must be predictable. It must be documented. It must be something a human can inspect and an AI can reliably generate.
This is the missing layer between FileMaker and the modern development ecosystem.
Once FileMaker scripts exist as real text, they can live in IDEs. They can be formatted. They can be validated. They can be linted. They can be documented. They can be compared in Git. They can be inspected by AI agents. They can be transformed back into FileMaker.
That changes the workflow.
FileMaker scripting stops being trapped inside a visual-only editor.
It becomes part of the wider software world.
Why AI Agents Need a Standard
AI models are language models.
That sounds obvious, but it matters.
A language model performs much better when there is an actual language to follow.
If we ask an AI to “write FileMaker script,” it has to guess the shape. It may imitate what it has seen in documentation, forums, examples, or previous conversations. Sometimes it will be close. Sometimes it will invent syntax. Sometimes it will produce something readable but not pasteable.
That is not good enough.
The answer is not to yell better prompts at the model.
The answer is to give it a grammar.
When an AI writes Python, it has a target language.
When it writes JavaScript, it has a target language.
When it writes SQL, it has a target language.
FileMaker scripting also needs a target language.
That is what .fmscript provides.
Instead of saying:
“AI, invent a FileMaker script for me.”
We say:
“AI, write FileMaker logic using this standard grammar.”
That is a completely different problem.
The first is guesswork.
The second is constrained generation.
And constrained generation is where AI becomes useful for serious development.
The Localization Problem
FileMaker has another unusual challenge: localization.
FileMaker Script Workspace is localized in many languages. Japanese FileMaker displays script steps in Japanese. French FileMaker displays them in French. German FileMaker displays them in German. The same is true across multiple supported locales.
That was a good market strategy.
It helped FileMaker enter local markets and made the product more approachable for users in those regions.
But from an engineering point of view, it creates a major problem.
Python is Python.
JavaScript is JavaScript.
SQL is SQL.
There is no Japanese Python.
There is no German JavaScript.
There is no French SQL dialect just because the developer’s operating system is French.
But FileMaker Script Workspace visually behaves as if there are many script languages for the same underlying logic.
That creates friction for humans, and it creates even more friction for AI.
An English-speaking FileMaker developer cannot easily read a Japanese FileMaker script in Script Workspace.
An AI agent trained mostly on English examples may not reliably understand localized step names.
A global community cannot build one shared corpus of script examples if every locale appears to be a different language.
So we solved the problem at the correct layer.
We do not rely on the localized displayed name.
We rely on FileMaker’s internal script step IDs and XML structure.
That means a Japanese FileMaker script can be copied, transformed into universal English .fmscript, edited in VS Code, and then pasted back into Japanese FileMaker, where FileMaker displays it again in Japanese.
That is not a translation trick.
That is the correct architecture.
The localized UI is a display layer.
The script identity is internal.
.fmscript uses the invariant structure, not the localized surface.
This gives us one universal FileMaker scripting standard for humans, IDEs, and AI agents.
The Demo That Matters
In the presentation, I showed FileMaker running in Japanese.
The script steps were Japanese.
I copied the script, went to VS Code, transformed it, and the script became English .fmscript.
That alone is useful.
But the important part came next.
I changed a value in the text. Then I transformed the .fmscript back and pasted it into Japanese FileMaker.
The script was Japanese again.
The changed value was preserved.
That is the “holy grail” workflow:
- Copy from FileMaker Script Workspace.
- Convert to universal
.fmscript. - Work in VS Code.
- Let humans and AI agents inspect, edit, and document.
- Convert back.
- Paste into FileMaker.
- FileMaker renders it in the user’s local language.
The AI does not need to know Japanese FileMaker.
The English-speaking developer does not need to read Japanese script steps.
The Japanese FileMaker user does not lose the localized experience.
Everyone works through the same universal standard.
That is why .fmscript matters.
The VS Code Layer
Once FileMaker scripts become text, we can use proper development tools.
That is where the ai2fm VS Code extension comes in.
The free extension gives FileMaker developers a real editor experience for FileMaker scripts:
- syntax highlighting
- formatting
- autocomplete
- hover documentation
- side documentation
- validation
- squiggles for errors
- structure folding
- color-banded blocks
- support for modern VS Code-compatible editors
For developers who have lived inside FileMaker Script Workspace for twenty or thirty years, this is a paradigm shift.
In Script Workspace, we click.
Click, click, click.
That is the muscle memory.
In VS Code, we type. We use snippets. We use shortcuts. We use formatting. We use agents. We use extensions. We use Git. We use documentation panels. We use keyboard-driven workflows.
That is not how classic FileMaker developers grew up.
But it is how the younger software generation works.
They know VS Code.
They know npm.
They know JavaScript.
They know TypeScript.
They know Python.
They know AI coding assistants.
Many of them do not know FileMaker.
This is a serious problem for the future of the platform.
If FileMaker stays isolated inside its own scripting UI, the next generation of developers will not naturally enter the ecosystem.
But if FileMaker scripts can exist as text inside the tools young developers already use, the bridge becomes possible.
That is not only a technical feature.
It is a survival path.
The Two Generations Problem
There are two groups we have to bring together.
The first group is the experienced FileMaker generation.
They know the platform deeply. They know layouts, relationships, context, portals, script triggers, privilege sets, imports, finds, transactions, and all the odd details that only come from years of building real systems.
But many of them have never needed VS Code.
They did not need extensions. They did not need a terminal. They did not need Node.js. They did not need Git workflows.
FileMaker gave them a complete working environment.
The second group is the modern developer generation.
They know VS Code. They know Git. They know package managers. They know AI coding assistants. They know text-based development.
But they may not know FileMaker.
They may never have seen Script Workspace. They may not understand FileMaker context. They may not know why a layout matters for a script step. They may not know how much power is hidden in the platform.
If these two groups remain separated, FileMaker loses.
The older generation keeps the knowledge but struggles to adopt modern AI workflows.
The younger generation has the modern workflow but never enters FileMaker.
.fmscript and ai2fm are designed to connect these two worlds.
For the experienced FileMaker developer, VS Code becomes less alien because the language is still FileMaker.
For the modern developer, FileMaker becomes less alien because the script is now text in a familiar IDE.
That is why onboarding matters.
We cannot just say, “Install VS Code and good luck.”
We need step-by-step tutorials.
Download VS Code.
Install it.
Create a folder.
Trust the folder.
Install the extension.
Create a .fmscript file.
Use formatting.
Use snippets.
Copy from FileMaker.
Paste into VS Code.
Transform back.
Test in FileMaker.
This is basic for a web developer, but not basic for many FileMaker developers.
So we document it.
Patiently.
Step by step.
Because the question “I installed it, now what?” is not a stupid question.
It is the real onboarding problem.
Why We Still Use the Clipboard
Some people will say:
“The clipboard is old technology.”
Yes.
Of course it is.
But it is also the reliable bridge FileMaker gives us today.
We are not religious about the clipboard. We are not trying to stay there forever. We use it because it works now.
The long-term direction is deeper automation.
FileMaker’s newer tooling around Save a Copy as XML and upgrade workflows suggests a future where scripts and other objects can be patched more directly. That would allow a developer to work in VS Code, let agents iterate, and then push changes into FileMaker without manual copy and paste.
That future is interesting.
But we have to be honest about the current state.
In our testing, the current automation path is not yet reliable for everything. Some objects work better than others. Base tables, fields, table occurrences, relationships, and layouts may behave more predictably. But script updates are still problematic. The tool may report that a script was updated while the script remains unchanged. It may add. It may delete with caution. But reliable script updating is not fully there yet.
So today we use the clipboard.
Tomorrow, when the automation layer becomes reliable, ai2fm can move deeper.
The important point is this:
The standard comes first.
Whether the transport is clipboard, XML file, API, upgrade tool, or some future FileMaker automation layer, we still need the same core thing:
A deterministic textual representation of FileMaker scripts.
Without that base, automation has nothing stable to build on.
Real Scripts, Not Toy Scripts
A common problem with demos is that they use toy examples.
A 10-step script.
A simple If.
A Set Variable.
A Show Custom Dialog.
A basic Go to Layout.
That is fine for introductions, but it proves very little.
Real FileMaker systems are not made of toy scripts.
Real systems have imports.
They have Go to Related Record.
They have transaction patterns.
They have window behavior.
They have field references.
They have layout context.
They have variables.
They have error handling.
They have old steps, new steps, renamed steps, deprecated steps, localized steps, and version-specific behavior.
So we tested against complexity.
We created scripts with all possible combinations and options for script steps. We built huge test files. We copied them out. We transformed them. We pasted them back. We found bugs. We reported bugs. We patched our transformer. We repeated the process.
That is the work behind the demo.
The demo looks simple because the tool hides the complexity.
But the complexity was not ignored.
It was absorbed into the deterministic layer.
That is why I do not want to show only easy examples.
Easy examples make everything look possible.
Hard examples reveal whether the system is real.
FileMaker 2026 Bugs We Found During R&D
During development and testing, we found several FileMaker 2026-specific issues.
These were not theoretical.
They appeared while testing real copy/paste and cross-version behavior.
One example involved AI-related script steps where FileMaker internally changed XML tag names between versions. In some cases, copying from FileMaker 2025 and pasting into FileMaker 2026 could silently lose information.
Silent loss is the dangerous part.
If a tool throws an error, at least the developer knows something failed.
But if FileMaker accepts the paste and silently drops configuration, the developer may continue working without realizing the script is now wrong.
Another issue involved a provider value. A step configured for Google could become OpenAI after copy/paste, because the default value was used instead of preserving the original provider.
Another issue involved a response target in a RAG-related action, where the target could disappear after copy/paste.
These are exactly the kinds of problems that only appear when you test the full surface area.
They also show why deterministic transformation matters.
If FileMaker itself changes internal XML names or behavior between versions, the transformation layer must understand those differences. It must normalize. It must preserve intent. It must adapt quickly.
Because ai2fm’s transformer is centrally controlled, patches can be applied immediately for everyone. Users do not need to wait for a new extension release just to receive a transformer fix.
That is not just convenience.
It is part of the reliability model.
When FileMaker moves the goalposts, the transformer can be patched.
Agentic FileMaker Development
The most important part of the presentation was not simply copying text back and forth.
The important part was the agentic workflow.
Once the script is in VS Code as .fmscript, AI agents can work on it like real code.
In the demo, I used multiple agents with different roles.
Claude created.
Codex reviewed and corrected.
Gemini documented.
That is not science fiction.
That is practical work.
The agents were not magically intelligent because they woke up one morning knowing my project. They were useful because they had context.
They were bootstrapped with plain documents. They knew the goal. They knew the format. They knew the role. They knew what we were trying to build.
This is the important lesson:
Agentic development is not about asking a random chatbot a random question. It is about giving agents the right working context and the right standard.
In the demo, I started from a small skeleton.
Open transaction.
Loop.
If.
With snippets and autocomplete, that structure appeared in seconds. Then an agent expanded it into a more complete script. Another agent reviewed it. Another documented it.
The result was not accepted blindly.
That is critical.
AI output is not production code just because it looks nice.
The human still reviews.
FileMaker still tests.
The compiler still validates.
The system still has to run.
But the speed of iteration changes dramatically.
Instead of manually typing a long script from scratch, we can have the agent produce a first pass. Then we ask another agent to inspect it. Then we ask another to document it. Then we paste into FileMaker, run it, test it, find the real errors, copy back, fix, and paste again.
That loop is where the productivity lives.
Not in one perfect AI answer.
In many fast, cheap, inspectable iterations.
The Correct Role of the Human
There is a phrase people like to use: “human in the loop.”
Most of the time it is vague.
In this workflow, it is concrete.
The human decides the intent.
The human defines the business rule.
The human knows the FileMaker solution.
The human knows whether the script makes sense.
The human tests the final behavior.
The human accepts or rejects the result.
The AI agents assist.
They generate.
They inspect.
They document.
They suggest.
They catch mistakes.
They accelerate the loop.
But they do not replace the architect.
The architect is still the human.
That is especially important in FileMaker, because FileMaker scripting is not just syntax.
FileMaker scripts depend on context.
The current layout matters.
The found set matters.
The relationship graph matters.
The privilege set matters.
The window matters.
The transaction state matters.
The table occurrence matters.
An AI agent that does not understand context will produce dangerous FileMaker scripts.
That is why .fmscript alone is not enough.
We also need project context, onboarding documents, examples, standards, and agent instructions.
But .fmscript is the foundation.
Without it, the agent has no reliable language to write in.
From Single Script Editing to Solution Analysis
The current workflow already allows a developer to copy one script, edit it in VS Code, and paste it back.
That is useful.
But it is only the beginning.
Once we can read FileMaker XML reliably, we can analyze entire solutions.
Not one script at a time.
All scripts.
All tables.
All relationships.
All calculations.
All references.
All dependencies.
This opens the door to tools that can show interconnections across a FileMaker solution.
Where is this field used?
Which scripts call this script?
Which layouts depend on this table occurrence?
Which calculations reference this field?
Which scripts interact with external files?
Where are imports defined?
Where are AI steps configured?
What breaks if we rename this?
FileMaker has always had metadata, but much of it has been hard to use in modern workflows.
Save a Copy as XML changes that.
ai2fm builds on it.
The future is not only “paste one script.”
The future is full solution intelligence.
Readable.
Searchable.
Visual.
Agent-friendly.
Developer-friendly.
That is where this goes.
Why This Matters for FileMaker’s Future
FileMaker is a powerful platform.
That is not the problem.
The problem is that the software world around FileMaker has changed.
Developers now expect text.
They expect version control.
They expect IDEs.
They expect AI coding assistants.
They expect documentation on hover.
They expect autocomplete.
They expect linting.
They expect automation.
They expect repeatable workflows.
FileMaker has its own strengths, but if it remains isolated from those expectations, it becomes harder to bring new developers into the ecosystem.
This is not about making FileMaker become JavaScript.
It should not.
FileMaker has its own model. Its own strengths. Its own development style.
But FileMaker does need a standard textual bridge.
That bridge allows FileMaker to remain FileMaker while participating in modern development.
This is the key point:
The future of FileMaker is not to abandon FileMaker.
The future is to expose FileMaker logic in a form modern tools can understand.
That is what .fmscript does.
The Practical Workflow
The workflow we are building is simple:
- Write or copy a FileMaker script.
- Transform it into
.fmscript. - Work on it in VS Code or another compatible editor.
- Use autocomplete, snippets, formatting, documentation, and validation.
- Ask AI agents to create, review, improve, or document.
- Transform the result back to FileMaker XML.
- Paste it into FileMaker.
- Test it in the real FileMaker solution.
- Iterate.
This workflow respects both worlds.
It respects FileMaker because the final script still runs in FileMaker.
It respects modern development because the working surface is text.
It respects AI because the model gets a grammar instead of raw XML noise.
It respects humans because the result is readable.
And it respects correctness because the transformation is deterministic.
That combination is the point.
The Future Is Not One Agent
Another important lesson from the demo is that the future is not one AI assistant doing everything.
Different agents can have different roles.
One agent can generate.
One agent can review.
One agent can document.
One agent can test assumptions.
One agent can explain a legacy script.
One agent can create onboarding notes.
One agent can compare two versions.
This is how serious agentic development will work.
Not one magic box.
A coordinated workflow.
But coordination requires shared context.
That context cannot be hidden inside a proprietary visual editor.
It has to be available as text.
It has to be documented.
It has to be stable.
It has to be readable by humans and machines.
Again, we return to the same foundation:
.fmscript.
Local AI Also Has a Place
During the Q&A, we also discussed local AI.
Not every workflow has to use cloud agents. Developers can run models locally using tools such as LM Studio, Ollama, or Unsloth Studio. With the right VS Code extension, a local model can be connected to the IDE and used without sending code to a cloud provider.
That matters for privacy, cost, experimentation, and learning.
Local AI is not magic either.
You need hardware. A proper GPU helps. VRAM matters. The first prompt may be slow because the model has to load and warm up. Smaller models may be faster but less capable. Larger models may reason better but require more resources.
But the important point is this:
A local model can also learn a standard.
If .fmscript is documented, structured, and available in an agent-friendly way, then local AI can use it too.
That means this work is not tied to one provider.
Not OpenAI.
Not Anthropic.
Not Google.
Not any single cloud.
The standard is the stable layer.
Agents can change.
Models can change.
Editors can change.
The standard remains.
The Claim We Can Prove
I do not like making claims that cannot be proven.
That is why the work behind ai2fm has been so heavy.
We tested complex scripts.
We tested all script steps.
We tested localization.
We tested copy/paste.
We tested cross-version behavior.
We found FileMaker bugs.
We patched transformer issues.
We responded to community reports.
We kept reducing the gap between “nice demo” and “production tool.”
The claim is not “AI will magically build your FileMaker system.”
That is nonsense.
The claim is more practical:
FileMaker scripts can be represented as deterministic text, edited in modern IDEs, understood by AI agents, and transformed back into FileMaker with high fidelity.
That is the claim.
That is what ai2fm is built to prove.
And that is what .fmscript is being created to standardize.
Why the Standard Comes Before the Product
A product without a standard becomes a private trick.
A standard creates an ecosystem.
That distinction matters.
ai2fm is a tool.
.fmscript is the language layer.
fmscript.org exists because FileMaker developers need something bigger than one extension, one editor, one model, or one vendor workflow.
A standard gives everyone a target.
Tool builders can build around it.
AI agents can learn it.
Developers can read it.
Documentation can reference it.
Examples can use it.
Training material can teach it.
Future automation can depend on it.
That is how we move from isolated hacks to a real development ecosystem.
The point is not to own every tool.
The point is to define the bridge.
Once the bridge exists, many tools can cross it.
What This Means in Plain English
For FileMaker developers, this means:
You can keep your FileMaker knowledge.
You do not need to become a JavaScript developer overnight.
You do not need to abandon Script Workspace.
You do not need to trust AI blindly.
But you can now bring FileMaker scripting into a modern IDE and let AI agents help where they are useful.
For modern developers, this means:
FileMaker becomes more approachable.
Scripts are no longer locked inside a visual editor.
You can see logic as text.
You can use tools you already understand.
You can learn FileMaker through a familiar workflow.
For AI agents, this means:
Stop guessing.
Use the standard.
Generate .fmscript.
Follow the grammar.
Respect the structure.
Let deterministic software handle the transformation.
For the FileMaker ecosystem, this means:
There is a path forward.
Not by throwing away what made FileMaker powerful.
But by connecting it to the tools and workflows that define modern development.
This Is Not About Replacing FileMaker
This work is not about replacing FileMaker.
It is about unlocking FileMaker.
For decades, FileMaker developers have built serious business systems with a development environment that is fast, practical, and deeply integrated.
But the world has changed.
AI agents are here.
Modern IDEs are here.
Text-based workflows are here.
Version control is expected.
Automation is expected.
Standards matter more than ever.
FileMaker can participate in that world.
But not by sending raw XML to an LLM and hoping for the best.
Not by relying on lossy printed script output.
Not by pretending that visible text is enough.
And not by asking every AI model to invent its own FileMaker syntax.
The answer is a deterministic bridge.
A universal text format.
A standard.
.fmscript.
That is the foundation.
Once we have that foundation, the rest becomes possible:
AI-assisted scripting.
Multi-agent review.
Automatic documentation.
Cross-locale script editing.
IDE support.
Validation.
Formatting.
Round-tripping.
Solution analysis.
Future automation.
The future of FileMaker development is not “AI magic.”
It is something better:
Human intent, AI assistance, deterministic transformation, and FileMaker execution.
That is the workflow.
That is the bridge.
That is why we built ai2fm.com.
And that is why .fmscript matters.
