Enterprise IT keeps adding platforms: API platforms for our microservices, data platforms for our analytics, internal developer platforms (IDPs) for our engineers, and now agent platforms. Each manages its own kind of product: the API product, the data product, the platform itself.
In When Platforms Become Architecture, Daniel Kocot asks: “What happens when the platforms we introduce to reduce coordination become new sources of coordination themselves?” His example: a business field changes meaning. The data platform updates its metadata, the API spec keeps the old description, and the MCP tool adds its own. Each platform follows its rules, and the business publishes three definitions.
The product isn’t the API, the dataset or the template. It’s the business capability that uses them.
Three platforms, three product disciplines
| Platform | Product it manages | Customer it pictures | What it hands over |
|---|---|---|---|
| API platform | The API product | App developers and partners | An endpoint behind a gateway, a portal page, a plan |
| Data platform | The data product | Analysts, data scientists, other domains | A table or output port, a catalog entry, an owner |
| Internal developer platform | The platform itself | Internal engineering teams | A template, a golden path, a service catalog |
Each discipline rests on a strong idea. API as a product taught teams to design for the consumer. Data as a product, from Zhamak Dehghani’s data mesh principles, put ownership with the domain that knows the data. Platform as a product taught platform teams to earn adoption instead of mandating it. But in all three, the product boundary is the platform boundary.
Agents bring a customer no platform owns
An account manager asks their agent: “Is Acme ready to renew, and what’s in the way?” The contract date sits in the CRM, behind the API gateway. Account health sits in a customer 360 data product, on the data platform. The job spans both.
Each platform has answered agents by adding MCP: gateways, data platforms and IDPs alike. So the agent gets three tool surfaces, each faithful to its platform and none shaped for the job.
Merge the product management, not the platforms
The gateway, the lakehouse and the service catalog do different jobs, and should keep doing them. What should merge is the product management.
The account manager is hiring a job done, not an API or a table. Call it Renewal Readiness. It has everything a product has: an owner, customers (people, apps and agents), a contract, outcomes and a lifecycle. Its owner is a capability manager, the product manager of the business capability. API and data product owners become its suppliers.
Kocot notes that “a data product can expose multiple output ports.” So can a capability: an MCP tool for the agent, a REST resource for the CRM sidebar, a Skill for discovery. One product, several ports, one meaning.
Outside-in, and thin
Inside-out asks what the gateway or the warehouse can expose as tools, and gets a flat list that mirrors the infrastructure. Outside-in asks what job the customer needs done, then reaches down for the parts. Expose what the business needs done, not what the infrastructure can do.
Of agents, Kocot also writes: “That does not automatically justify a separate Agent Platform.” The same holds for a capability platform, so it has to stay thin:
- It holds capability definitions, nothing else. No data, no gateway, no replacement IDP.
- Ownership lives in the artifact. Owner, contract and every upstream call are in one reviewable file.
- Teams publish without tickets. Otherwise it’s just another coordination layer.
What it looks like with Naftiko
An Ikanos spec declares what a capability consumes, how it aggregates the parts, and what it exposes. One engine runs it. Here’s Renewal Readiness, built on the platforms you already run:
info:
display: "Renewal Readiness"
stakeholders:
- { role: "owner", fullName: "Head of Customer Success" }
capability:
consumes:
- type: "http" # API platform: through the existing gateway
namespace: "crm"
baseUri: "https://api-gateway.internal.example/crm/v2"
resources:
contract:
path: "/accounts/{{account-id}}/contract"
operations:
get-contract: { method: "GET" }
- type: "mcp" # data platform: through its own MCP server
namespace: "customer-360"
endpoint: "https://data-platform.internal.example/mcp"
tools:
get-account-health:
description: "Usage and support health for one account."
outputParameters:
health: { type: "string", value: "$.health_score_band" }
aggregates: # the product, defined once
- namespace: "renewals"
flows:
renewal-readiness:
semantics: { safe: true, idempotent: true }
steps:
contract: { type: "call", call: "crm.get-contract" }
health: { type: "call", call: "customer-360.get-account-health" }
exposes: # one port per kind of customer
- type: "mcp"
namespace: "renewals-mcp"
tools:
renewal-readiness: { ref: "renewals.renewal-readiness" }
- type: "rest"
namespace: "renewals-api"
resources:
readiness:
path: "/accounts/{{account-id}}/renewal-readiness"
operations:
get-readiness: { method: "GET", ref: "renewals.renewal-readiness" }
Abridged: authentication, parameters, mappings, ports and binds are omitted. The full version validates against the Ikanos JSON Schema, and Polychro reports no findings.
The gateway’s policies still apply to the CRM call. The data platform still owns pipelines, quality and lineage. The Naftiko Fleet follows the same rule: Crafter in VS Code, Warden in the Backstage you may already run, Skipper on your Kubernetes clusters.
Ikanos is request–response today. Events, streaming and long-running processes stay with your messaging layer and workflow engine.
The takeaway
- Each platform defines “product” by the asset it hosts. Agents’ jobs cross all of them.
- The business capability is the product, owned by a capability manager and served through several ports.
- Merge the product management, not the platforms. Build outside-in, and keep it thin.
