The question this post is for is the next one. What do you do when one MCP is not enough?
Every vendor MCP — Notion’s included — is shaped to expose the vendor’s full operational surface. That is the right default for the vendor. It is rarely the right default for an enterprise consuming that vendor through an agent. Four things you cannot do from a stock vendor MCP that you can do from a Naftiko capability over the same vendor:
A Naftiko capability that wraps the Notion API is a single YAML file. It declares which Notion tools you want to expose, how you want to shape the context that goes in, what governance tags the operation carries, and what telemetry it emits. It then exposes the result as MCP, REST, A2A, or an Agent Skill — same spec, multiple agent surfaces. Drop in a second capability that wraps Salesforce, or your internal capability over SAP, and you have a uniform fleet of agent-callable operations governed at the spec layer.
Notion’s MCP is the doorway. The capability layer is the building.
The first two paths are real. They will work for many teams. They stop working at exactly the point most enterprises hit this quarter — the second vendor MCP, the first compliance question, the first cost surprise, or the first time an agent calls a tool nobody knew was on the surface.
Vendor MCPs are going to keep shipping. Stripe, Slack, Adyen, Linear, Notion — the list grows every week, and the quality range across them grows with it. You should celebrate every one that ships. And you should also have a place to put them — one place — that gives you fine-grained tool control, declarative context, observability, governance, and the same shape across every other vendor MCP your fleet will consume in the next twelve months.
That place is a capability layer. That is what Naftiko does.
]]>We landed on it together.
Naftiko is an agentic asset manager.
I wrote it down. Then I sat with it for a few days. Then I tested it on three more conversations. Then I came back to write this post.
The phrase fits. It fits in a way the previous attempts — “AI integration platform,” “capability fleet,” “MCP governance layer” — never quite did. It explains who the buyer is, what the job is, why the job is new, and why the existing categories do not cover it. The rest of this post is the unpack.
Walk into any enterprise of meaningful size and ask who knows what software we are running, what it costs, who has access, and what we are not using. Somebody knows. Probably a small group of people inside IT, or finance, or a procurement office that sits between the two. They are running an asset manager — whether or not the budget line says “asset manager” — because the alternative is shadow IT, license waste, and audits that go badly.
Software asset management is a boring discipline. Nobody writes founder Twitter threads about it. But it is also one of the most consequential things an enterprise does, because the assets it covers — SaaS licenses, server capacity, database instances, integration platforms, internal services — are what the business actually runs on. Get the asset management wrong and you discover you have been paying $4M a year for Salesforce seats nobody uses, or that the customer support team is using six different competing tools because nobody knew the existing one was already licensed.
The discipline has a stable shape. There are roughly five things a real asset manager does:
Those five jobs have existed for decades. The IT organization has owned them, the finance organization has paid for them, and the procurement organization has enforced them.
Agents just became a new class of asset. The same five jobs apply.
The job is not interesting for SaaS licenses anymore — most enterprises have working tooling for that. The job is very interesting for agents, because every property that made traditional asset management hard is amplified for agent workloads.
Agents proliferate fast. A typical enterprise added new SaaS licenses at the rate of a dozen per quarter. The same enterprise is adding agents at the rate of dozens per week — once you count team-level pilots, embedded copilots inside tools they already license, and the side projects nobody told IT about.
Agents have non-obvious access. A SaaS license grants access to the SaaS itself. An agent grants access to whatever services the agent calls on the user’s behalf. The set of services an agent reaches is dynamic, runtime-resolved, and frequently invisible to the user, let alone to IT.
Agents have non-obvious cost. A SaaS seat costs a predictable monthly number. An agent’s cost is the model bill plus the token spend plus the upstream API spend plus the retry overhead plus the human cleanup time. Most enterprises do not have a single line of accounting that captures any of those, let alone all of them.
Agents have non-obvious risk. A SaaS seat has a known compliance posture — the vendor publishes a SOC 2 report, the legal team reviews it, the access is logged. An agent’s compliance posture is per-invocation. The same agent doing the same operation on the same data can be safe on Monday and out of scope on Tuesday depending on which upstream services it composed.
Each of these makes the traditional asset management discipline more important, not less. The set of jobs is the same. The amplification is what is new.
This is what Naftiko does, mapped to the five jobs.
Visibility. Every capability you run on Naftiko is declared — what it does, what it consumes upstream, what it exposes downstream, what cost it carries, what risk surface it lives in. The declaration is the registry. Ask “what agent-reachable surfaces do we have” and there is an answer. For the services you have not declared yet, Naftiko Signals reads the external footprint and gives you the inventory you have not built one for internally yet. Visibility from both directions — what you have declared and what we can see from outside.
Access management. Capabilities ship with allow-lists. Per-environment, per-agent, per-team. The same operation can be allowed for the marketing-team agent and disallowed for the customer-support-team agent, expressed declaratively, audited centrally.
Utilization. Every capability invocation is observable — cost, latency, success rate, retry rate. The capabilities nobody uses become visible the same way the SaaS seats nobody uses do. The capabilities that are being hammered become visible too, which tells you where the next investment should go.
Maximization. The whole capability framing is built around reusability. The job is to take the API the enterprise already paid for and make it agent-reachable once, then let every agent in the org reuse the same capability. No new vendor purchase needed for most of the agent’s job. That is maximization. Use what you have before you buy another.
Decommission. Capabilities have a lifecycle. The retired ones are recorded as retired. The agents that used them know they are gone. The credentials they held are revoked. The audit log carries the history. Nothing leaks because nobody remembered to clean up.
Five jobs. Same shape as the discipline that has worked for SaaS asset management for two decades. Different artifact — the capability instead of the license — but the operating bar is the same.
The reason this matters is not that “agentic asset manager” sounds cool. It is that the existing categories do not actually do the job.
MCP gateway. Routes agent traffic. Does not give you a registry, an access policy, a utilization view, or a cost view of the assets being routed. Necessary, not sufficient.
API management. Already exists. Already runs in most enterprises. Does not extend to the agent class of consumer, because the consumer model was designed for human-driven SDKs in 2014, not for autonomous agents in 2026. Necessary at the gateway layer, not sufficient at the asset-management layer.
LLM observability tools. Watch the model layer. Tell you what the prompt was and what the response was. Cannot see what the agent did between those two events when it called four upstream services and burned a lot of money doing it.
Software asset management tools. Manage licenses. Do not have a vocabulary for agents, capabilities, or the per-invocation cost shape an agent has.
Each of these is doing real work. None of them, alone or together, gives you the full asset-management discipline applied to the agent layer. That is the seat Naftiko is taking.
The buyer is the person in the enterprise who is already responsible for asset management at the SaaS or infrastructure layer, who is being asked to extend that responsibility to the agent layer and does not have a tool to do it.
In practice that is the CIO, the CTO, the Chief AI Officer, the head of platform engineering, or the head of integration depending on the org chart. The exact title matters less than the question they keep getting asked by the CEO and the board: what are our agents doing, what are they costing us, and are we safe?
If you cannot answer that question today, that is the gap. Naftiko fills it. That is the agentic asset manager.
Five jobs, same discipline, new class of asset. We have been running asset management on the rest of the stack for thirty years. Now we run it on the agents too.
]]>The week before that, I published twenty-one blog posts, ran a daily LinkedIn cadence, shipped a podcast episode, and sent a newsletter. The total reach across those channels was in the low six figures of impressions.
Three hours of conversation in a small room produced more pipeline movement than the week of broadcast did. Not by a little.
That is not a story about events being better than content. It is a story about the playbook the agent-era enterprise buyer responds to, and how it has quietly stopped looking anything like the playbook every startup blog has been telling us to run for twenty years.
For roughly the last two decades, the dominant instruction at the top of every startup go-to-market playbook has been some version of if it does not scale, do not do it. SEO scales. Paid acquisition scales. Content marketing scales. Webinars scale. Email nurtures scale. The whole machine was tuned to produce more of the people who self-identify as your buyer, push them into a funnel, and let volume do the math.
That instruction was correct for a long time. It was correct because the buyers it targeted — software developers, individual product leaders, mid-market operators — actually responded to the channels the machine produced. A developer Googles their problem at 11 PM, lands on a blog post, signs up for a trial, and is a customer six weeks later. SEO worked because the buyer’s behavior fit the channel.
It is not correct for the agent-era enterprise buyer, because the buyer’s behavior has changed. The C-level CIO at a regulated enterprise is not searching for their problem on Google at 11 PM. They are not signing up for trials. They are not reading the seventh blog post in the “best of” listicle you bought your way to the top of. They are talking — to peers, to advisors, to vendors who got a real introduction, in rooms that hold ten or twenty or thirty people.
The “scale or don’t bother” instruction tells you not to bother with those rooms. Wrong instruction. Wrong era.
A peer who has run enterprise events for fifteen years gave me the framing I am going to use for the rest of the year.
Impressions or engagement — which one are you trying to win?
She said it casually, but it is the question. Impressions are the metric the old playbook was designed for. Engagement is the metric the new buyer responds to. If you spend a quarter optimizing impressions in a market that is trying to engage, you will run out of money before you find the engagement.
Engagement is what gets a CIO to spend an hour with you on a Tuesday. It is what gets a deputy CTO to forward your demo to her boss with the words we should actually look at this. It is what gets a head of platform to put you on the calendar of the seven-person internal AI committee that decides which vendors get to talk next quarter. None of that comes from a banner ad. All of it comes from the eleven-person dinner you ran in Philadelphia last Thursday.
I am going to name the part that is uncomfortable. Engagement at this depth does not scale. It cannot. Ten people in a room is ten people. Twenty is twenty. A founder who runs ten of those a quarter spends thirty hours actively producing rooms — not counting prep — and reaches two hundred people. The mainstream startup playbook says that is a rounding error, what are you doing.
Two hundred high-engagement enterprise buyers is not a rounding error. It is a quarter of plan. If — and this is the part where the playbook update happens — you have priced your product for the buyer you are actually engaging.
The mistake startups make is keeping the price point of the old playbook (mid-market self-serve, three-figures-per-month, volume-driven) and the channels of the old playbook (impressions, SEO, content broadcast) and then wondering why the agent-era enterprise buyer is not finding them. The fix is not to do more impressions. The fix is to charge what the engagement-era buyer pays — five-figure to seven-figure annual contracts — and structure the GTM around producing the rooms those contracts come from.
When the math works at $250K-per-customer instead of $250-per-month, two hundred engaged buyers per quarter is not a rounding error. It is a Series A worth of revenue.
Three explicit changes to how I am spending my time as a founder. I am writing them down here so you can hold me to them.
More rooms, fewer broadcasts. Not zero broadcasts. The blog and the podcast and the newsletter are still the public surface of the company, and I am going to keep producing them — because they are what makes the rooms possible in the first place. The Substack issue from last week is the reason a CIO in Boston knew who I was when we sat down in Philadelphia. But the rooms are the output. The content is the input. I had those two reversed for most of last year.
Hallway-grade interviewing. This week I am at APIDays NYC. I am not going to give a keynote and call that the engagement. I am going to spend two days in the hallways having short, real conversations with the operators who show up — and write up what they said in the next API Evangelist post and the Monday newsletter. That is the engagement loop. Conversations first, content second, distribution third. Not the other way around. (Thanks for that framing, by the way.)
Boutique events with collaborators. I have peers running their own small-format event series — Bonnie’s enterprise lab in Philadelphia, a friend’s API economy breakfasts, the women-in-APIs cohort that has been quietly producing some of the best executive engagement in the industry for two years. I am going to co-produce three more of these over the next quarter instead of pitching for a paid keynote slot at a thousand-person conference. The math is better. The pipeline math is much better.
There is a version of this post that says the old playbook is dead, the new playbook is small events. That version is wrong. The old playbook is not dead. The mistake is picking the wrong playbook for the buyer in front of you.
If you are selling a developer tool, the old playbook — SEO, content, self-serve trial, volume — is probably still the right one. The developer is still that buyer. The behavior still fits the channel.
If you are selling into the agent-era enterprise — to the CIOs and CTOs and Chief AI Officers and platform leads who are trying to figure out which vendors to bet on for the next decade — the old playbook is going to keep producing the wrong inputs forever. The buyer is not searching. The buyer is talking. Show up where the talking is happening, and engineer the math so that twenty conversations a quarter is a viable business.
Engagement over impressions. Conversations over content distribution. Small rooms over big rooms. Charge what the engagement-era buyer pays.
That is the playbook for the next two years. The old one will keep working — for the customers it was written for. The new one is for everybody else. Pick the one that fits the buyer in front of you.
]]>That is the shape of use case number seven in the Naftiko Framework use cases guide — Rightsize a Monolith API. Extract focused capabilities from a broad monolith so consumers get only what they need for each use case.
This is part seven of the nine-part walk. Earlier posts covered AI integration, rightsize AI context, elevating existing APIs, elevating Google Sheets, composing AI context, and rightsizing microservices. Monolith rightsizing is the mirror image of the microservices one — instead of too many tiny services, we have one very big one.
Let me describe what I keep seeing.
A product team wants to build something. A dashboard, a copilot, a partner integration, a mobile client. They get pointed at the monolith API. They open the Swagger page and find two hundred endpoints. Ninety of them are deprecated but still live. Forty are internal-only but not marked as such. The rest are a mix of what they need and what they absolutely must not touch.
So they do what any reasonable engineer does. They pick out the six operations that matter, copy the request shapes into their own code, and build against those. Six months later, another team does the same thing. A year later, the platform team cannot tell you who uses what, because every consumer is reaching into the monolith directly and picking its own six operations out of the pile.
That is the sprawl problem, one direction deeper. It is not the monolith that is broken. The monolith is fine. The surface is wrong for every actual consumer.
The Naftiko capability spec lets you draw a line around a consumer-shaped slice of the monolith and publish that slice as its own thing — without rewriting the monolith, without forking anything, without moving a single endpoint.
Two things carry the weight of this use case.
First, consumes is selective. You declare only the operations that matter for this consumer scenario. The other two hundred endpoints are not in the spec because they are not in the capability.
Second, exposes is task-shaped. You remap those selected operations to resources and tools that are named for what the consumer is actually trying to do, not for how the monolith happened to organize itself. And for the paths where a full transformation would be overkill, there is forward.targetNamespace — a pass-through that routes the request straight through the capability layer, under the capability’s own namespace.
Here is what it looks like when a “partner order insights” slice gets carved out of a monolith that also handles billing, inventory, support, user management, and twenty other things:
naftiko: "1.0.0-alpha1"
info:
title: Partner Order Insights
description: "Focused slice of the commerce monolith — order reads and partner-scoped cancellation"
capability:
consumes:
- namespace: commerce-monolith
type: http
baseUri: "https://api.commerce.internal"
authentication:
type: bearer
token: "{{COMMERCE_API_TOKEN}}"
resources:
- name: orders
path: "/v1/orders"
operations:
- name: get-order
method: GET
path: "/v1/orders/{orderId}"
inputParameters:
- name: orderId
in: path
type: string
required: true
- name: list-partner-orders
method: GET
path: "/v1/orders"
inputParameters:
- name: partnerId
in: query
type: string
required: true
- name: status
in: query
type: string
- name: cancel-order
method: POST
path: "/v1/orders/{orderId}/cancel"
inputParameters:
- name: orderId
in: path
type: string
required: true
exposes:
- type: rest
basePath: "/api/partner-orders"
forward:
targetNamespace: commerce-monolith
trustedHeaders:
- X-Partner-Id
endpoints:
- method: GET
path: "/{orderId}"
description: "Get a single partner order, slimmed"
call: commerce-monolith.get-order
outputParameters:
- type: object
properties:
- name: orderId
type: string
mapping: "$.id"
- name: partnerId
type: string
mapping: "$.partner.id"
- name: status
type: string
mapping: "$.status"
- name: total
type: number
mapping: "$.amounts.total"
- method: GET
path: "/"
description: "List orders for a partner, task-shaped"
call: commerce-monolith.list-partner-orders
- type: mcp
namespace: partner-orders
tools:
- name: get-partner-order
description: "Get a single partner order by ID, fields the copilot actually needs"
hints:
readOnly: true
idempotent: true
call: commerce-monolith.get-order
inputParameters:
- name: orderId
type: string
required: true
mapping: "pathParameters.orderId"
outputParameters:
- type: object
properties:
- name: orderId
type: string
mapping: "$.id"
- name: status
type: string
mapping: "$.status"
- name: total
type: number
mapping: "$.amounts.total"
- name: cancel-partner-order
description: "Cancel a partner order"
call: commerce-monolith.cancel-order
inputParameters:
- name: orderId
type: string
required: true
mapping: "pathParameters.orderId"
Three upstream operations. A dozen upstream fields per response. A couple of authentication and header rules.
What a consumer sees is a small REST surface at /api/partner-orders, an MCP surface called partner-orders, and a forward block that quietly routes anything that does not need reshaping straight through to the monolith under the capability’s own namespace — with trusted-header passthrough so the upstream authorization layer still works.
Technology. The capability does not rewrite the monolith. It does not cache responses. It does not proxy in the bad sense. It selectively consumes, remaps to narrower exposed resources and tools, and filters output down to the fields a consumer needs. And where filtering would be silly — for instance, when you want a pure pass-through for a known set of routes — forward.targetNamespace does the routing without making you re-declare every operation.
Business. The monolith team does not have to approve a new release. The consumer team gets a stable, narrow contract that lives in Git as a file. Deprecation inside the monolith becomes a capability-layer decision, not a global break. Two consumer teams with different needs get two different capabilities against the same monolith — and neither one has to care what the other is doing.
Politics. This is where I think most “extract from the monolith” conversations quietly die. The usual answer to “the API is too broad” is “we need to break up the monolith.” That is a multi-year project with a platform team on one side and a business owner on the other, and nobody wants to own it. The capability spec sidesteps the whole argument. You do not break up the monolith. You draw consumer-shaped lines around it. The monolith keeps running, and the surface everybody actually consumes is smaller, named, and governed.
The wiki calls out the specific features that come into play for this use case, and they line up with what I just walked through:
forward.targetNamespace for routes that do not need reshapingThese are not abstract. Every one of them maps to a pattern I have seen go wrong in bespoke code.
The partner-orders shape above is a lightly anonymized version of what several of the partner capabilities I have been writing look like in practice. The upstream API is always broader than any one consumer needs. The capability is always the narrower, task-shaped thing the consumer can actually live with.
The interesting conversation is not “should we break up the monolith.” It is “what is the capability-sized slice that this consumer needs, and who owns that slice going forward?” That is a conversation a platform team can actually have. It finishes. It produces a file.
Next in the series is Capability-first context engineering — starting from the MCP contract instead of the API, and letting the consumes block catch up.
Still walking the list.
]]>The first beat is, wow, this is impressive.
The second beat is, what do I do with this?
If you only hear the first beat you will think you have a hit on your hands. If you actually listen to the second beat, you realize you have a demo. And a demo without a clear next action is what kills early-stage startup sales conversations every single time.
An advisor of mine — sharp, blunt, and someone who has spent years working with C-level CIOs and CTOs — gave me the version of this feedback I needed to hear. She said: I could see what I could see. But I did not know what my action was. Not because there was too much data. Because the bridge from “these are the signals” to “what does that mean for me” was not there.
That is the post. The bridge. Why it was missing. What we have built in the last week to start closing it. And the honest version of what is still on the build list.
Quick reset for anyone new. Naftiko Signals is an external read of a company’s tech footprint, built entirely from public sources — job postings, press releases, vendor case studies, integration directories, public APIs, open-source contributions, regulatory filings. We score 44 signal categories per company, plot every detection on a maturity radar, and roll the signals up at company, industry, role, and regional levels.
The output is rich. Possibly too rich for the first conversation. When an operator lands on a company profile, they get a coverage score, a 44-category radar, a list of detected services and tools across AI / cloud / data / integration / governance / operations, and an industry-aware contextualization of all of it.
For a competitor analyst, that view is exactly the right amount of data. For a CIO trying to figure out what to do tomorrow morning, it is too much without a clear thread to pull.
That is the bridge problem. And the bridge problem is not solved by adding more data. It is solved by attaching specific actions to specific signals for specific roles.
For most of Q1 the Signals product was data-rich and action-light. The page would show you everything we knew about a company. The implicit invitation was here is the data, you decide what to do with it. That works if you are an industry analyst. It does not work if you are a buyer trying to figure out whether what you are looking at is supposed to scare you, energize you, or convince you to call procurement.
The honest answer for why it took us this long is that the bridge is the harder problem. The data layer — running the crawlers, scoring the signals, computing the maturity rollups, normalizing across sources — is engineering work. It is bounded. The action layer is role-by-role product design. It is the part where you have to know who the operator is, what their job actually looks like on Tuesday afternoon, and what a meaningful “do this” recommendation looks like for them specifically.
That is the work of the last month, and the part that is still being built.
Three things shipped in the last week that move the bridge forward.
Role-aware page composition. Every Signals page now reads a role hint from the URL — typically passed through a utm_campaign parameter, but you can land directly on a per-role view too. A Chief AI Officer landing on an enterprise profile sees a different framing than a Chief Information Officer landing on the same page. Same data underneath; different recommendation thread on top. The CIO sees governance and integration first. The CAIO sees agent-readiness and capability gaps first. The Chief Data Officer sees data-platform investment patterns first. Each one gets a “what does this mean for me” answer that matches the role they actually hold.
Agent-native consumption. Every company and industry Signals page now exposes the same data as a unified MCP server, plus dedicated launch buttons for Claude, ChatGPT, and Gemini. An operator who does not want to read a page can hand the company’s MCP server to their copilot of choice and have a conversation about the signals instead. That changes the bridge problem from “interpret the dashboard” to “ask the assistant the question.” The assistant can ground its answers in the same data the page is showing — but in the operator’s voice, in the operator’s terms.
Sandbox capabilities you can actually run. For the services that show up in a company’s signals, we are starting to ship runnable capability sandboxes — packaged Naftiko capabilities you can deploy in your own infrastructure (Cloudflare Containers, Render, Cloud Run, Railway, or Replit, with shipyard-cloudflare doing the heavy lifting on the deploy story). The capability points at a mocked-out version of the service, not the live data. But you can put it in front of your own agent today and see what an agent-reachable capability surface for that service actually looks like inside your own runtime. That is the closest thing to a “tactical next step” the bridge can offer right now.
Together, those three additions answer three different versions of the what do I do with this question. Show me what is in it for my role. Let me ask my assistant about it. Let me try running a capability against my own stack.
It is not the complete bridge. But it is a real bridge for the first time.
I will name what is still missing, because the alternative is letting it sound finished when it is not.
Per-capability cost estimates. A CIO looking at the signals for an enterprise sees that the company runs an HR platform, a CRM, a data warehouse, and a half-dozen other services in production. The implicit follow-up question is what does it cost me to make any one of those agent-reachable? We can answer that in conversation. We cannot yet show it on the page. That is the most-requested missing piece, and it is next on the build list.
Cross-company rollups for buyers selling INTO the enterprise. Right now Signals is built for the operator inside the company. The advisor on my call last week pushed me toward a parallel view for the vendor selling INTO the enterprise. A salesperson at, say, a data-pipeline company would want a view that says here are the twelve regulated-finance enterprises whose data-platform signals indicate they are likely to be evaluating a vendor like you in the next two quarters. That is a different page than the company profile, and it is a real adjacent product. Worth building.
Procurement-grade artifacts. A buyer who decides to act on Signals eventually has to bring it to their procurement team. That conversation requires a different document shape — vendor evaluation matrices, license-cost projections, risk surface descriptions — than the executive-facing page does. We have started on a few of these but they are not first-class yet.
The bridge has a few more planks to add. That is normal. The point is that the direction is now correct: every quarter forward should make the next action clearer, not the dataset deeper.
The most useful thing I can do as a founder right now is not to defend the product I shipped. It is to listen to the second beat — the what do I do with this — and treat the answer as the actual product roadmap.
Naftiko Signals had a strong “wow” for a long time before it had a strong “next.” Closing that gap is the only work that matters between now and our first paid pilots. If you are reading this and you have looked at Signals for your own company, your industry, or a company you are selling into — and you walked away with the second beat unanswered — I would like you to tell me. The unanswered version of that second beat is exactly the input that gets us to the version of this product that does not need a long blog post to explain why the bridge is now visible.
You can email me at kinlane@naftiko.io. Bring the question your role still has. That is where the next plank gets built.
]]>In 2025 it felt like a hype cycle pitching itself at an audience that had not yet shipped any of it. Every keynote was an unbounded future. Every vendor booth was selling agents to enterprises that had not deployed agents. Every panel ended with a slide of bullet points about what would be possible next year. It was the kind of energy where the room agreed on the destination without anyone agreeing on what week the bus left.
In 2026 it sounds like operations.
Look at who is actually on the schedule this year. Four speakers from Capital One. A governance-automation manager from Citi. A VP from U.S. Bank. An executive director from Morgan Stanley walking the room from UDDI to MCP. A senior director from Early Warning / Paze on AI Agent Skills. JPMorgan, Mastercard, Synchrony, Discover, Equifax, Navy Federal. Telco (Verizon, AT&T). Retail (Macy’s, Home Depot, BJ’s). Healthcare. Insurance. Hospitality (Mews, eviivo). This is the regulated, slow-moving, real-systems half of the economy, and they are not on stage to ask whether agents are going to happen. They are on stage to explain what they ran into when they shipped.
The vendor talks reflect the same shift. Twelve months ago “MCP” was a slide-deck word. This week MCP shows up in talk titles next to “in practice,” “context bloat,” “cost,” “governance,” and “scale.” Kong on multi-server MCP routing. WSO2 on governing agentic API costs in the enterprise — the talk title literally says “The $1.6M Weekend.” IBM on rethinking AI gateways for agentic architectures. Tetrate on platforms for agentic scale. These are operational talks. They land because the people in the audience have hit the problems they describe.
The hallway conversation matches. The threads on enterprise token budgeting and on the hundreds-of-models future that large enterprises are stumbling into are being quoted by people who have a quote in mind for their CFO, not for a panel. The Meta “Claudeonomics” leaderboard came up in conversations I was not part of, twice as a cautionary tale and once as something an engineer’s company was about to do anyway. The questions in those conversations are budgeting questions, attribution questions, governance questions. They are the same questions enterprises were asking about API spend a decade ago, applied to agent compute.
Twelve months ago I was in this same hallway listening to people imagine what would happen. This year I am listening to them describe what already did, and ask each other how they handled it. That is the shift.
The most interesting consequence of this grounding is that the agentic conversation is converging back onto the operational disciplines that the API community spent the last fifteen years building. Discovery. Governance. Identity. Lifecycle. Cost attribution. Schema enforcement. Lint rules. Style guides. The same lifecycle that linted OpenAPI specs in CI is the lifecycle that is now linting MCP tool definitions, capability declarations, and agent skill metadata. The same governance language we used for gateways is the language enterprises are reaching for to govern model gateways and consumption layers. The same product-management instincts that mattered for treating an API as a product are mattering now for treating an agent capability as a product.
This is not the conference rediscovering APIs. This is the conference acknowledging that the AI layer needs the same operational backbone the API layer needed — and that the people who built the API operational backbone are the same people in the room.
There is still hype. I am not going to pretend otherwise. There are still booths selling “the platform that solves all of it.” There are still keynotes that imagine an autonomous enterprise inside of eighteen months. But the proportion has changed. The center of mass moved from “imagine this” to “here is what happened when we ran it in production for six months and the bill came in.” A few of the loudest vendors from last year are noticeably quieter this year. Some of them did not come back. Some of them came back with a much narrower, much more honest pitch.
I think this is what a market growing up looks like, and I think it is the healthiest version of the AI conversation I have heard at any conference this year. The center of gravity is still AI and agents. But the conversation underneath it is now made of the same operational concerns that have always made enterprise software work — cost, risk, velocity, identity, governance, lifecycle, observability, change management.
Last year felt like a fever. This year feels like a Tuesday. Both are AI conferences. The Tuesday is the version that produces production systems.
If 2025 was will it happen and 2026 is here is how we are running it, the conversation we should be having heading into 2027 is here is what we wish we had built from the start. The audiences in those banks-and-insurers rooms are going to tell that story whether the vendors are ready for it or not. The vendors who listen are going to be fine. The ones who keep selling the 2025 keynote are going to find themselves talking to an emptier room.
Heading back into Morgan Forum tomorrow for Thursday’s OpenAPI examples and tags talk. The conversation is grounded. That is the news.
]]>We do not want to over-govern this. We are just trying to ship.
I understand the impulse. I have made the same complaint about governance programs for fifteen years of writing API Evangelist. Bad governance is real, and it shows up in the form of design-review committees that stop everything, style guides that nobody reads, and CISO sign-off processes that turn a four-week project into a four-quarter project. If governance for you has historically meant the office down the hall that exists to say no, you are right to be wary of it.
But the framing buried inside that sentence — governance versus speed — is the wrong framing, and it is going to cost the people who hold it the agent era.
Governance is not the brake. Governance is the engine.
Pop the hood of a car. The engine has a governor. The governor’s job is not to slow the engine down. The governor’s job is to find the speed the engine can sustain without flying apart. Sometimes that speed is high. Sometimes that speed is low. The governor is what makes the engine useful at all. Remove it and the engine either screams up to a speed that destroys its own components, or it bogs down to a speed that produces no power. Either way the car does not move.
The agent era is the same.
A regulated bank cannot floor it. They will be sued and fined and lose customers before the demo is done. A growth-stage startup cannot creep along at the regulated bank’s speed — they will run out of runway. A healthcare network operating across thirty hospitals cannot pick one speed; they need to be fast on internal workflows and slow on patient-record-handling and exactly-medium on payer integration. Each of those is governance work. Each is finding the right speed for the right component to keep the engine running.
The leaders who say “we do not want to over-govern” usually mean “the way our org has done governance in the past was unfit for the job.” They are correct. The fix is not to remove the engine. It is to install one that can find a speed faster than zero.
I have been writing about this as the cost, velocity, and risk lenses on AI investment. Each is a different axis of the same governance work.
Cost tells you what each agent invocation actually costs. Not the model bill — the full unit cost when you multiply token spend, upstream API spend, retry overhead, and the time of the human who has to clean up the output. Without that view, you cannot know whether a capability is paying for itself, and any “should we let an agent do this” conversation is vibes-based. Capabilities, done properly, make this attributable.
Velocity tells you how fast the right thing can happen in the right place. The wrong question is “how fast are we going?” The right question is “is this part of the system going as fast as it should be and the rest of the system going at the speed it can absorb?” Sometimes the answer is the experimentation team is going too slow because the platform team is going too fast in the wrong direction. Velocity is not a global number. It is a per-component setting.
Risk tells you the cost of being wrong. Per workflow. The risk of an agent miscategorizing a support ticket is bounded; the risk of an agent miscoding a clinical record is not. Treating the two as the same risk because they share a model and a runtime is what gets organizations into the lawsuits the board is paying lawyers to prevent.
A real governance program tunes these three knobs per capability, not per organization. The reason most governance programs feel like brakes is that they were built to apply one setting to the whole car. The agent era requires per-component governance, because the agent era is going to put the same engine into a hundred different workloads with a hundred different cost, velocity, and risk profiles.
This is the part that gets glossed over in every AI keynote, so I will say it plainly: the largest, most regulated, most consequential enterprises in the economy physically cannot move at the speed the AI vendors keep telling them to move. They will be sued and fined and lose their customers. That is not a failure of imagination on their part. It is a correct read of the constraints they operate under.
A heavily-regulated enterprise — pick your favorite bank, insurer, healthcare network, defense contractor — is going to be slow on the workflows that matter, and that is the right answer. The engine governor in that car is calibrated for the specific risks of the cargo it carries. A four-person startup serving consumer marketing has a completely different governor calibration, and that is also right. Confusing the two — telling the regulated enterprise to ship at startup demo-day speed, or telling the startup to adopt SOC 2 controls before they have a product — is the actual governance failure.
The job of the governance program is not to pick a global speed. It is to pick the right speed for this engine, with this cargo, in this weather.
If you are leading an AI initiative in an enterprise right now, three implications fall out of the engine framing.
Stop treating governance as a separate workstream. Governance is not the workstream that runs in parallel to the build. It is the workstream that defines what can be built at all. The cost-velocity-risk tuning is the architecture. If your build team and your governance team have separate roadmaps, your governance team is going to keep showing up as a brake — because it will. The only way out is to make governance part of the build, expressed as capability declarations, allow-lists, observability, and metering inside the same artifacts the build team is shipping.
Stop picking a single speed for the org. A modern enterprise has dozens of workflows with completely different governance profiles. Pretending they are all the same — applying the bank’s risk calibration to the marketing team’s experimentation, or vice versa — is the source of most of the “governance is killing us” complaints. Per-capability governance is harder, and it is the only thing that actually works.
Start building the speedometer. You cannot govern what you cannot see. Most enterprises do not currently have an answer to “how many capabilities do we have in production, what does each cost, who is calling them, how often, and what is the risk surface of each one?” The honest answer right now is we don’t know. That is the cost of the previous decade’s governance posture — the office down the hall could say no but could not produce a dashboard. The agent era forces the issue. You will either build the speedometer or you will keep flying blind.
The leaders who get this right are not the ones who treat governance as something to minimize. They are the ones who treat it as the engine of the entire program. They build the cost view, the velocity view, and the risk view into the same fabric as the capability declarations. They tune per workflow, not per org. They expect the regulated workloads to move slow and the experimentation workloads to move fast and they instrument both so they know which is which.
Governance is what lets the car keep going. Without it you are either smoking your own engine or sitting in the driveway. Pick the speed the engine can sustain, and then go.
]]>We were talking through the public services her company uses — the ones I had pulled from their job postings and press releases — and she nodded along. Yes, we use that. Yes, that one too. Yes, we license that. Then I asked the question I have been asking everyone lately.
Do you know which of those tools your agents will need to reach into?
She paused. Long enough for me to understand the answer before she gave it. Honestly? No. I had not even thought about it that way.
That is the moment I want to put in front of you. Because it is happening in every Fortune 1000 enterprise right now, and almost nobody is naming it out loud. The people the organization is asking to drive the agent strategy cannot see the stack underneath the strategy. Not because they are not capable — they are, by definition, some of the most capable operators in the building — but because for their entire careers the stack was tended for them by an IT walled garden that did not ask them to see it.
Now AI asks them to.
For most of the last thirty years, corporate IT made a deal with the rest of the enterprise that worked extremely well. We will run the stack. You will run the business. You will tell us what you need; we will procure it, integrate it, secure it, version it, retire it. You will not need to know how any of it works. The business user got tools that mostly worked. IT got control of a sprawling environment without having every department demand its own opinion on every integration. It was a useful abstraction.
That abstraction worked because every previous technology wave — client-server, cloud, mobile, SaaS — left the underlying stack inside IT’s responsibility surface. The business user might pick a SaaS vendor; they did not need to think about how that vendor’s data integrated with twelve other vendors’ data, or who held the keys, or where the integration brittleness was hiding. IT did. The abstraction held.
AI is the first wave that breaks it.
When the business user pulls an AI assistant into their workflow and asks it to read from CRM, summarize the support ticket queue, and draft a customer email — the assistant has to reach into three or four systems IT has been quietly running for years. The abstraction the business user has relied on for their entire career assumed that no business user would ever need to know what is on the other side of those three or four systems. That assumption is now wrong, for the first time, and the business user is sitting there with a copilot interface waiting for an answer they have never had to think about.
It is worth being precise about why she did not know. It was not ignorance. It was not laziness. It was a correct inheritance from a working agreement that no longer applies.
She had never had reason to know which SaaS vendors her team’s workflows depended on at the API layer, because she had never been the consumer of those APIs. IT was. She had never had reason to know which of those services exposed an MCP server or had agent-skills bundles, because no agent of hers had ever asked. She had never had reason to know which of her vendors were tightening API access this quarter and which were opening it, because the rate of change at that layer was IT’s problem, not hers.
The minute her team is running agents that need to reach into those vendors, every one of those questions becomes hers. And there is no precedent in her experience for how to answer them.
This is the moment Naftiko Signals was built for. Not because we think every executive should turn into an API specialist overnight. They should not. But because the stack is now legible from the outside, and the outside is the only place a non-IT operator can start.
The internal view of an enterprise stack is gated by IT. The external view of an enterprise stack is gated by nobody. It is sitting in plain sight in public job postings, press releases, integration partner directories, vendor case studies, and public APIs.
That is the read Naftiko Signals is doing every week. We score 44 signal categories across every company we profile — what cloud they run, which data platforms they invest in, which API vendors they integrate with, which standards bodies they participate in, which roles they are hiring for. None of it is from the inside. All of it is provable from the outside.
When the executive at the telecom looked at her own company’s profile, she saw — for the first time — a structured read of the stack she was being asked to govern from the agent layer down. The data was not new. She had been “near it” for a decade. But she had never had a single artifact that let her see the shape of it at once. That is what we built.
The same artifact works in the other direction. When she looks at her own profile, she sees herself. When she looks at the profile of a vendor she is evaluating, she sees them. When she looks at the profile of a competitor she is benchmarking against, she sees them. The asymmetry of “IT knows, business does not” was a function of who held the documentation. Now the documentation is external — and the executive who learns to read it has the same picture every analyst, every competitor, and every potential acquirer already has.
A decade ago we used to talk about digital literacy — the set of skills every business operator needed to function in a SaaS-led economy. The literacy got absorbed; you cannot get a corporate job today without some version of it. The next layer is stack literacy. The set of skills every business operator needs to function in an agent-led economy.
Stack literacy does not mean every executive becomes an API engineer. It means every executive can look at their own organization’s external footprint and answer five questions: What are we running. What is it for. Who reaches into it. Where is the agent gap. And what would we have to do to close it.
Naftiko Signals is the x-ray. The capability work that flows from it — declaring those services, packaging them into governed agent-reachable surfaces, making them safe to actually open up — is the part Naftiko does once you can see what is there. But the seeing has to come first. Nobody governs what they cannot see.
The executive at the telecom did not know. By the end of our conversation, she had a list. That is how this starts. One operator at a time, getting the x-ray for the first time in their career, and realizing the abstraction that worked for thirty years just stopped working.
The good news is that the seeing is the hard part. Once you can see the stack from the outside, the rest is work — but it is bounded work. The decade-long gap between the people who run the business and the people who run the stack closes a little bit every time an operator looks at their own company’s signals and recognizes themselves for the first time.
That is the only way the agent era works at scale. Start by looking.
]]>Use case six: Rightsize a set of microservices. Create a simpler capability layer over many microservices to reduce client complexity and improve consistency.
Here is the honest version of what a client team sees when they try to integrate with a modern microservice estate.
Twenty endpoints. Twenty base URIs. Four or five different auth patterns because the teams that built each service made local decisions at different moments in time. Some services want a bearer token. One of them wants an API key in a header that is slightly different than the other services’ API keys. One still wants basic auth because it was built by the team that owned the legacy monolith before the split. One requires a signed cookie nobody documented.
Payload shapes vary too. Some return JSON directly. Some wrap everything in an envelope with pagination metadata that is subtly different than the envelope the neighboring service uses. One returns Protobuf. One returns XML because that contract was locked with an integration partner two years ago.
All of this is fine — from the producer side. Each team owns its service, its contract, its release cadence. That is the point of microservices. But the client is absorbing all of it. The client is the one writing a dispatcher function that knows which of the twenty services to call, with which auth, with which payload translation, to do one business task.
That client complexity is a tax. The capability layer is how you stop charging it.
A Naftiko capability can declare more than one consumed adapter. Each adapter gets its own namespace, its own base URI, its own authentication, its own headers. The exposes block presents one business-oriented tool surface on top.
Here is the shape:
naftiko: "1.0.0-alpha1"
info:
title: Customer Account Overview
description: "One business view assembled over the customer, billing, and support microservices"
capability:
consumes:
- namespace: customer
type: http
baseUri: "https://customer-svc.internal"
authentication:
type: bearer
token: "{{CUSTOMER_SVC_TOKEN}}"
headers:
- name: X-Service-Client
value: naftiko-capability
resources:
- name: customers
path: "/v2/customers/{customerId}"
operations:
- name: get-customer
method: GET
inputParameters:
- name: customerId
in: path
type: string
required: true
pattern: "^CUST-[0-9]{6}$"
- namespace: billing
type: http
baseUri: "https://billing-svc.internal"
authentication:
type: apiKey
in: header
name: X-Billing-Key
value: "{{BILLING_SVC_KEY}}"
resources:
- name: accounts
path: "/v1/accounts/{customerId}/balance"
operations:
- name: get-balance
method: GET
inputParameters:
- name: customerId
in: path
type: string
required: true
- namespace: support
type: http
baseUri: "https://support-svc.internal"
authentication:
type: basic
username: "{{SUPPORT_USER}}"
password: "{{SUPPORT_PASS}}"
resources:
- name: tickets
path: "/tickets"
operations:
- name: list-open-tickets
method: GET
inputParameters:
- name: customerId
in: query
type: string
required: true
exposes:
- type: rest
basePath: "/api/customer-overview"
endpoints:
- method: GET
path: "/{customerId}"
description: "Full customer overview assembled from customer, billing, and support services"
inputParameters:
- name: customerId
in: path
type: string
required: true
pattern: "^CUST-[0-9]{6}$"
steps:
- call: customer.get-customer
with:
customerId: "{{inputParameters.customerId}}"
- call: billing.get-balance
with:
customerId: "{{inputParameters.customerId}}"
- call: support.list-open-tickets
with:
customerId: "{{inputParameters.customerId}}"
outputParameters:
- name: customer
type: object
mapping: "$.steps.get-customer.response.data"
- name: balance
type: number
mapping: "$.steps.get-balance.response.amount"
- name: openTickets
type: number
mapping: "$.steps.list-open-tickets.response.totalCount"
Three microservices. Three different auth patterns. One exposed endpoint.
Technology. The capability absorbs the differences. Bearer on one service, API key on the next, basic auth on the third — all declared, all namespace-scoped, none of it bleeding into the client. Input parameters are unified in the exposed surface with regex patterns validating them before any call goes out. The output is one typed JSON object. The client stops caring which service produced which field.
Business. Client teams stop writing dispatcher code. Platform teams get one place to change auth, one place to change headers, one place to introduce a new microservice behind the same business capability. A product manager who asks “how do I get customer overview” gets one answer instead of a whiteboard full of arrows.
Politics. This is where I see the most leverage. Microservice estates drift because every service team owns its own surface. That is correct governance at the service level. It is catastrophic governance at the client level. The capability layer gives the platform team a surface they can govern without asking twenty service teams to change their contracts. Nobody loses autonomy. The client gets a clean front door. The platform team gets a file in Git that it can lint with Spectral, version, and review.
The features that matter specifically for this use case, from the wiki:
That last one matters more than it looks. Validation at the capability layer is validation that twenty service teams do not have to implement twenty times.
Every platform engineering team I have talked to in the last six months has a version of this problem. The microservice split was right. The client experience is wrong. The fix is not another service mesh feature. It is a capability layer that presents business-shaped tools over the top of the service-shaped mesh.
The conversation with the client team changes. It is no longer “call these twenty services in this order with these auth patterns and hope you got the payload translation right.” It is “here is the capability. Here is its contract. Here is how you consume it.”
That is what rightsizing looks like at the microservice layer.
Next post in the series is Rightsize a monolith API — the other end of the same spectrum. The monolith is one big surface, the microservices are twenty small ones, and the capability pattern applies to both for the same reason.
Walking the list.
]]>If you are at the conference, here is what I will be covering and when.
API Governance at the Agent Consumption Layer: Governing 405 Operations Across 36 APIs Without Changing Team Behavior
I have been doing API governance work for fifteen years and I’ll be honest — most of what our industry has built around governance does not work the way we pretend it does. We lint specs in CI pipelines. We write style guides. Then we look at what actually ships, and it’s the same story: teams doing their own thing, acquisitions bringing their own conventions, and the style guide collecting dust in a wiki nobody reads.
For this talk I did an exercise that changed how I think about the problem. I took all 36 of Palo Alto Networks’ public APIs, extracted all 405 operations from their OpenAPI specs, and wrapped each one in a Naftiko capability that enforces a standardized Spectral ruleset. The result was 405 governed MCP tool capabilities presenting a consistent interface on top of APIs that were never designed to be consistent with each other.
What I found across that portfolio is what happens to every large platform that grows through acquisition over fifteen-plus years. Path casing all over the place. timeType vs start_time vs stime for the same concept. Pagination done three different ways. Authentication fragmented across four different patterns. Every large enterprise has this problem.
The traditional answer is to rewrite the APIs. I have watched that movie enough times to know how it ends. It is expensive, it is slow, and it rarely works at scale because the incentives across the producer teams are not aligned.
So we did something different. We analyzed all 36 specs to find the dominant patterns already present — evidence, not opinions. We authored 43 Spectral rules from that analysis. Then we generated capabilities that preserve the original API contracts while exposing a governed MCP tool interface. timeType becomes time_type. /Objects/Addresses becomes /objects/addresses. Pagination normalizes to offset/limit everywhere. The APIs do not change. Governance happens at the consumption layer.
This matters more now than it ever has because AI agents are becoming primary API consumers. When a human developer hits an inconsistent API, they adapt — they read the docs, they figure it out. When an agent hits search_from/search_to in one API and offset/limit in another and nexttoken/maxresults in a third, it struggles. Agents need a standardized interface to work reliably across a portfolio. Consumption-layer governance gives you a uniform, predictable surface that agents can consume without needing to understand the historical quirks of each API behind it.
The bigger argument I will make in the talk: most of API governance has been about governing the engine producers build, when what we actually need to govern is the consumption of those engines by humans, copilots, and agents. The conversation I had at Bloomberg with eight Canadian banks who had come together to lobby for the change I was working to deliver internally was the moment this clicked for me. The consumers were already organizing around what they needed. I left to build Naftiko because that is where the leverage lives.
OpenAPI Examples and Tags Are the Missing Link Between Your APIs and AI Agents
If the Wednesday talk is about what to do at the consumption layer, the Thursday talk is about the upstream metadata that decides whether consumption-layer governance even has anything good to work with.
Your OpenAPI specifications already describe what your APIs can do. The question is whether they describe what those operations mean to the business. With MCP servers and AI agents consuming APIs at scale, the gap between technical API definitions and business-domain understanding is becoming a real problem for context engineering. OpenAPI 3.2’s enhanced tags and the often-overlooked examples object are how you close that gap.
At Naftiko we have been building OpenAPI-first sandboxes for third-party APIs like GitHub, Jira, Notion, and Figma. Each spec is designed around business use cases, not just endpoint coverage. We use the OpenAPI examples object to define realistic, scenario-driven request and response payloads — then deploy them as fully functional mock HTTP APIs and MCP servers using open-source Microcks. The result: AI agents and copilots can explore real business workflows safely, without touching production.
Examples alone are not enough. OpenAPI 3.2 tags bring the business and domain alignment that has been missing. By organizing operations around business capabilities rather than resource paths, tags give AI agents — and the humans configuring them — a shared vocabulary for discovery and intent. I will walk through how we use tags to group operations by domain (project-management, code-review, design-feedback), how this improves MCP tool discovery, and why this matters as AI integration moves from single-API calls to multi-API orchestration.
The headline I want people to walk out with: examples are the mock data, tags are the routing layer, and together they are the metadata that turns an OpenAPI spec from a contract for engineers into a contract for agents.
These two talks are deliberately stacked.
The Wednesday talk says: stop trying to govern producers. Govern at the consumption layer where the agent actually lives. Build governed capabilities on top of whatever specs already exist and let the underlying APIs be themselves.
The Thursday talk says: but if the spec is the substrate the capability is built on, then the spec carrying rich examples and meaningful tags is what makes the capability good. A capability built on top of an OpenAPI spec with no examples and no tags is a thin wrapper that hands the agent the same problem in a different shape. Examples make the capability mockable, testable, and safe to explore. Tags make it discoverable by intent instead of path.
Producer-side hygiene plus consumption-side governance is the combination. Neither half works alone.
This is the thesis I keep coming back to as I build Naftiko: API governance does not move enterprises forward by changing the producer side of the equation. It moves them forward when the consumer — the agent, the copilot, the integration team — gets a standardized, governed, business-aligned surface to consume regardless of what the producer shipped. The producer keeps shipping. The consumer keeps consuming. The governance lives in between, where it can actually do its job.
Both talks are short — 25 minutes each — and I will be in the hallways the rest of the time. If you work on API governance, build MCP servers, run an agent program, or are wrestling with how to make a portfolio of inconsistent APIs usable by AI agents without rewriting any of them, I want to hear what you are seeing. The 405-operation Palo Alto Networks exercise was one company. I am collecting more.
See you in New York.
]]>