The elephant in the room?

​@itsmatt You’re not wrong about the shift—but you’re probably overcorrecting on what it means.

What you’re feeling is real: tools like Claude Code and Microsoft Copilot collapse a lot of “glue work” into fast, disposable code. That absolutely eats into the kind of ad-hoc, one-off workflows where FME used to shine. If your mental model of FME is “a faster way to script transformations,” then yes—AI agents are now competing directly with it.

But here’s the part that doesn’t hold up: the idea that this makes FME obsolete or that you’re heading toward irrelevance.

Where your argument is right

• Speed of prototyping has flipped
  AI agents are brutally efficient at “just do it” tasks. Writing Python + pandas + some spatial libs is often faster than assembling a workspace from scratch.
• Barrier to entry is collapsing
  Junior or non-technical users can now automate things that used to require an FME specialist. That will reduce demand for certain kinds of FME work.
• Cognitive shift
  You’re no longer rewarded for solving every small problem manually. That’s a real psychological loss if you used to enjoy that craftsmanship.

Where it breaks down

FME was never only just about speed—it was about reliability, transparency, and operationalization.

AI-generated scripts:

• drift over time
• lack clear lineage
• are hard to audit for now
• break silently in production for now

FME (especially with Flow) gives you:

• visual lineage (huge in enterprise + GIS contexts)
• repeatability and scheduling
• data governance compatibility
• team readability (not everyone reads Python well, even now)

AI is amazing at creating solutions. FME is still very strong at running them safely at scale.

The real shift (this is the important part)

You’re not being replaced—you’re being pushed up the stack.

The old role:

“Build the workflow”

The new role:

“Decide what should exist, validate it, and make it production-safe”

AI can generate 80% of a pipeline. But:

• Who ensures it handles edge cases?
• Who integrates it into existing systems?
• Who owns failures at 3 AM?

That’s still a human with experience—someone like you.

Why FME feels slow now

Because you’re comparing:

• AI → instant, disposable output
  vs
• FME → structured, production-ready workflows

That’s not a fair comparison. It’s like comparing a sketch to a building.

The real risk (and it’s not what you think)

The danger isn’t “FME dies.”

It’s:

You stay in “tool operator mode” while the world moves to “system designer with AI leverage.”

If you only define yourself as “the FME person,” then yes—that niche shrinks.

If you redefine yourself as:

• data workflow architect
• automation strategist
• AI-augmented problem solver

then you’re in a stronger position than most devs, because you already understand data pipelines deeply.

What would actually make us safer (practically)

• Lean into Python—not instead of FME, but alongside it
• Treat AI as your default builder, FME as your production layer
• Get comfortable reviewing and validating AI-generated code (this becomes a core skill)
• Think in systems, not tools

About your “FME agent” idea

You’re absolutely right:

An AI that can operate FME directly would be powerful.

That’s likely where things go:

• AI generating workspaces
• AI debugging them
• AI iterating inside tools like FME Flow

If that happens, FME doesn’t disappear—it becomes a backend execution engine.

Bottom line

You’re not imagining the disruption—but you’re aiming your fear at the wrong target.

AI didn’t just make coding easier.
It made building anything easier.

That doesn’t eliminate experienced people—it raises the bar for what “valuable” work looks like.

If you adapt, your 15 years of experience becomes more valuable, not less.

If you don’t, then yeah—it starts to feel like the walls are closing in.

P.S: I would not claim that these are my two cents! 

Happy FME:-) ing

SRG

​@itsmatt Thanks for putting into writing what I think is on a lot of people’s minds these days. 

I don’t think “FME is the new Cobol” just yet ;-) But I hear your arguments and we’ve had internal discussions in the same vein. It’s an interesting challenge, in particular when presenting FME to potential clients with more technical expertise than budget.

While you can definitely replace some workspaces with vibe-coded software, you’ll still face some very real challenges down the road. And for now I believe the longer the road, the bigger the challenges. Some of my own lessons learned include:

