Side by Side
At a Glance
14 dimensions of comparison between Naftiko and Stackmint — same row, different layer of the stack. Scan top-to-bottom to see where each product makes a different choice on the same axis.
Dimension
Naftiko
Stackmint
Category
Naftiko
Spec-driven capability platform — open-source engine + Fleet
Stackmint
Governed execution platform for enterprise AI workflows
Origin
Naftiko
Kin Lane (API Evangelist) + Jerome Louvel (Restlet → Talend → Qlik), 2025
Stackmint
Florian Boymond (CEO), framing AI governance as “separating Intelligence from Execution”
Primary primitive
Naftiko
Capability — declarative YAML that consumes APIs and exposes REST/MCP/Skills
Stackmint
Bud (atomic execution unit) composed into Branch (workflow)
Layer in the stack
Naftiko
Between APIs and agents — capability spec + runtime engine
Stackmint
Between LLMs and business systems — execution control plane
Core artifact
Naftiko
*.capability.yaml in your Git repo — portable, versionable, runnable anywhere
Stackmint
Buds (JS/TS classes) + Branches (JSON config) authored inside the Stackmint platform
Open source posture
Naftiko
Apache 2.0 Framework (Ikanos); free embedded UX (VS Code, Backstage, Docker Desktop)
Stackmint
Proprietary; no public open-source artifacts
Deployment model
Naftiko
Self-hosted Docker / Kubernetes / GitOps with NaftikoCapability CRD
Stackmint
SaaS only — api.stackmint.ai; no self-hosted or on-prem option
Multi-protocol
Naftiko
Consumes HTTP/REST; exposes REST + MCP + Skills + A2A (roadmap) + Webhook (roadmap)
Stackmint
REST API + MCP-compatible tool surface; agents are Stackmint’s own runtime
Governance scope
Naftiko
Spec-level tags (agent safety, billing, data sensitivity) + @naftiko/rules + Kyverno admission
Stackmint
Runtime gates — budget circuit breakers (variance capped < 5%), human approval routing, ROI telemetry
Discovery surface
Naftiko
Backstage capability catalog + VS Code topology + Fleet control API
Stackmint
Stackmint console + REST API + per-client MCP tools catalog
Audit / observability
Naftiko
OpenTelemetry built-in (no sidecar), Prometheus /metrics, structured JSON logs
Stackmint
Per-run telemetry — token usage, step traces, ROI metrics, board-reportable
Identity / auth
Naftiko
API Key / Bearer / Basic / Digest on consumes; per-operation auth on exposes
Stackmint
Bearer token + X-Stackmint-Org-Id header; admin / mcp / runtime / bud.run scopes
Cost / FinOps
Naftiko
K8s label propagation → Kubecost; per-operation billing tags on consumes
Stackmint
Budget circuit breakers cap variance < 5%; per-run token usage; board-reportable ROI
Founder framing
Naftiko
“API integration reinvented for the AI era” — capability-first, spec-driven, governable
Stackmint
“Separating Intelligence from Execution” — governance as architectural
Common Ground
Where They Overlap
Both Naftiko and Stackmint bet on the layer above per-vendor MCPs. Here are the 8 concrete places where those bets actually meet — same problem, sometimes the same shape, increasingly the same conversation.
1
Both target the production gap in enterprise AI
Naftiko frames the problem as fragmented API sprawl that has to be wrapped into governable capabilities before agents can use it. Stackmint frames it as “70% of enterprise AI projects fail to reach production because execution isn’t controlled.” Different vocabulary, same gap between experiment and production.
2
MCP is a first-class concept for both
Naftiko exposes capabilities as MCP servers any agent runtime can discover. Stackmint catalogs MCP tools as governed platform resources per client. Both treat MCP as protocol-level, not just “another API.”
3
REST API as the developer-facing primary
Both ship a REST API as the primary developer integration surface. Naftiko via the capability’s
exposes: rest adapter; Stackmint via api.stackmint.ai/v1 with structured clients / branches / buds / runs / mcp-tools resources.4
Both decouple business logic from LLM provider choice
Stackmint routes Bud and Branch execution across OpenAI, Anthropic, Mistral, DeepSeek, Bedrock, Azure AI, Vertex, Hugging Face, Cohere and more. Naftiko capabilities consume any LLM API behind the same declarative contract — both products refuse to hard-code a model.
5
Deep observability of execution
Stackmint exposes step-by-step run traces, token usage, and per-run ROI metrics through its
runs endpoint. Naftiko exposes OpenTelemetry traces, /metrics, and structured JSON logs on every capability call. Both treat execution telemetry as a first-class product surface.6
Org-level scoping / multi-tenancy
Stackmint partitions everything by
client with the X-Stackmint-Org-Id header. Naftiko partitions by namespace + labels + Fleet-level cost attribution. Both assume large enterprise needs multiple isolated tenants under one platform.7
Policy enforcement is in-product, not bolted on
Stackmint enforces budget circuit breakers, approval-gate routing, and compliance routing as part of the runtime. Naftiko enforces spec-level rules, Kyverno admission, and
@naftiko/rules at design / admit / runtime altitudes. Neither product treats policy as a downstream concern.8
Both reject the “raw agent” deployment
Stackmint introduces the Semantic Execution Layer (Ontology → Semantics → Branches → Agents → Runtime/Audit). Naftiko introduces the Capability spec (Consumes → Exposes → Operations → Tags → Rules). Both refuse to let an agent reach a business system without a structured intermediary.
Where We Diverge
How Naftiko Is Different
The clearest single-sentence difference: Naftiko is the spec-driven capability layer between your APIs and your agents; Stackmint is the governed execution platform that runs the agents themselves — different layers of the same stack, complementary rather than competing.
1
Where the artifact lives
Naftiko
*.capability.yaml in your Git repo, portable across runtimes, versionable, diffable, reviewable in PRs.Stackmint
Buds (JS/TS) and Branches (JSON) authored inside the Stackmint platform, coupled to the Stackmint runtime.
Portability is the largest single difference — Naftiko capabilities run anywhere the Naftiko engine runs.
2
Deployment model
Naftiko
Self-hosted Docker / Kubernetes / GitOps. Customer owns the runtime; data stays in customer infrastructure.
Stackmint
SaaS only. No self-hosted, no on-prem, no private-cloud option. Customer data flows through Stackmint.
3
Open source posture
Naftiko
Apache 2.0 Framework, free embedded UX (VS Code, Backstage, Docker Desktop). Paid Standard / Enterprise editions on top.
Stackmint
Closed source, proprietary platform. No public source, no community fork path.
4
What’s first-class — capabilities or workflows
Naftiko
Capabilities are first-class. In-spec orchestration (sequential, conditional, for-each, parallel-join on roadmap) composes capabilities into workflows.
Stackmint
Workflows (Branches) and atomic units (Buds) are first-class. Capabilities are emergent — they happen by Bud composition, not as a distinct primitive.
5
How governance is enforced
Naftiko
Spec-level governance — declarative tags +
@naftiko/rules + Kyverno admission. Enforced at design time, admission time, and runtime.Stackmint
Runtime governance — budget circuit breakers (variance < 5%), human approval-gate routing, per-run ROI telemetry. Enforced at execution time.
Spec-level governance composes across runtimes; runtime governance enforces inside one runtime.
6
MCP role
Naftiko
Capabilities are EXPOSED as MCP tools for any agent runtime (Claude Code, Cursor, Cline, your own) to discover and invoke.
Stackmint
MCP tools are CATALOGED inside the platform and invoked under Stackmint governance. Stackmint is the agent runtime.
7
Cost attribution
Naftiko
Kubernetes label propagation → Kubecost; per-operation billing tags on consumes; FOCUS-aligned FinOps.
Stackmint
Budget circuit breakers cap variance under 5%; per-run token usage; board-reportable ROI metrics.
8
Agent runtime
Naftiko
Agent runtime is external. Naftiko exposes the tool surface; whatever agent runtime is sitting in front consumes it via MCP.
Stackmint
Stackmint IS the agent runtime. Agents are Stackmint runtime processes that select and execute Branches based on context.
This is the cleanest line between the two products — Naftiko ships the capability layer, Stackmint runs the agent layer.
Partnership Thesis
Service Partnership
Stackmint runs the governed agent. Naftiko ships the capability the agent reaches. Two products at two layers of the same stack — Stackmint at the execution control plane; Naftiko at the capability layer underneath. The capability map below is the integration kit that wires these two products together.
“Stackmint executes the workflow. Naftiko is what the workflow calls. Together — the governed agent runtime above the spec-driven capability layer.”
Two First-Meeting Questions
Q1. MCP catalog feed
Would Stackmint accept a Naftiko-published MCP capability registry as a client-importable tool source — so every Naftiko capability becomes a Stackmint-governable tool with one declarative registration, instead of customers manually wiring each MCP server into the Stackmint console?
Q2. Governance metadata propagation
Naftiko capabilities carry rich governance metadata (agent safety hints, billing granularity tags, data sensitivity classification, lifecycle stage). Stackmint runs budget circuit breakers, approval-gate routing, and ROI telemetry. Would the two sides agree on a shared metadata schema so a Naftiko capability surfaces inside Stackmint with its safety / billing / sensitivity tags already populated — preventing customers from having to author governance twice?
Integration Kit
Partnership Capability Map
10 Naftiko capabilities authored to integrate with Stackmint as a service partner. Each one consumes a specific Stackmint surface and exposes it as REST + MCP through the Naftiko engine — shipped as inline alpha2 YAML in the api-evangelist repository and published to the apis.io capability catalog.
Stackmint Clients Discovery
stackmint-clients-discovery
Read-only discovery of Stackmint clients (org-level scoping roots) into Naftiko Fleet — every Stackmint client visible alongside the rest of the API surface inventory in Backstage.
Stackmint Branches Discovery
stackmint-branches-discovery
Read-only discovery of Stackmint Branches (reusable workflows) per client — see every workflow authored in Stackmint and identify which need a Naftiko-shaped capability backing them.
Stackmint Buds Discovery
stackmint-buds-discovery
Read-only discovery of Stackmint Buds (atomic execution units) per client — map Bud inventory to Naftiko capabilities and identify duplicates, gaps, and reuse opportunities.
Stackmint Branch Run
stackmint-branch-run
Invoke a Stackmint Branch from inside a Naftiko capability — Naftiko orchestrates upstream, Stackmint executes with budget circuit breakers, approval gates, and ROI telemetry applied.
Stackmint Bud Run
stackmint-bud-run
Invoke a Stackmint Bud as a sub-operation in a Naftiko orchestration — useful when an existing Bud encapsulates work a Naftiko capability should hand off rather than reimplement.
Stackmint Runs Telemetry
stackmint-runs-telemetry
Pull Stackmint Run telemetry (status, step traces, token usage, ROI) into Naftiko's OpenTelemetry pipeline — one observability surface across both platforms.
Stackmint MCP Tools Catalog
stackmint-mcp-tools-catalog
Discover MCP tools cataloged inside a Stackmint client. One catalog view across Stackmint-managed tools and Naftiko-published MCP capabilities side by side.
Stackmint MCP Tool Invoke
stackmint-mcp-tool-invoke
Invoke a Stackmint-cataloged MCP tool through Stackmint's governance layer (budget caps, approval routing, audit trail apply) from inside a Naftiko capability.
Stackmint Providers Config
stackmint-providers-config
Configure Stackmint LLM and multimodal provider credentials (OpenAI, Anthropic, Mistral, Bedrock, Azure, Vertex, etc.) from declarative Naftiko spec + binds — not the Stackmint console.
Stackmint Assignments Policy
stackmint-assignments-policy
Set Branch approval-gate assignments (compliance routing to legal, finance, ops) on Stackmint Branches from Naftiko governance metadata — governance authored once, enforced both sides.
