Here is a failure that has nothing to do with intelligence.
Ask a well-grounded AI assistant to create a Spark rule in SkySpark. It knows Axon. It has the function library indexed. It writes you clean, syntactically valid code — and hands back one record.
A working Spark rule needs two: a func record holding the detection logic, and a sparkRule record configuring how and where the rule applies. They have to agree with each other. Miss the second and nothing errors — you simply have a rule that never fires, on a site you believed was being monitored.
No amount of syntax knowledge prevents that. It is not a language problem. It is a procedure problem, and procedure is the half we have been leaving out.
What a workflow actually is
A workflow is a markdown file. That is the whole trick.
It carries a little frontmatter so it can be catalogued, then plain prose and tables that describe how to do one thing properly:
---
title: Create Spark Rule
description: Step-by-step guide for creating a Spark rule with func and sparkRule records
category: fault-detection
tags: [spark, rule, fault, automation]
version: 1.0
---
Both MCP servers load every .md in their workflows/ directory at boot and expose them over the Model Context Protocol as readable resources under a workflow:// URI. The assistant does not have to be told they exist — it can list them, search them, and pull the full text on demand, mid-task.
Fantom MCP Server watches that directory. Drop a new file in, and it becomes available without a rebuild or a restart.
The two catalogues today
Fantom MCP Server — 13 workflows, covering the build-and-maintain side:
ai-coding-loop · api-migration-reference · connector-workflow · create-pod · create-skyspark-extension · explore-code-relations · haxall-basics · haxall-coding-standards · haxall-methods-workflow · skyspark-4x-migration · unit-testing · use-fanr · xeto-spec-guide
Axon MCP Server — 10 workflows, covering the analytics-and-operations side:
app-creation · axon-func-update · axon-lang-information · curRule-computed-points · html-email-skyspark · job-status-check · recform-template-design · spark-rule-creation · task-subscriber-permissions · visualytik-mcp-authoring
Twenty-three files. That is the entire encoded procedural memory of this toolchain right now — and it is nowhere near enough.
What a good one looks like
The flagship example is ai-coding-loop, which teaches an assistant how to change code without letting the index rot underneath it. The server's structural memory spans 240+ projects and 156K+ functions; an edit that is not reindexed makes every subsequent search subtly wrong.
The rule the whole loop hangs on is one sentence: after every code change, call reindexChangedFiles on the paths you touched. Re-parse, rebuild the graph nodes and edges, re-embed. Skip it and the next semantic search answers from a codebase that no longer exists.
Notice what that workflow is not. It is not documentation of an API — the tool descriptions already do that. It is the order of operations, the thing that is obvious once someone tells you and invisible until they do.
That file also carries a line worth stealing: "Verified live on 2026-06-10 against sedonaWebEditor." A workflow with a verification date is a workflow you can trust or retire. One without is a rumour.
Why this is the bottleneck
The instinct is to assume better models close this gap. They do not, and it is worth being precise about why.
A model's weakness in this domain is not reasoning and increasingly not syntax — grounded indexes handle syntax. The weakness is that procedural knowledge in building automation was never written down in a form anything can execute. It lives in the heads of a few thousand practitioners worldwide, and it transfers by apprenticeship: you learn that a Spark rule needs two records because a senior engineer watched you ship one that didn't fire.
That transfer mechanism does not scale, and it does not survive people changing jobs. Every integrator re-derives the same procedures independently. The same afternoon is lost, in parallel, in a dozen companies.
A workflow is that apprenticeship moment, written once, executed by every assistant on every project from then on.
Why it has to be the community
Here is the part I cannot do alone, and neither can any single company.
The people who hold this knowledge mostly do not write servers. The engineer who knows the correct commissioning order for a rooftop unit, or which curRule pattern actually holds up on computed points, is a controls person — not a TypeScript developer. If contributing required a pull request against an indexing engine, their knowledge would stay where it is.
It does not. A workflow is a markdown file. Frontmatter, a heading, the steps in order, the traps. If you can write down how you do it, you can contribute one.
The economics are absurdly in our favour. A workflow takes an afternoon to write. It then saves an afternoon for every engineer who would otherwise have re-derived it — across every company, indefinitely. There are few places in software where the leverage is that lopsided.
And the domain is too small to fragment. Building automation is not web development; there is no army of contributors coming. If the people who know Sedona, Haxall, Axon and Xeto each keep their procedures private, everyone keeps paying the same tuition. Twenty-three files is what a handful of us managed. Two hundred, reviewed and dated, would change what a newcomer can do in their first week.
The honest risks
A workflow catalogue is not automatically good, and pretending otherwise would set this up to fail.
A wrong workflow is worse than no workflow. An assistant follows it confidently and produces a confidently wrong result. Missing procedure at least produces hesitation; bad procedure produces bad commissioning. Review matters more here than in most documentation.
Workflows go stale, silently. SkySpark 4.0 changed the extension format and invalidated real procedures overnight. A workflow does not notice that it has aged. Hence version: in the frontmatter and, better, an explicit verification date and the project it was last checked against.
Scope discipline. A workflow that tries to explain everything teaches nothing. The good ones do one job — create this thing, migrate that thing, keep the index fresh.
None of these argue against the approach. They argue for review, dating and re-verification being part of it from the start rather than bolted on at two hundred files.
Come build the catalogue
Both servers are source-available, and the workflow directories are the easiest possible place to start:
- FantomMcpServer —
workflows/, 13 files, build-and-maintain - AxonMcpServer —
workflows/, 10 files, analytics-and-operations
The gaps are not subtle. There is no workflow for BACnet point naming conventions, none for commissioning a chiller plant sequence, none for the half-dozen Haystack tagging decisions that every project re-litigates.
If you know one of those procedures — genuinely know it, including where it goes wrong — that is a workflow, and right now nobody has written it down.
Bring it to the forum, where the working groups coordinate, or open a pull request against either repository. A markdown file is a low bar on purpose.
More on how these servers work: Axon MCP Server · cross-language code intelligence · the Sidecar fleet and the RLM.