what I did after I mapped 941 AI agent skills

==========
2026-06-12 · #nord #agents #systems #methodology #ndc

Earlier this month I mapped 941 AI agent skills to understand the landscape. The map answered the question I started with. It did not answer the harder one underneath. Which of these does NORD adopt as-is, and which do I need to build myself? That is the question I have been working on since.

The method I am about to describe is the one I developed to answer it. I am using it on our own work first because NORD is the test case. The methodology is what we would bring into another company if they asked us to help them codify how they actually run.

Pass one: the external landscape

Step 1. Filter. Not everything on the map is a candidate to build right now. I ranked the 941 entries by adoption priority, removed cross-listed duplicates, and excluded the official vendor MCPs and the official Anthropic skills. The criterion for exclusion was who maintains it, not who built it. That filtering pass produced 230 unique in-scope items.

Step 2. Decompose. Each of the 230 items is a package. A package is not comparable to another package because it bundles several capabilities together. I broke each one down into atomic capabilities, the smallest unit of "this thing does X." The 230 packages contained 2,544 atomic capabilities, about eleven per item.

Step 3. Cluster. Once everything is decomposed, you can compare across packages. I grouped the 2,544 atomic capabilities by what they actually do, not by what their authors named them. Vendors call the same function by different names, and the underlying behaviors overlap heavily. The 2,544 atomic capabilities collapsed into 48 capability clusters, plus a tail of items that did not group with anything else.

Step 4. Rule. For each cluster I asked four questions. Build it (we have a real need and no clean upstream source). Adapt it (something close exists; we modify it). Adopt it (something out there is good enough; we use it directly). Defer it (real, but not now). That ruling pass produced 49 candidate proprietary skills NORD would build itself.

That is the pass one funnel. 941 to 230 to 2,544 to 48 to 49.

One example of how a ruling actually shook out: ecommerce. There are mature ecommerce tools available; some are open source, some are subscription products. The cluster ruling was build, but as a family of variants, not a single skill. A core that handles the workflow, with per-platform implementations underneath. Each project we work on selects the variant that matches its stack. The ruling pass is rarely a clean yes or no. The interesting work is figuring out the shape.

Pass two: our own work

The 49 candidate skills were the output of decomposing other people's tools. They told me what NORD could build. They did not tell me how NORD should run. For that I needed to apply the same method to our own work.

We have a project lifecycle at NDC. Ten phases, seven gates, defined enforcement layers. I broke that down the same way. Each phase has its own work, its own owners, its own outputs. I cataloged every concrete responsibility against the same build, adapt, adopt, or defer frame. That pass produced 26 lifecycle skills NORD would build to support our own delivery.

Then I went one layer deeper. Inside each phase are tickets. Inside each ticket are tasks. I decomposed every task, named the owner (human and agent), listed the inputs, and named the NORD piece (skill, rule, MCP, or template) that would streamline it. That work is what I am calling the Task Atlas.

The Task Atlas has three profiles:

  • Product builds. The work we do on our own products.
  • Client engagements. The work we do for clients, from proposal to delivery to retainer.
  • Business operations. The recurring cycles that keep the company running.

Each profile has its own decomposed atlas. 214 task and gate nodes total across the three. Each profile has a master flow chart that shows the whole thing on one page.

Why I am doing this

The reason is not to make NORD a better internal tool. NORD is the test case. The method is the point.

A lot of the companies I see run on workflows that live in two or three people's heads. The systems on paper describe the work loosely. The actual decisions, the actual judgment calls, the actual sequence of who does what when, lives in tacit knowledge that nobody has written down. When the company tries to scale or hand off work, that tacit layer breaks. People leave. Quality drops. The owner becomes the bottleneck.

The decomposition method is how you fix that. You make the tacit layer explicit. You catalog the actual work. You decide which parts of it can be augmented by AI without losing the operator's judgment. You build the system around the work people already do, not on top of it.

I am running it on NDC first because I cannot honestly bring a method into another company that I have not used on my own. The artifacts I am producing (the catalog, the lifecycle decomposition, the Task Atlas) are the proof that the method generates real, usable work. When we bring this into another company, we will not be selling a methodology. We will be applying one we already trust.

If this is your situation

If you run a company whose workflows live mostly in your head and the heads of a few people around you, and you suspect that turning that into a system would unlock more than another hire would, this is the kind of work we do.

Write to me. d@dsmith.ink.