• There’s a real lack of predicitability in how AI handles edge cases (unless you’ve specifically planned for them) and no knowledge about the business aspects which a human developer would often take for granted
• As there is no collective memory of existing processes, AI tends to re-invent the wheel each time, sometimes with subtle and non-trivial changes in behavior. Just something as simple as establishing a parametrized database connection can be deceptively tricky and might be implemented in hundreds of ways. Which one will your AI coding agent use today?
• For getting predictable results and avoiding too much of a mess, you still need the mindset and some experience as a software developer, unless the task is trivial. Blindly trusting the output of AI is a recipe for problems than can be very difficult to resolve. A software developer might know a lot about coding, but do they also have deep domain knowledge about your GIS business workflows? FME empowers those with domain knowledge.
• FME is more than Form, and re-implementing the functionality of Flow using vibe-coded software, for it to run other vibe-coded software components, would still be a massive undertaking with a lot of risk. Yes, there are solutions like Airflow out there, but the barrier of entry is substantial, even with AI as support. Speaking of support, Safe is really in a league of its own.
• Quality testing is critical and time-consuming, and cannot be fully solved using AI-generated unit tests alone.

This is not to say that AI-generated coding does not solve real problems, but for the time being we are a long way away from saying it can fully replace established platforms like FME other than for relatively simple and isolated tasks. And, honestly, acquiring FME for only such use-cases is probably overkill anyway.

Regarding having proper AI skills to author and reason about workspaces, I believe that is something Safe is actively working on, and that would absolutely be a killer feature. I sincerely hope Safe can close this gap as soon as possible.

What I see in the meantime, is that the co-existence of established software like FME and custom scripts is increasingly important. To stave off the vibe coders, I believe FME could quickly gain a lot by improved integration with external workflows, in particular in the Flow ecosystem, already ideal for orchestration. There’s some really simple stuff that could be done to meaningfully improve how the FME platform co-exists with custom scripts, e.g. everything related to the SystemCaller:

In my opinion this is low-hanging fruit that would help proponents of vibe-coding to not see FME as competition, but as complementary.

My colleagues are slowly discovering these tools as well and can do a lot more themselves with AI, soon they wont need an FME guy to automate stuff

I think this is the scary bit tbh.  As they say, you don’t know what you don’t know. I look forward to finding more excel spreadsheets with latitude and longitudes that have been converted from British National Grid via an unknown transformation online. And that’s assuming they’ve got the x & y the right way round in the first place!

I don’t actually have any experience of using AI in FME as the environment i’m currently working in doesn’t have access to AI assist but I’ve been very disappointed with all the questions FME related I’ve asked other AI systems so far.  

How much of the work that you are talking about is spatial? 

• ​@itsmatt , I am quite happy that it will be easier to build pipelines and software, with population getting older, we need more productivity (at a reasonable environmental cost). Of course we will need to adapt. I just followed two software architecture courses and maybe we will end up working in bakeries but that’s life. 
  To complement on ​@david_r   points, my non AI 2 cents on our transition : 
  - If it is easier to build, there will be more pipelines, it does not necessarily mean that less people will be needed.
  - FME abstraction is quite good at forcing us to think modularly, not reinventing the wheel, etc... so we will still be needed to clarify domain experts needs (even without FME). 
  About FME as a platform, the vertical integration, readability etc... help but it is clear that rough times are coming. The speed*trust is still good for a production data process.
  For how long? No clue.
  
    

One of FME's biggest strengths that I don't think AI or coding agents can truly replace is the ability to visually see and understand your entire workflow as you build it. When you're working with complex data transformations, being able to see every connection, every transformer, and every data flow laid out in front of you is invaluable. While some code-based tools do offer pipeline visualization, they rarely match the granular, step-by-step transparency FME provides inside each transformation. With code, understanding what is truly happening within each element still requires developer-level expertise, which creates a significant gap for subject matter experts. And when something breaks in a complex pipeline, troubleshooting becomes exponentially harder without that visibility.

This is especially critical in industries where data accuracy and process integrity matter, like GIS, engineering, utilities, and logistics. A subject matter expert using FME can visually trace exactly where data is coming from, how it is being transformed, and where it is going. That level of transparency is not something you can easily replicate with code, especially AI-generated code that even the developer may not fully understand. Code-based solutions also constantly rely on external libraries, and frequent updates can break your entire pipeline. With FME, updates can occasionally introduce issues, but they are minimal compared to code-based solutions. And if a library becomes deprecated, you may need to rebuild your entire pipeline from the ground up if it was core to your solution.

