The Collective Is Online: How We Built ai2fm Together

Dimitris Kokoutsidis 16 mins0

From Launch to Reality

ai2fm.com is live.

That sentence looks simple, but it hides mounths of pressure, testing, failure, rebuilding, and one very important architectural decision: this project could not be built as a normal one-person software project.

Not because one person could not write code. Because the problem itself was larger than code.

FileMaker has always had a structural gap with modern AI development. AI works best with text. FileMakerโ€™s Script Workspace works through a protected visual interface and a strict clipboard XML format. That makes the development loop painful: you can ask an AI agent to improve a script, but getting that improved logic safely back into FileMaker has historically meant manual typing, fragile XML handling, or accepting failure as part of the workflow.

ai2fm was built to close that gap.

  1. Copy from FileMaker.
  2. Translate into readable .fmscript.
  3. Edit in VS Code, Cursor, Windsurf, Antigravity, Codium, or any compatible IDE.
  4. Use Claude, Codex, Gemini, Copilot, local LLMs, or your own workflow.
  5. Validate.
  6. Compile back into native FileMaker clipboard XML.
  7. Paste straight into Script Workspace.

That is the visible product.

But this post is not only about what ai2fm does. This is about how we built it. Because the method became as important as the product.

The Launch Signal

After launch, ai2fm reached developers from 28 countries.

That matters. Not as vanity. As validation.

A compiler is not proven by a clean demo. A compiler is proven when real developers throw ugly scripts, old habits, local quirks, incomplete references, edge cases, malformed assumptions, and production-shaped chaos at it.

That started immediately.

Veteran FileMaker developers tested it. Agencies tested it. Community members pushed the syntax engine. People reported issues. Some questioned the server-side transform model. Some stressed the clipboard path. Some found edge cases. Some asked for better autocomplete. Some forced us to clarify exactly what was free, what was licensed, and where the security boundary sits.

Good. That is how tools become real.

A product does not become trustworthy because the creator says it works. It becomes trustworthy when the community tries to break it and the system improves instead of collapsing.

https://www.youtube.com/watch?v=zg1LieGfHTU

The Real Architecture Was Not Only Technical

ai2fm has a technical architecture:

  • A free VS Code-compatible extension.
    • FileMaker-aware syntax highlighting.
    • .fmscript validation.
    • Autocomplete.
    • Hover documentation.
    • Autoformatting.
    • Clipboard type detection.
  • A licensed XSLT transform pipeline.
    • FileMaker XML to readable text.
    • Readable text back to native FileMaker clipboard XML.
    • macOS and Windows support.
    • A zero-retention transform model.

But behind that, another architecture was needed. A development architecture.

The project became too large for โ€œI remember where that file is.โ€ It became too large for loose local folders. It became too large for one AI agent holding context in one chat window. It became too large for mythology.

So we stopped treating the work as a folder. We turned it into an operating system.

The Four-Repo Structure

The Axelar AI Collective now operates through four private GitHub repositories, each with a clear responsibility.

AxelarEU/multi-agent

This is the coordination brain. It holds the operating contracts, shared-memory rules, API bootstrap material, onboarding notes, workflow discipline, and agent instructions. This is where an agent learns how to behave before touching the work.

Not โ€œbe creative.โ€ Not โ€œdo your best.โ€ But:

  • Read current state first.
  • Reuse existing task IDs.
  • Update the task when state changes.
  • Report using task IDs.
  • Do not duplicate work.
  • Do not invent invisible context.
  • Respect the security boundary.

AxelarEU/projects_v4

This is the Axelar Projects app. It contains the API endpoints, browser UI, schema-only SQL, app source, and documentation for the project management layer. It deliberately excludes live data, credentials, uploaded files, backups, runtime media, and logs.

That distinction matters. A repo should give agents enough structure to work safely. It should not become a careless archive of secrets.

AxelarEU/ai2fm-platform

This is the public and server-side ai2fm platform. It holds the public site, license manager, Node/Express API, Polar integration, transform endpoints, deployed XSLT work, and server-side behavior. This is where the commercial product lives.

AxelarEU/ai2fm-extension

This is the IDE and knowledge-base side. It contains the VS Code extension, FileMaker language support, FileMaker documentation, grammar references, and extension planning. This is where FileMaker becomes text-native enough for modern AI-assisted development.

Together, those four repositories describe the full operating surface.

  • Coordination.
  • Project state.
  • Platform.
  • Extension.
  • No magic paths.
  • No invisible v4/ folder assumptions.
  • No agent guessing which machine has the real file.

The Shared Memory Layer

Git stores code. Git does not store operational state well enough for multi-agent execution.

