DEV Community: Kin Lane

What 253 Enterprises Are Actually Investing In (Hint: It's Not Just AI)

Kin Lane — Fri, 24 Apr 2026 13:19:20 +0000

If you read the trade press, every enterprise on earth is doing exactly one thing right now: AI. Every keynote, every analyst note, every LinkedIn post says the same thing. AI-first. Agent-native. Foundation-model-powered.

So we went and looked at what enterprises are actually spending money on. Not what their CMOs are saying. What their engineering orgs are hiring for, contributing to, and buying. And the answer is more interesting than the hype cycle gives it credit for.

How we measured

Naftiko Signals profiles 253 enterprise companies by reading the engineering signals that cost real money: job postings, open source contributions, SaaS portfolios, standards participation, and tooling choices. Marketing is cheap. Headcount is not. A company that has been hiring for a capability for eighteen months is telling you something a press release cannot.

We bucket those signals into 44 areas of technology spanning the full stack — AI, cloud, data, APIs, integrations, security, governance, observability, platform engineering, and the rest. Then we count: out of 253 enterprises, how many show meaningful investment in each area?

Here is what came back.

The top of the list

Rank	Area	Companies	%
1	Artificial Intelligence	253	86%
2	Active Directory	253	86%
3	Electronic Data Interchange	252	86%
4	Deep Learning	252	86%
5	Data	252	86%
6	Machine Learning	251	85%
7	Operations	249	85%

Read that list again. AI is tied for first — with Active Directory. And one rank below both of them, holding 86% of the enterprise market, is EDI. The protocol your grandfather used to send purchase orders.

This is the story the hype cycle refuses to tell.

What it actually means

Three things jump out of this data, and none of them are the thing the analysts are selling.

AI is real, but it is not alone at the top. Yes, 86% of enterprises are investing in AI, ML, and Deep Learning. That part of the narrative is true. What is missing from the narrative is that the same enterprises are investing — at the exact same intensity — in identity infrastructure, B2B document exchange, and operational tooling. The boring stuff did not go away. It got more important, because every AI initiative eventually has to authenticate against Active Directory and exchange data with a partner over EDI.
The unglamorous layers are load-bearing. Active Directory at #2 and EDI at #3 are not legacy footnotes. They are the substrate every shiny initiative runs on top of. When 86% of large enterprises are still actively investing in EDI in 2026, that is not technical debt — it is the operating reality of how business actually moves between organizations. Anyone selling an "agent-to-agent commerce" vision that does not have an EDI story is selling a slide deck.
"Data" is the silent winner. "Data" as a category sits at 86%, alongside Deep Learning and Machine Learning. Enterprises figured out a long time ago that AI without data infrastructure is a demo, not a system. The investment in pipelines, governance, and storage matches the investment in models — because it has to.

What the hype cycle gets wrong

The dominant story of 2026 is that AI is reshaping everything and the rest of the stack is along for the ride. The signals say something more honest: AI is being layered on top of a stack that enterprises are still actively maintaining and growing. The directory service is not going away. The EDI gateway is not going away. The operational tooling is not going away. They are getting more investment, not less, because the AI layer increases the demands on all of them.

If you are building for enterprises, this matters. A product that assumes the legacy substrate is dissolving will lose to a product that assumes it is thickening. Because the data says it is thickening.

Why this is visible at all

The reason any of this is visible is that we stopped relying on what enterprises say and started reading what they do. Job postings are a leading indicator of investment. OSS contributions are a leading indicator of internal capability. SaaS portfolios are a leading indicator of architectural strategy. Standards participation is a leading indicator of interoperability commitment. None of these are secret. They are just unaggregated.

Signals aggregates them. Every company we profile is an open YAML file in a Git repository. Every signal definition is open. Every ranking is reproducible. If you disagree with how we classified a company, you can submit a PR.

What to do with this

If you are an operator inside an enterprise: use this list as a reality check on your own roadmap. If your AI strategy assumes EDI and AD are someone else's problem, the other 86% of enterprises disagree with you.

If you are building software for enterprises: the boring categories at the top of this list are where the buyers are. The fastest path to relevance is connecting the new layer (AI, agents, MCP) to the substrate (identity, EDI, data, ops) — not pretending the substrate is gone.

If you are trying to make sense of the market: stop reading press releases. Read the signals. They are open.

Try it

Platform: signals.naftiko.io
Browse the areas of technology view to see the full ranking across all 44 signal groups
Browse the radar to see how each area sits across Adopting, Optimizing, Evaluating, and Watching

The hype cycle tells you what enterprises want you to think they are doing. The signals tell you what they are actually paying people to build. Those are not the same list — and the gap between them is where the real opportunities live.

Stop Writing Integration Code. Write a Spec Instead.

Kin Lane — Tue, 21 Apr 2026 19:03:35 +0000

Most enterprise integration work follows a familiar pattern. A team needs to connect system A to system B. A developer writes a client, adds authentication, shapes the response, exposes it somewhere. It works. It ships. Within a sprint it starts drifting from whatever documentation existed. Within a quarter, three other teams have written their own version of the same integration with different assumptions.

This is not a tooling failure. It is a methodology failure. The integration intent — what to consume, how to shape it, what to expose — was never captured in a durable, inspectable artifact. It went straight into code and started drifting immediately.

Spec-Driven Integration

Let me talk for a little bit about Spec-Driven Integration (SDI), and why it provides a new way to look at how we integrate.

Spec-Driven Integration (SDI) is a methodology that treats the specification as the primary integration artifact. Not documentation. Not generated code. The executable definition itself.

A capability specification declares:

What upstream APIs are consumed (base URIs, authentication, resources, operations)
How data is shaped (input parameters, output extraction via JSONPath)
What is exposed downstream (REST endpoints, MCP tools, Agent Skills)

The specification is complete enough to execute directly. An engine reads it at runtime, handles HTTP consumption, data transformation, format conversion, and protocol exposure. No code generation. No compilation.

naftiko: "1.0.0-alpha1"

capability:
  consumes:
    - type: http
      namespace: payments
      baseUri: https://api.internal.company/v2
      authentication:
        type: bearer
        token: "{{PAYMENTS_TOKEN}}"
      resources:
        - name: transactions
          path: /transactions
          operations:
            - name: list-transactions
              method: GET
              outputParameters:
                - name: transactions
                  type: array
                  value: $.data

  exposes:
    - type: mcp
      port: 3001
      namespace: payments-tools
      tools:
        - name: list-recent-transactions
          description: "List recent payment transactions"
          call: payments.list-transactions
          outputParameters:
            - type: array
              mapping: "$.data"

That YAML is the integration. Run it in a container. The MCP tool is live on port 3001.

Why Code Generation Creates Drift

The common objection is: "We already generate code from our OpenAPI specs." Code generation moves the specification one step away from execution. The generated code becomes the artifact that runs, not the spec. The moment someone modifies the generated code — to add a retry, to shape a response, to handle an edge case — the spec and the implementation diverge. Drift is reintroduced.

I am looking for SDI to avoid this entirely. The spec IS what executes. There is no intermediate code artifact that can diverge.

The SDI Workflow

Specify — Write a YAML capability spec capturing the integration intent
Validate — Lint and analyze for completeness before execution
Execute — Run the engine. No build step. No code generation.
Refine — Evolve the spec based on production feedback

This cycle keeps the spec primary. What is deployed always matches documented intent because they are the same artifact.

Why This Matters for AI

AI agents need structured contracts to reason about. An agent can parse a capability spec, understand what tools are available, what inputs they require, and what outputs they produce. It cannot do the same with custom integration code spread across multiple repos.

When the spec is the integration, AI agents can:

Discover available capabilities by reading specs
Call tools reliably because the contract is deterministic
Propose spec refinements based on usage patterns
Validate consistency without reverse-engineering code

SDI is not just a cleaner way to build integrations. It is the prerequisite for AI agents to use your integrations reliably. What I like about SDI, is it takes what we have been investing in for the last decade and helps me integrate AI into existing operational workflows I've worked hard on for years.

Read the full methodology | Explore the Naftiko Fleet

A Big Four Firm Just Ranked #1 in API Investment. Ahead of Every Tech Company.

Kin Lane — Thu, 16 Apr 2026 14:32:01 +0000

At Naftiko, We track technology investment signals across 292 companies at Naftiko — APIs, AI, cloud, data, security, governance, automation, integrations. Scored and ranked.

EY ranks number one. Not among professional services firms. Across all 292 companies. Ahead of Citi, UnitedHealth, Morgan Stanley, Cisco, Visa, Nvidia, and Alphabet.

An accounting firm. Number one.

The numbers

EY scores 2,603 points. The professional services sector overall:

EY: 2,603 (22.8% of sector)
Accenture: 2,022
Booz Allen: 1,447
McKinsey: 1,435
KPMG: 1,200
PwC: 1,155
Bain: 991
Deloitte: 572

EY leads every category. APIs, AI, cloud, data, security, governance, services, integrations, containers, observability. Broad, deep, consistent.

Why professional services is ahead

Technology as a sector scores 44,840 points — but across 49 companies (avg 915 each). Professional services scores 11,425 across 8 companies (avg 1,428 each). Per-company investment density is 56% higher than technology.

The reason is structural. Professional services firms don't build one product. They build integration and transformation capabilities for every client, across every industry. A single firm like EY needs competency in financial services data platforms, healthcare interoperability, manufacturing automation, retail personalization, and energy management — simultaneously.

They also sit at the intersection of business strategy and technical implementation. They wire SAP to Salesforce, connect Workday to Azure AD, build data pipelines from Oracle to Snowflake. Their API and integration investment is not aspirational. It is operational.

What EY is doing differently

Cloud and data are the foundation. Cloud (219) and data (222) are where enterprises build the platforms AI agents will consume. EY is investing in the substrate.

Governance is a differentiator. 92 points — significantly ahead of the field. For an audit and compliance firm, this makes strategic sense. But it also positions them for AI agent governance.

Security is the highest in the sector. 139 points. In a world where AI agents are about to get API access to enterprise systems, security investment is the prerequisite for adoption.

Why this matters for developers

The professional services investment pattern maps directly to what AI agent infrastructure needs:

Discover and inventory APIs across environments with hundreds of services
Govern API access with identity propagation, policy enforcement, and audit trails
Compose capabilities from existing APIs into reusable units of work
Observe what agents are doing and whether integrations work

Professional services firms are the most integration-intensive organizations on the planet. They are investing accordingly. The question is whether the rest of the enterprise world catches up before the agents arrive, or after. For me, this is counter to what I read about professional services companies in mainstream team press, that they are irrelevant and going away.

You can explore the full signals data and run governed AI capabilities yourself using the open-source Naftiko Fleet. Feel free to email me personally at kinlane@naftiko.io if you have any questions.

Making Your APIs Visible Using Capabilities for GitHub 7 GitBook Discovery and Documentation

Kin Lane — Wed, 15 Apr 2026 21:26:40 +0000

Your organization has more APIs than anyone thinks. Specs are scattered across GitHub repos. Docs exist in GitBook spaces that were created for a launch and never updated. Some APIs have specs but no docs. Others have docs but no specs. A handful have neither.

This is the API visibility problem, and it's universal. GitHub and GitBook are both excellent platforms. The gap is the workflow between them.

Capabilities

Naftiko capabilities — each a portable YAML file that consumes the GitHub and/or GitBook APIs and exposes MCP tools for the workflows that documentation writers and governance teams need. No code generation, no SDK, no platform subscription.

Discovery

Helping you with your API discovery.

GitHub OpenAPI Scanner — scans every repo in a GitHub org for OpenAPI/AsyncAPI specs
GitBook Space Auditor — checks spaces for completeness, staleness, missing descriptions
API Documentation Gap Analyzer — compares GitHub specs vs GitBook docs, finds gaps in both directions
Documentation Coverage Scorer — measures what percentage of API operations are documented

Here's the scanner:

naftiko: "0.5"
info:
  label: "GitHub OpenAPI Scanner"
  description: "Scans GitHub organization repositories for OpenAPI and AsyncAPI specification files, building an inventory of every API definition across the org."
capability:
  exposes:
    - type: "mcp"
      namespace: "spec-scanner"
      tools:
        - name: "scan-org-for-specs"
          description: "Scans all repositories in a GitHub organization for OpenAPI and AsyncAPI specification files."
          inputParameters:
            - name: org
              in: query
              type: string
          steps:
            - name: search-openapi
              type: call
              call: "github.search-code"
              with:
                q: "org:{{org}} filename:openapi"
                per_page: 100
            - name: search-asyncapi
              type: call
              call: "github.search-code"
              with:
                q: "org:{{org}} filename:asyncapi"
                per_page: 100
  consumes:
    - namespace: "github"
      type: "http"
      baseUri: "https://api.github.com"
      authentication:
        type: "bearer"
        token: "{{github_token}}"
      inputParameters:
        - name: "github_token"
          in: "environment"
        - name: "Accept"
          in: "header"
          value: "application/vnd.github+json"
        - name: "X-GitHub-Api-Version"
          in: "header"
          value: "2022-11-28"
      resources:
        - name: "code-search"
          label: "Code Search"
          description: "Search for code across repositories"
          path: "/search/code"
          operations:
            - name: "search-code"
              method: "GET"
              label: "Search Code"

And here's the gap analyzer that compares both platforms:

naftiko: "0.5"
info:
  label: "API Documentation Gap Analyzer"
  description: "Compares API specifications discovered on GitHub against documentation published in GitBook to identify undocumented APIs and orphaned docs."
capability:
  exposes:
    - type: "mcp"
      namespace: "gap-analyzer"
      tools:
        - name: "compare-specs-to-docs"
          description: "Searches GitHub for API specs and GitBook for documentation spaces, then compares the two to identify gaps."
          inputParameters:
            - name: org
              in: query
              type: string
            - name: gitbook_orgId
              in: query
              type: string
          steps:
            - name: find-github-specs
              type: call
              call: "github.search-code"
              with:
                q: "org:{{org}} filename:openapi"
                per_page: 100
            - name: find-gitbook-spaces
              type: call
              call: "gitbook.list-spaces"
              with:
                orgId: "{{gitbook_orgId}}"
  consumes:
    - namespace: "github"
      type: "http"
      baseUri: "https://api.github.com"
      authentication:
        type: "bearer"
        token: "{{github_token}}"
      inputParameters:
        - name: "github_token"
          in: "environment"
        - name: "Accept"
          in: "header"
          value: "application/vnd.github+json"
      resources:
        - name: "code-search"
          label: "Code Search"
          path: "/search/code"
          operations:
            - name: "search-code"
              method: "GET"
              label: "Search Code"
    - namespace: "gitbook"
      type: "http"
      baseUri: "https://api.gitbook.com/v1"
      authentication:
        type: "bearer"
        token: "{{gitbook_token}}"
      inputParameters:
        - name: "gitbook_token"
          in: "environment"
      resources:
        - name: "org-spaces"
          label: "Organization Spaces"
          path: "/orgs/{{orgId}}/spaces"
          inputParameters:
            - name: "orgId"
              in: "path"
          operations:
            - name: "list-spaces"
              method: "GET"
              label: "List Spaces"

GitHub → GitBook

Keeping your repos in alignment with what teams do in Gitbook.

GitHub-to-GitBook Spec Publisher — fetches specs from GitHub, creates GitBook spaces
API Catalog Publisher — aggregates multi-repo specs into a browsable GitBook collection
OpenAPI GitBook Uploader — uploads specs to GitBook's native interactive API viewer
API Changelog Publisher — generates changelogs from spec diffs, publishes to GitBook

Here's the publisher capabilty:

naftiko: "0.5"
info:
  label: "GitHub-to-GitBook Spec Publisher"
  description: "Discovers OpenAPI specifications in GitHub repositories and publishes them as structured documentation in GitBook spaces."
capability:
  exposes:
    - type: "mcp"
      namespace: "spec-publisher"
      tools:
        - name: "publish-spec-to-gitbook"
          description: "Fetches an OpenAPI spec from a GitHub repo and creates or updates a GitBook space with the spec content."
          inputParameters:
            - name: owner
              in: query
              type: string
            - name: repo
              in: query
              type: string
            - name: spec_path
              in: query
              type: string
            - name: gitbook_orgId
              in: query
              type: string
            - name: space_title
              in: query
              type: string
          steps:
            - name: fetch-spec
              type: call
              call: "github.get-file-contents"
              with:
                owner: "{{owner}}"
                repo: "{{repo}}"
                file_path: "{{spec_path}}"
            - name: create-space
              type: call
              call: "gitbook.create-space"
              with:
                orgId: "{{gitbook_orgId}}"
                title: "{{space_title}}"
                visibility: "public"
        - name: "batch-publish-org-specs"
          description: "Scans a GitHub org for all OpenAPI specs and publishes each to a GitBook space."
          inputParameters:
            - name: org
              in: query
              type: string
            - name: gitbook_orgId
              in: query
              type: string
          steps:
            - name: find-specs
              type: call
              call: "github.search-code"
              with:
                q: "org:{{org}} filename:openapi"
                per_page: 100
            - name: list-existing
              type: call
              call: "gitbook.list-spaces"
              with:
                orgId: "{{gitbook_orgId}}"
  consumes:
    - namespace: "github"
      type: "http"
      baseUri: "https://api.github.com"
      authentication:
        type: "bearer"
        token: "{{github_token}}"
      inputParameters:
        - name: "github_token"
          in: "environment"
        - name: "Accept"
          in: "header"
          value: "application/vnd.github+json"
      resources:
        - name: "repo-contents"
          label: "Repository File Contents"
          path: "/repos/{{owner}}/{{repo}}/contents/{{file_path}}"
          inputParameters:
            - name: "owner"
              in: "path"
            - name: "repo"
              in: "path"
            - name: "file_path"
              in: "path"
          operations:
            - name: "get-file-contents"
              method: "GET"
              label: "Get File Contents"
        - name: "code-search"
          label: "Code Search"
          path: "/search/code"
          operations:
            - name: "search-code"
              method: "GET"
              label: "Search Code"
    - namespace: "gitbook"
      type: "http"
      baseUri: "https://api.gitbook.com/v1"
      authentication:
        type: "bearer"
        token: "{{gitbook_token}}"
      inputParameters:
        - name: "gitbook_token"
          in: "environment"
      resources:
        - name: "org-spaces"
          label: "Organization Spaces"
          path: "/orgs/{{orgId}}/spaces"
          inputParameters:
            - name: "orgId"
              in: "path"
          operations:
            - name: "list-spaces"
              method: "GET"
              label: "List Spaces"
            - name: "create-space"
              method: "POST"
              label: "Create Space"
        - name: "openapi-specs"
          label: "OpenAPI Specs"
          path: "/spaces/{{spaceId}}/openapi"
          inputParameters:
            - name: "spaceId"
              in: "path"
          operations:
            - name: "upload-openapi"
              method: "POST"
              label: "Upload OpenAPI Spec"

GitBook → GitHub

Now let's go back the other way from GitHub to Gitbook.

GitBook-to-GitHub Spec Centralizer — extracts docs from GitBook, commits to a central GitHub repo
Multi-Repo Spec Consolidator — consolidates scattered specs into one canonical repo

Governance

Now you can govern things because you know where the APIs are.

GitBook-GitHub Doc Sync — bi-directional sync, detects drift
API Doc Freshness Monitor — flags stale documentation before consumers notice
GitBook Change Request Reviewer — PR-style review for documentation updates
GitBook Collection Organizer — organizes spaces into domain-based collections
API Style Guide Enforcer — validates docs against style guidelines, creates fix requests
GitBook Search Indexer — cross-space search, duplicate detection

Here's the style guide enforcer — it searches for banned terms and creates change requests for fixes:

naftiko: "0.5"
info:
  label: "API Style Guide Enforcer"
  description: "Validates API documentation in GitBook against organizational style guidelines."
capability:
  exposes:
    - type: "mcp"
      namespace: "style-enforcer"
      tools:
        - name: "search-for-banned-terms"
          description: "Searches for terminology that violates the style guide."
          inputParameters:
            - name: gitbook_orgId
              in: query
              type: string
            - name: banned_term
              in: query
              type: string
          steps:
            - name: search-content
              type: call
              call: "gitbook.search-content"
              with:
                orgId: "{{gitbook_orgId}}"
                query: "{{banned_term}}"
        - name: "create-style-fix-request"
          description: "Creates a change request to track a style violation fix."
          inputParameters:
            - name: spaceId
              in: query
              type: string
            - name: violation_summary
              in: query
              type: string
            - name: fix_description
              in: query
              type: string
          steps:
            - name: create-cr
              type: call
              call: "gitbook.create-change-request"
              with:
                spaceId: "{{spaceId}}"
                subject: "{{violation_summary}}"
                description: "{{fix_description}}"
  consumes:
    - namespace: "gitbook"
      type: "http"
      baseUri: "https://api.gitbook.com/v1"
      authentication:
        type: "bearer"
        token: "{{gitbook_token}}"
      inputParameters:
        - name: "gitbook_token"
          in: "environment"
      resources:
        - name: "search"
          label: "Search"
          path: "/orgs/{{orgId}}/search"
          inputParameters:
            - name: "orgId"
              in: "path"
          operations:
            - name: "search-content"
              method: "GET"
              label: "Search Content"
        - name: "change-requests"
          label: "Change Requests"
          path: "/spaces/{{spaceId}}/change-requests"
          inputParameters:
            - name: "spaceId"
              in: "path"
          operations:
            - name: "create-change-request"
              method: "POST"
              label: "Create Change Request"

How it works

I am not sure how you organization operates, and I tried to cover the bases.

Each capability is a Naftiko 0.5 YAML file that declares:

What APIs it consumes (GitHub, GitBook, or both)
What MCP tools it exposes*

All you do is point the Naftiko Framework at the YAML, and it serves live MCP tools, agent skills, and REST endpoints. The YAML is the runtime — no code generation required.

Why capabilities for this

The individual API calls are simple. The hard part is doing them consistently, across every repo and every space, over time. Manual processes don't scale. One-time audits go stale. Documentation sprints easily get deprioritized.

Capabilities make the workflow repeatable. Run them on a schedule, wire them into your CI, or invoke the MCP tools from an agent. The more alignment you can bring, the more likely you'll be governing the right things. You can't govern what you don't see.

The 5 Hardest Problems in Context Engineering Right Now

Kin Lane — Tue, 14 Apr 2026 18:55:46 +0000

Context engineering is not prompt engineering. It is an emerging discipline focused on optimizing context windows for AI agents, translating upstream APIs and MCP servers into efficient tool interfaces, and building evaluation frameworks for agent-API interaction quality.

If you are working with agents and MCP tools, you are probably running into these problems already. Here are the five we keep seeing.

1. No agent evaluation framework
You need to know whether your agent called the right API with the right parameters in the right order — not just whether the output text looks reasonable.

Most evaluation today stops at the surface. Did the LLM produce something plausible? That is necessary but not sufficient. An agent that returns a confident summary while calling the wrong endpoint with the wrong payload is worse than one that errors out, because the failure is invisible.

What we need: evaluation frameworks that inspect the actual state of upstream services after an agent acts. Did the record get created? Did the right field get updated? Was the sequence of API calls correct? This is integration testing for autonomous systems, and the tooling barely exists.

Compounding the problem: different models behave differently with the same tool definitions. What works on Sonnet may break on Opus. Evaluation needs to be model-aware.

2. Too many MCP tools
The MCP ecosystem is growing fast. The problem is that an agent with access to 40 tools performs worse than one with 4 well-designed tools.

Context windows are not infinite. Every tool description consumes tokens. Every similar-sounding tool creates decision overhead for the model. Context engineers need to consolidate sprawling API surfaces into minimal, precise tool interfaces.

This is the core design problem in context engineering: compression without information loss. You need to understand the upstream API semantics AND the downstream model behavior, then find the minimal translation between them. The right translation differs by model, task, and user intent.

What many teams ship:

list_users
get_user
create_user
update_user
delete_user
list_user_roles
get_user_role
assign_user_role
... (30 more tools)

What the agent actually needs:

query_resource (list, get, filter across entities)
mutate_resource (create, update, delete with validation)
manage_permissions (roles, assignments)

The consolidation is not mechanical. It is a design problem.

3. MCP workflows need embedded question formation
"Ask anything" interfaces sound great in demos. In practice, they fail when developers don't know what to ask.

This is the cold-start problem for MCP-powered copilots. A developer who asks the wrong question gets a confident-sounding answer to the wrong question — and might not realize it until something breaks downstream.

Context engineers are discovering that documentation layers need to embed question formation into the workflow. Instead of just answering the current question, the system should suggest the next question based on where the developer is in their workflow.

Think of it like this: traditional docs are a reference book. What agents need is a guided workflow that knows which page you need before you know to look for it.

4. Repos need minimum agent operational docs
Your repo looks well-documented. README, API docs, architecture decision records, inline comments. A human developer can onboard in a day.

An agent tries to run the test suite and fails immediately.

Why? Because "run the setup script" requires a human to infer which script, navigate to the right directory, set environment variables, and interpret error messages. An agent needs all of that explicit:

Which script (exact path)
What arguments
What environment variables must be set (and valid values)
What the expected output looks like
What to do when output doesn't match
Context engineers are defining "minimum agent operational documentation" — the baseline structured docs a repo needs before agents can reliably operate within it. This is not replacing human docs. It is a parallel, machine-readable layer.

The interesting side effect: making docs agent-consumable usually makes them better for humans too, because it forces you to close the gaps everyone was silently working around.

5. Markdown needs standardized structures

This is the most foundational problem and it affects everything else.

Most markdown is written for human readability: inconsistent heading hierarchies, ambiguous section boundaries, sections that depend on context from earlier in the document, formatting that prioritizes aesthetics over structure.

Agents need:

Consistent heading structures
Explicit section boundaries
Self-contained sections (no dependency on prior context)
Metadata indicating what kind of information each section contains

The gap between "human-readable markdown" and "agent-consumable markdown" is wider than most teams expect. Every MCP server serving markdown content, every copilot referencing project docs, every automated workflow reading a README is affected.

The common thread
These problems exist because infrastructure built for human-only workflows does not transfer cleanly to agent-augmented workflows. Context engineering is the discipline of building that translation layer.

At Naftiko, we are building the governed, spec-driven capability layer between enterprise APIs and AI agents. These are exactly the problems we are solving.

If you are running into any of these in your own work, I'd like to hear about it in the comments.

Naftiko Framework Alpha 1: Turning API Sprawl Into Governed Capabilities for AI

Kin Lane — Tue, 07 Apr 2026 23:16:57 +0000

I have been writing about API sprawl for fifteen years. The shape of the problem has not really changed — large enterprises now run an average of 1,295 SaaS applications and over 14,000 internal APIs, with AI-related APIs up 807% year over year — but the stakes have. The agents are here. They want to consume everything. And nobody has a clear story for how to give them safe, governed access to what already exists without rebuilding the world.

Today we are shipping the first alpha of the Naftiko Framework. It is Apache 2.0, declarative, Java-based, and built around one simple idea: your existing data and APIs are not technical debt. They are strategic inventory. They just need to be made discoverable, governed, and reusable as capabilities instead of scattered projects nobody can find.

This post is a walkthrough of what shipped, why the spec-driven integration approach matters, and what it looks like to actually build with it.

The problem: MCP sprawl on top of API sprawl

If you are reading dev.to, you have probably already lived this. The first MCP integrations go great. The second wave starts to feel a little ad-hoc. By the time you are wiring your fifth or sixth tool, you realize you are just re-creating API sprawl one layer up — except now the ungoverned thing is talking directly to a model that will happily call it a thousand times in a runaway loop.

The trigger symptoms are familiar:

MCP sprawl on top of API sprawl
Teams shipping prototypes, but nothing makes it to production
Security and compliance becoming the bottleneck
Costs that are impossible to predict (tokens, models, and upstream API usage)
Specs that "age like bananas"
You can't govern, secure, or reuse what you can't see

The honest answer is that the existing toolchain — API gateways, iPaaS, ad-hoc MCP servers — was not built for this. We need a different unit of work.

The unit: a capability

Naftiko's answer is the capability. A capability is a YAML file that declares two things: what it consumes (the upstream APIs it calls) and what it exposes (the surfaces it offers — MCP, Skill, or REST).

Here is a real example from the Shipyard tutorial:

naftiko: "1.0.0-alpha1"

capability:
  consumes:
    - namespace: registry
      type: http
      baseUri: "https://registry.shipyard.dev/api/v1"
      resources:
        - name: ships
          path: "/ships"
          operations:
            - name: list-ships
              method: GET

  exposes:
    - type: mcp
      port: 3001
      namespace: shipyard-tools
      description: "Shipyard MCP tools for fleet management"
      tools:
        - name: list-ships
          description: "List ships in the shipyard"
          call: registry.list-ships
          outputParameters:
            - type: array
              mapping: "$."
              items:
                type: object

consumes declares where the data lives. exposes declares what the agent sees. call: registry.list-ships is the wire between the two. The outputParameters block reshapes the upstream payload — renaming imo_number to imoNumber, dropping fields the agent does not need — so the model never sees the raw API surface.

That is the whole idea. The spec is the integration. Not a description of it, not documentation written after the fact — the actual runnable artifact. The Naftiko Engine reads this YAML at runtime and serves it as a live MCP server. There is no code generation step, no compilation, no drift between what is documented and what is running.

Spec-driven integration, in plain terms

The methodology behind this is what we are calling Spec-Driven Integration (SDI). It is the integration-domain cousin of spec-driven development, and it rests on a few principles that I keep coming back to:

Specifications as the lingua franca. The spec is the single source of truth. Maintaining an integration means evolving its spec. Everything else is derived.
Executable specifications. A spec is only valuable if it is precise enough to produce a working integration directly. If it cannot be executed as-is, the gap is a signal of incompleteness — not an invitation for interpretation.
Continuous refinement. Specs are linted, validated, and analyzed for ambiguity throughout their lifecycle, not at a single approval gate.
Bidirectional feedback. Production behavior feeds back into the spec. The spec is a living artifact, not a snapshot.

Why this matters for AI integration specifically: context engineering is fundamentally an integration problem. Agents need the right data, in the right shape, at the right time. When the spec is the artifact, agents (and the humans operating them) can reason about integrations, propose refinements, and validate consistency against a structured contract — instead of poking at opaque runtime behavior.

Four levels of progressive abstraction

Naftiko meets your APIs where they are. The framework introduces a four-level progressive abstraction model for consumed APIs, so you do not have to rip and rebuild anything:

Forwarding HTTP client — forward any HTTP call with shared endpoint behavior like authentication.
Templatized HTTP client — reuse predefined request collections imported from HAR, Postman, or similar formats.
Structured API client — abstract HTTP calls into clean web API paths and operations, enabling reuse across teams.
Functional MCP client — abstract structured APIs into MCP tools, resources, and prompts for context engineering and agent orchestration.

You can climb the ladder one capability at a time. Start by forwarding. Move to structured. Reach the top when it makes sense to. Nothing forces a wholesale rearchitecture.

What ships in Alpha 1

The alpha release covers three areas:

Right-sized AI context — declarative applied capabilities that expose Agent Skills, plus MCP support for Resources and Prompts alongside existing Tools support. The outputParameters story above is the key here: capabilities shape response payloads into smaller, typed outputs aligned to tasks instead of dumping raw provider complexity into a context window.
API reusability — lookups within API call steps, consumer authentication and permissions for API and MCP servers, reusable source HTTP adapter declarations across capabilities, and applied capabilities that compose multiple sources.
Core developer experience — published artifacts on Maven Central and Docker Hub, Javadocs on javadoc.io, a Naftiko Skill based on the CLI, a Spectral-based ruleset for spec governance, JSON structure validation, a GitHub Action template based on Super Linter, and a comprehensive wiki with FAQ, getting started guide, and roadmap.

Alongside the framework, the Naftiko Fleet Community Edition is also free. It ships with a VS Code extension for live structure and rules validation of capability YAML files, and Backstage templates that scaffold new capabilities and bootstrap their Git repositories. The Community Edition will always be free. Standard and Enterprise editions will add what large organizations need — SLAs, federation, continuous compliance, domain-level governance — but the framework itself stays open source.

Governance as guidance, not gatekeeping

One of the things I keep saying out loud in conversations with platform teams: governance has to be guidance, not gatekeeping. Naftiko's Spectral-based ruleset enforces 15 consistency rules at lint time, the VS Code extension surfaces them as you type, and the GitHub Action template runs them in CI. The point is to catch the things that matter — naming, schema, identity propagation, exposed contract shape — before a capability ships, not to slow anyone down with a review board.

When procurement eventually starts asking the question Sarah Guo predicts in her "Dark Code" essay — "what did your agents do with our data on a Tuesday in March?" — the answer is in the spec, the governance ruleset, and the engine telemetry. Not reconstructed from scattered logs after the fact.

Where this goes next

The roadmap is on the wiki. The short version:

Alpha 2 (May 2026) — A2A server adapter, MCP authentication and gateway integration, webhook server adapter, conditional / for-each / parallel orchestration steps, OpenAPI-to-Naftiko import tooling, a Control API accessible via CLI, and starter capability templates.
Beta (June 2026) — stable spec, resilience patterns (retry, circuit breaker, rate limiter, time limiter, bulkhead), MCP server-side code mode, expanded governance with tags and labels.
GA (September 2026) — production-ready v1.0 with full test coverage, stable spec, and JSON Schema published to JSON Schema Store.

Try it

This is an alpha. The spec will move. The edges are rough in places. But the core idea — that capabilities are the right unit, that governance is guidance not gatekeeping, that the producer-consumer relationship in API land has to be rethought for the agent era — that part I am clear on.

If you have spent any time thinking about MCP, AI integration, or how to give your security and compliance teams something better than a SOC 2 PDF, this is for you. Roll up your sleeves, pull the Docker image, walk through the Shipyard tutorial, and tell me where it breaks.

GitHub: github.com/naftiko/fleet
Wiki & docs: github.com/naftiko/fleet/wiki

I Wanted to Invite You to the Postman $100K API Hack

Kin Lane — Wed, 06 Jan 2021 04:39:30 +0000

Postman is an essential tool in my API development toolbox. I enjoy using it as an API client to onboard, test, and integrate with APIs, but I am also increasingly using it to also develop and automate with API. Since the release of Postman public workspaces in November I have been captivated with exploring what is possible with Postman when working with different, but more specifically what is possible when you automate and orchestrate with different APIs in a public workspace with public APIs—the possibilities are endless. What is cool about all of this is that I get paid do to this, and now you can too as part of the Postman $100K API Hack.

To help bring attention what is possible on the Postman platform we are putting on a hack challenge for the next 30 days, encouraging developers to build something cool with Postman and any APIs they think are interesting, useful, or just cool. Here are the details:

Hacking runs Jan. 5, 2021 (9 a.m. PST) to Jan. 25, 2021 (5 p.m. PST)
$100,000 USD in cash prizes
Read the official rules
Register for the Postman API Hack
Get help on the Resources page
Watch the winners announced on February 3, 2021, at Postman Galaxy

Everyone who registers as part of the hack will get a limited-edition Postman API Hack T-shirt, but we have designated four levels of prizes to award developers who put Postman to work in the most innovative and interesting ways.

1st Place, Intergalactic Grand Prize (1) - $25,000 USD awarded to the team with the best project
2nd Place, Andromeda Prize (1) - $15,000 USD awarded to the team with the 2nd best project
3rd Place, Nebula Prize (1) - $10,000 USD awarded to the team with the 3rd best project
Honorable Mention, Moonshot Prize (10) - $5,000 USD prize awarded to the next ten highest scoring entries following the Grand Prize, Andromeda Prize, and Nebula Prize

There are thirteen different ways you can get paid to build cool things with Postman, using any API you want, or series of APIs to design, integrate, automate, orchestrate, and build any API-driven solution you can think up—here is what you need to do to get involved with the hack.

Check out the official rules and FAQs for complete details
Join the hack
Register for the free Postman Galaxy API conference
Sign up for a Postman account, if you don’t already have one

To help get your imagination going we’ve posted some inspirational projects as part of the hack details. You can also find a list of 200+ workspaces for many different types of interesting APIs to help demonstrate what is possible when you use the right APIs. I’ll be helping judge the hack, so I can give you a little insight into what I will be looking for as part of the review process--I am looking for interesting usage of interesting APIs in a collaborative way. Meaning, spend the time to put just the right API or APIs to work in a way that delivers something useful or is just really cool. I am looking for developers to demonstrate they get APIs and they get Postman, and have done the hard work to solve a real world problem using APIs.

Alright, that is the scoop. I just wanted to invite you to our hack, and see what you can build. I am going to spend the next 30 days leading up to Postman Galaxy thinking about and talking about this hack. So, if you need any further inspiration or have questions about how to put the Postman feel free to reach out to me personally on Twitter at @apievangelist. I have a pretty deep knowledge of the different types of APIs available out there, and I enjoy pushing the limits of what is possible with the Postman platform. I am also not afraid to tell you your idea needs more work and point out the really interesting aspects of what you are building. So, consider this your official invitation to the hack, and to let you know I am here to help support you in your journey as you work to bring home one of the prizes. I look forward to seeing what you and your team builds, and having you part of the Galaxy conference in February.