AI and coding agents are great tools, and they will change how we work, but they do not replace the domain expertise and visual problem-solving that FME specialists bring. Companies also tend to underestimate the real costs of going the full-code route, including:

• Backend infrastructure setup and maintenance
• Developers needed to recreate legacy processes
• Managing integrations across existing and new systems

My longer-term concern is around critical thinking. The more we hand off complex problem-solving to AI, the more we risk losing the experienced human judgment that good data solutions depend on. AI is only as good as the people training it, and if those people stop developing deep expertise, the quality of what AI produces will suffer too.

Context matters enormously in this field. Humans naturally bring external knowledge into their decision-making, things like organizational history, business rules, and real-world constraints that are rarely fully documented. An experienced FME specialist doesn't just build a workflow, they make judgment calls based on years of accumulated knowledge that AI simply doesn't have. AI only knows what you explicitly tell it, and in complex data environments, what you leave out is often just as important as what you include. That gap is where things can quietly go wrong, and in ways that are hard to detect until it's too late.

FME is a platform built around making complex data workflows understandable, auditable, and maintainable. That is what makes it so special.

Matt, thank you for sharing this. There’s a lot of good stuff here but I don’t see any elephants! 😄

Your post is exactly the kind of post that gets us excited. With AI, everything is changing.

You’re absolutely right about programming. It has changed forever. I’ve even “written” code recently, although my assistant actually did it. And to be honest, I don’t always review it. The ground is shifting under all of us, and we all feel it.

We talked about this at Safe during our last all-hands meeting.  We looked at the arc from assembly code to writing every line yourself, to “vibe coding,” to a world where you simply specify outcomes and trust the system.

This isn’t just about coding. It’s happening to every role. I can’t remember the last time I created something entirely from scratch, including this response.

Where you’re spot on is this. AI has completely reset expectations around speed and effort. Once you’ve experienced an agent “just doing it,” anything slower feels slow and broken. That’s real, and we need to respond to it.

Where I think the picture is incomplete is the conclusion that the answer is moving away from FME toward raw coding in python with AI. I sense your frustration as to me it is clear what you really want is to be able to build workspaces for FME using AI.

AI is commoditizing coding. It doesn’t eliminate the need for problem solving, it amplifies it. When I used to code, the hard part was figuring out what to do. The coding was the mechanical part.  Enough time and effort and I could get it working.  Now, with AI knowing what to do is enough. AI can handle the rest.

With AI the value shifts to:

• orchestration
• reliability
• governance
• and most importantly, data

Today you can’t talk about AI without talking about data. And data is messy. It’s fragmented, secured, on-prem, in the cloud, behind APIs, and in formats no LLM has ever seen or can deal with. Some of it you can’t move. Some of it you aren’t allowed to expose. And yet AI wants all of it.

We’ve often described FME as a data pipe or nervous system connecting data to applications.
Now the most important applications are AI.

For me when you say you mainly use FME when it’s going into Flow, that’s actually a really important signal. It tells me that you're already gravitating toward orchestration. 

Here is what I think about what happens next:

• AI commoditizes the creation of FME workspaces
• Agents generate and refine them
• AI driven workflows run on an engine that can reach all your data, wherever it lives
• And that engine runs on-prem or in any cloud

We are actively working on what you described, a “coding agent that can speak FME.” You express intent, and FME artifacts are generated, ready to run or refine.

After all the engine is the product.

Everything else, Form, Flow, even AI, is about:

• generating “code” for the engine
• or exposing the engine through new services like Data Virtualization, and MCP

There is of course no rule that says that code has to be written by a human.

On MCP, we see a huge opportunity. FME is uniquely positioned to act as an MCP server, both on-prem and in the cloud, with the same stack. That means you can expose the right data to AI while keeping sensitive data secure.

I’ll also say this candidly:

FME as we know it today will change. It has to. This is a platform shift.

There will be winners and losers in this AI transition. The winners will be those who fully embrace AI. There is no halfway.

At Safe, we are all-in. Not as an add-on, but as a fundamental shift in how everything is built. Next week is our innovation week. Development stops and everyone focuses on building. AI will be front and center.