So the Collective uses the Axelar Projects API as the shared memory layer. That is where active tasks live.

  • Not in one chat.
  • Not in one machine.
  • Not in one agentโ€™s context window.
  • Not in someoneโ€™s memory.

Actual task records.

That one design choice changed everything. An agent can fetch a project, inspect tasks, check dependencies, update status, attach links, and leave handoff context. A task can move from Claude on Mac, to Codex on Linux, to Gemini or Codex on Windows, without the thread being lost.

The operating rule is simple:

  1. Read current state first.
  2. Reuse existing task IDs.
  3. Update the task when the state changes.
  4. Report using task IDs.

That is the difference between parallel guessing and coordinated execution.

The Security Boundary

The project also needed discipline about what must never enter Git. The new structure excludes credentials, live databases, runtime uploads, backups, logs, and real local runbooks.

Instead, it provides safe templates. For example:

  • db_connection.example
  • SESSION_RUNBOOK_TEMPLATE.md
  • .gitkeep placeholders for runtime folders

That may sound boring. It is not. Boring is good here. Security should be boring. Predictable. Explicit. Repeatable.

The rule is simple: Structure in Git. Secrets outside Git.

That is how you give AI agents enough context to work without giving them things they should never hold.

The Machines Came Into Alignment

The sync happened across the active development nodes.

Linux Codex created and pushed the curated projects_v4 baseline, then updated the coordination repo so agents would stop assuming that a loose local v4/ folder existed everywhere.

Windows Codex cloned and verified the new structure inside Google Antigravity.

Gemini aligned to the four-repo model and continued in its product and marketing role.

Mac Claude pulled the repos, corrected the ai2fm-extension agent contract, and marked old workspace-root bootstrap files as stale duplicates.

Then Linux pulled Claudeโ€™s correction.

At that point, the important thing was not that one agent had succeeded. The important thing was that the system had converged.

  • Linux.
  • Mac.
  • Windows.
  • Codex.
  • Claude.
  • Gemini.
  • GitHub.
  • Axelar Projects API.
  • One operating map.

That is when the project stopped depending on local folder mythology.

Why This Matters

A multi-agent project fails when context is local, implicit, or personality-bound. It succeeds when the structure survives:

  • a different machine,
  • a different operating system,
  • a different AI model,
  • a depleted context window,
  • a new agent joining the project,
  • a human stepping away and returning later.

That is what changed.

Before, the project had powerful agents. Now, the project has an organization.

Not a company. Not a fantasy. An operating structure.

A new agent can enter the system and learn:

  • where coordination lives,
  • where app source lives,
  • where platform source lives,
  • where extension work lives,
  • which files are authoritative,
  • which files are stale,
  • which task IDs matter,
  • which files must never be committed,
  • and how to leave the next agent a clean handoff.

That is not โ€œAI helping with a project.โ€ That is an AI development organization.

All of Us

I built ai2fm. But I did not build ai2fm alone.

That sentence matters. This was not one human pressing a button and watching magic happen. It was a coordinated system of human judgment, AI acceleration, community pressure, technical correction, security discipline, and constant feedback.

Codex wrote and refactored. Claude criticized and corrected. Gemini organized, framed, and helped position. The community tested, questioned, challenged, and broke assumptions. FileMaker developers from around the world brought the one thing no internal test suite can fully simulate: reality.

And I held the architecture together.

That is the honest answer. This is how we did it. All of us.

What Comes Next

The launch is not the end of ai2fm. It is the point where the real work becomes visible.

The immediate extension roadmap is already structured as shared tasks:

  • Task 51 โ€” build superset FileMaker language support into the extension.
  • Task 99 โ€” provide dropdown completions for enum-style script step options.
  • Task 100 โ€” sync hover-help knowledge base with official FileMaker documentation while keeping examples in .fmscript.
  • Task 101 โ€” rewrite the AI-facing grammar reference as positive โ€œdo thisโ€ guidance.

The important thing is not only that those tasks exist. The important thing is that every active agent can see them, understand them, continue them, and report against them from the same shared baseline.

That is the real unlock.

The Collective Is Online

ai2fm began as a bridge between FileMaker and AI.

It became something larger: proof that serious software can be built by a disciplined human-AI development system when context is treated as infrastructure.

Not vibes. Not scattered notes. Not โ€œthe agent probably remembers.โ€

Infrastructure.

  • A shared memory layer.
  • A clean repo topology.
  • Synchronized machines.
  • Explicit contracts.
  • Security boundaries.
  • Task IDs.
  • Community feedback.
  • Real users.
  • Real pressure.

And now, users from 28 countries.

The Collective is online.

  • Not finished.
  • Not polished.
  • Not mythologized.

Portable.

That is the milestone.

Dimitris Kokoutsidis

Related Articles

You May Have Missed