Please keep sharing posts like this. Fears, experiments, what’s working and what isn’t. This is exactly the conversation we need and enjoy as a community.

I believe what we’ll discover over the next few years, especially with MCP and agent-driven workflows, is that FME doesn’t disappear in the AI era.

It becomes one of the key ways AI connects to the entire world of data.

Do I feel uncomfortable at times? Absolutely.

But I also feel energized.

This is an incredible time.

I can’t wait to continue the conversation and see everyone in London.  Keep the discussion going. 

Thanks for kicking off this discussion ​@itsmatt! ​@donatsafe shared some more thoughts in this recent blog post: https://fme.safe.com/blog/2026/05/are-ai-coding-agents-replacing-tools-like-fme-lets-talk-about-it/

So I totally agree with these points around why platforms like FME still matter in enterprise environments:

• reliability

• auditability

• maintainability

• visual lineage

• governance

• scheduling/orchestration

• production safety

• debugging visibility

• team readability

• handling edge cases

Those things are massively important and they don’t just disappear because AI can suddenly write code really fast.

Where I somewhat disagree though is around the whole “AI generates 80% and humans validate the rest” thing. I think that really depends on what kind of 80% we’re talking about.

If AI is helping validate ideas, generate testers, SQL, regex, recommendations, troubleshoot stuff, suggest approaches etc then honestly that’s awesome. Human prompt -> inspect -> test -> refine. Massive productivity boost there.

But when it comes to really large complex production workflows, I’m not fully convinced that “AI builds it and humans inspect it” is always the better path.

Think about it this way... reviewing and understanding someone else’s huge workspace already takes a considerable amount of time. Understanding why it was done a certain way, testing assumptions, tracing logic, validating outputs etc. Sometimes for more complex stuff it’s actually more constructive and faster to build it the way you know how because you understand the intent and design decisions as you go.

And I still think even as AI improves, it’ll continue to struggle on the genuinely hard/complex tasks for quite a while. Humans are still better at making judgement calls, understanding context, spotting weird edge cases, and using AI almost like a sounding board to speed up problem solving. Could that eventually change? Maybe. But we’re definitely not there yet.

So for me the ideal world is still humans in the loop as the masters/chiefs, leveraging AI where it makes sense, staying in control, and producing robust deterministic processes that can actually be audited, understood, maintained, and trusted by organisations.

The other thing I worry about a bit is accidentally heading backwards.

Right now it’s great creating little mini tools and scripts with AI. But imagine a future where organisations end up with thousands of disconnected AI-generated scripts and automations, created by people who have long since left, all doing slightly different things with no consistency, governance, ownership, or visibility.

That starts looking a lot like the old data-silo world again... except now it’s AI scripting silos.

It actually reminds me a bit of the old “one system that can do it all” promise years ago. Big enterprise platforms came in replacing separate CRM systems, asset systems, mapping systems etc with the idea everything would live in one perfect ecosystem... and then over time a lot of organisations slowly drifted back toward specialised systems connected together because that reality worked better in practice.

In my mind AI feels a little bit like that right now.

We already have a really good structure:
FME acting as robust middleware, securely and safely connecting systems together, orchestrating processes, handling governance, visibility, reliability etc.

To me AI feels more like an extension and enhancement to that already great thing, rather than a replacement for the entire structure underneath it.

That’s my 2 cents at the moment anyway 😄

By the way, great idea having this kind of focus group/discussion!! Really interesting reading everyone’s thoughts on this because I think a lot of people are quietly thinking the same things right now.

The point ​@itsmatt  makes about wanting an AI agent with an FME skill is the one that stuck with me most:

I'd add one more layer to this: FME's built-in AI Assist is simply not available in all environments. Licensing constraints, security policies, air-gapped networks — a lot of us in the public sector or enterprise settings just don't have access to it.

So the idea of using an external AI like Claude with a dedicated FME skill isn't just a nice-to-have — for some of us it could be the only realistic option in the short term.

Has anyone in the community already built something like this? A Claude skill, an MCP tool, or even just a well-structured prompt for getting Claude or another agent to help author or debug FME workspaces? Would love to see it shared here if so. Feels like exactly the kind of thing this community could build together.

​@a.meshkat  I've explored this in quite some depth with Claude skills for authoring and debugging workspaces (mainly targeting Claude Chat and Claude Code; I don't trust Cowork's Claude in Chrome's ability to inspect browser console activity), and the honest takeaway is that it's very difficult to share the nuance of a skill and how personalized it becomes.

When you design any hyperspecific tool like this, it becomes entangled with your personal epistemology; that is to say, the information you prioritize, the weights you assign to different evidence, and the sense-interactive behavior you develop with the medium over time. I've built an intricate Claude skill for workspace authoring and debugging, and while it works well for me, I've noticed that adoption is difficult among those I've shared it with due to aspects of the design that are inherently tailored to how I personally rank and route information and where I want to intervene during LLM inference for human-in-the-loop. Moreover, software itself is in flux; FME ships newer versions with regressions and changes in behavior, so there are a lot of personal epistemological routes involved in ranking information over time. For example, a real reproduction in front of you carries more ordinal weight than a testimony or secondhand report. Skills need to be designed modularly to not only fetch information in a guided way, but to adapt around information that changes.

The central idea of a skill is RAG-based. The skill fetches documentation, summarizes it, and infers upon it: extracting the declarative knowledge from documentation and mapping it against the imperative execution (current observed behavior as described by you or OpenClaw/NemoClaw, etc.), creating an index card that updates with a direct evidential JSON body that helps the model make decisions but remains something tractable for you to steer if you notice it starting to drift. I've found that giving Claude or ChatGPT too much indirect supporting information is itself a source of hallucination. So I've been working on adaptive context loading using skill chaining, where a skill can chain to fetch additional information from its own subdirectories or from another skill entirely. I've designed my skills as file tree directories with tight context around topics, with the main SKILL.md file containing the routing logic to fetch specific context from .md files in the skill's subdirectories as needed for querying and information gathering.

Skill chaining opens a whole new avenue for building RAG context-loading pipelines. The idea is to get the model to start sequentially reasoning with summarized information/terms, using those information/terms to steer the next token prediction closer toward the desirable output. In practice though, I've found that monolithic skills (one SKILL.md with deep routing logic to fetch specific resources contained within the skill) with very tight routing logic to their subdirectory information perform much better than shallow skills that depend on chaining logic between coupled skills. The tradeoff is that the monolithic approach is harder to share due to the complexity in describing how it works and how to use it effectively; the shallow chaining pattern is much more intuitive for someone picking it up for the first time.

At the moment, creating skills using LLMs is quite handholdy due to the proclivities of the models favoring scripting languages (bash, Python) over word-based logic. You end up needing routing logic around how to fetch for better sources of information: transformer documentation, community forums, knowledge bases, and so on. And then you need to allow for validation using currently observed behavior described by you or by another means, such as OpenClaw. I've had great success with this Claude skill for authoring FME workspaces, but using it for complex debugging that sometimes arises from support tickets shows many of the limitations, especially when the model doesn't understand the underlying API that the FME GUI uses or recent changes in behavior.

Another headache is that skills optimized for one Claude model version perform differently on another. Skills designed for Cowork behave differently again. I've noticed that for RAG-heavy applications like this, Opus 4.6 is considerably better than its newer successors (other than Fable, which is its own story). Moreover, there seems to be a bias in how the model handles context depending on whether it is stored in a .md file or a text file.

One thing I have noticed with creating these intricate Claude skills, and conversing with how others design their AI-assisted workflows, is how prevalent tokenmaxxing tendencies are. At the moment, much of the web fetching capability is reserved for the frontier models, and the ones that have better RAG capabilities tend to be pricier when you start creating intricate workflows. I try to be mindful, but depending on the exploration you can easily fall into the trap. For example, I explored an application of providing a video capturing FME behavior to an LLM and having it extract frame by frame, documenting, and submitting a bug report; however, due to the verbose and hyperspecific descriptions (often not directly describing the intended behavior) it produces, it is not as scalable as I thought.

There is an accountability dimension to this as well. When dealing with sensitive data that cannot be passed to the model due to regulations such as HIPAA, you need to modify your AI workflow accordingly; a human can deterministically sanitize data, but relying on a probabilistic model to do the same seems counterintuitive for something legally binding. More broadly, making an LLM accountable for its output is very difficult. I'm sure you have encountered a situation where the LLM provides incorrect information and when you correct it, it responds with "You are absolutely right" and still makes similar mistake. Recognizing errors early and being able to steer before they cascade is critical, because cleanup costs compound quickly.

I do think much of the context loading could be achieved using locally hosted models with web-fetching reserved for frontier models, but it feels like many of us are constrained by the computing resources to meaningfully benchmark the required xB parameters for dependable agentic routing. Locally hosted LLM orchestration is where I think FME could really shine, since those models can be easily interacted with using FME's existing transformers; context management using stateful and stateless endpoints could be powerful for organizations that have limited computing resources. FME 2026.2 with the native looping and MCP server creation could be a whole new world of agentic AI workflows that can easily be explored by FME users. Thinking of the ability to create customized harnesses (prompts + MCP tool access) for LLMs to create scalable agents (AI agent = model + harness), I think this could usher in an interesting low-code perspective to creating complex agentic AI workflows.

Ultimately, striving to attain a technical mental model is most practical, especially for new users and juniors who probably have not developed a sound one yet. Low-code solutions such as FME provide a mechanism for this demographic to understand how the backend works and how to design integrations between infrastructure components without getting stuck on scripting syntax or losing the full picture (provided the solution is designed with modularity). While AI could teach you the theory or provide step-by-step tutorials on implementing solutions, I find retaining the technical knowledge difficult due to how easily it was acquired via LLM. And sure, you can ask an LLM to generate the entire function of a pipeline, but you won't understand it unless you have the technical literacy and the time to read the entire codebase.

​@davechoi Thank you for this. It's clearly the result of a lot of real experimentation, and I appreciate you writing it up in such depth.

If I understood correctly, the core message is: you've built something that works well for you, but it's become so shaped by your personal workflow and thinking that sharing it is genuinely difficult, not just technically but conceptually.

That itself is a useful finding. It suggests that a universal FME skill for Claude is probably not realistic right now, and that anyone attempting this will need to invest the time to build and tune it for their own context.

The data sensitivity point also resonates strongly for me. Working in a municipality, a lot of our geodata can't leave the on-prem environment, so any AI-assisted workflow needs to account for that from the start, not as an afterthought.

I'm curious: even if a full skill isn't shareable, would you be open to sharing the general structure or approach? The skeleton without the personal logic baked in. Even a starting point would lower the barrier for others who want to try building their own.

Trying to bring another perspective into this discussion….

If we take a step back and look at what has actually happened over the last 20 years:

• Millions of developers have shared knowledge, libraries and frameworks through Open Source.
• AI has now been trained on a significant part of that collective knowledge.
• As a result, coding itself is becoming increasingly commoditized.

This creates an interesting paradox:

The same Open Source movement that accelerated software development has also helped create AI systems that can now generate software at a scale no individual developer can compete with.

(Perhaps this is one reason why some really skilled developers are more skeptical of AI than others. Training AI models was probably not the primary ambition behind the Open Source movement...)
 

However, I actually see FME as an opportunity for Open Source developers to move up the value chain. As ​@donatsafe  pointed out, the value is shifting towards orchestration, reliability, governance and data.

Open Source developers are incredibly good at innovation at the core technology level. AI can amplify that innovation, but someone still has to invent the next breakthrough worth amplifying....

FME is incredibly good at governance and operationalization—enabling innovation at a higher level.
 

What excites me is the possibility of combining the two, rather than pitching them against each other.
 

Whether code is handwritten, AI-generated, vibe-coded, packaged in Python, exposed through MCP, or wrapped in a custom transformer becomes less important.
 

What matters is having a reliable platform that can orchestrate it, govern it, secure it and connect it to the right data.
 

Viewed from that angle, FME isn't competing with AI coding.

It's one of the few platforms where AI-generated functionality, proprietary and Open Source innovation can be orchestrated, governed, secured—and ultimately become production-ready.


….
(Side note: Historically, FME has been in similar situations before—admittedly not as dramatic as the current AI paradigm shift.

For instance, when XML was “new” and heavily hyped, there was widespread concern that traditional file formats would disappear, making FME obsolete.

The same happened when the Open Source movement really took off. People wondered what role FME would still have if Open Source tools could do the job.
 

And yet, here we are.
 

I think the reason is Safe Software's pragmatic DNA: recognizing the strengths of new technologies, embracing them, and adapting rather than resisting)

​@a.meshkat Apologies for slow response. Your understanding of my core message is correct! Describing the designs behind a skill is difficult because they're iterative and personal. I've explored many strategies, dropped some, refined others, and cannot fully inventory which ones survived. Sharing the reasoning behind those decisions is its own challenge; without similar experience to draw on, the context needed to effectively use or extend a skill compounds quickly.

That said, I can share the structural pattern I've settled on after many iterations.

```
Skill-Name/
├─ SKILL.md                            # Entry point: figures out what you need
├─ References/
│  ├─ resource_1.md                # Quick map of what's in each file (usually reserved for edge cases)
│  └─ resource_2.md
├─ SpecializationName1/
│  ├─ specialization.md            # Context/Instructions for a specific task type
│  └─ resource_3.md
└─ SpecializationName2/
   ├─ specialization.md             # Context/Instructions for another task type
   ├─ resource_url_registry.md
   └─ DomainName/
      ├─ domain.md                    # Deeper knowledge for a specific area
      ├─ resource_knowledge.md
      └─ SubdomainName/
         ├─ subdomain.md           # Most granular level knowledge for a very specific area
         └─ resource_urls.md
```

The entry point reads your prompt and decides which branch to follow. If the task is straightforward, it stops at the first or second layer. If it needs more specific knowledge, it keeps going deeper. The key idea is that it never loads everything; it only loads what's relevant. This keeps the AI focused and reduces the chance of it guessing when it should be referencing something specific.

For example, one of my skills (arcgis-troubleshooter) has Enterprise, AGOL, REST, ArcPy, etc. as specializations. Within the REST specialization, REST Services can be a domain covering supported endpoints, and a subdomain can contain information on FME's specific writer and the endpoint it uses. A workflow involving that writer in a prompt will invoke the skill and route to the particular context packets relevant to correctly configuring the writer using the error message.

If you're familiar with GIS, think of it like a tiered coded domain: the tier defines the available domain codes, and the domain code defines the available subtypes. You understand the dataset by understanding each level of that hierarchy. The skill works the same way.

One useful distinction I've noticed: some skills only need good examples to work well (the AI can generalize from patterns), while others need to pull in external documentation because the output depends on facts the AI shouldn't guess at. The example-driven skills are easier to build and share. The documentation-driven ones get more personalized over time, which makes them powerful for you but harder to hand off to someone else.

Hope this gives you a useful starting point!

I came to similar conclusions when building out a GIS MCP service as well. Base tools are mostly self explanatory but how to make an agent use them effectively (beyond demos) seems to require domain knowledge and skills/guides that are specific to a company, project or even individual. The skills tree structure you described helps to formalize that knowledge and get it to the agent in chunks, saving the context window for actual reasoning. What I’ve tried (and had some good success with so far) is giving the agent tools to create memory, guides and a distilled wiki of geospatial information that is generated over time and curated/distilled by another autonomous agent (like Karpathy’s LLM Wiki). Its centered around ArcGIS Portals/Services now but I’ll be adding FME services as well
 

Using a company analogy:

• Agent Memories are sticky notes. An agent mid-task jots down "layer 28 is the flood zone layer, FLD_ZONE uses code AE" in one second, no structure, no review. Raw, fast, sometimes wrong.
• Agent Guides are the official SOPs. Deliberately written playbooks ("how we do parcel due diligence"), editable and lockable by you. Human-curated, so they're the most trusted thing in the system.
• The Account Wiki is the auto-maintained intranet front page. A machine reads all the sticky notes, the SOPs, your projects, and your data sources, and compiles "here's what this company knows" — regenerated whenever things change. Nobody writes it directly (except pinned notes).

So the relationship is a refinery: memories are crude input, guides are certified product, and the wiki is the continuously re-distilled summary of both. When they conflict, trust flows down: guides > wiki > memories.

https://geoai.tools/