Problem Statements
Every problem documented here came from a real conversation with a practitioner at an enterprise operating integrations at scale. Each statement captures who feels the pain, what the context is, the business impact, and where Naftiko can help today and tomorrow.
67 problem statements across 5 themes.
| Problem Statement | Context | Impact | Naftiko Today | Naftiko Tomorrow | Type |
|---|---|---|---|---|---|
|
Need API Teams to Support Copilots
API teams lack common tooling and guidance to deliver MCP servers alongside their existing APIs for copilot integration.
|
|||||
|
Need Governed Approach to 3rd-Party Services via MCP
Teams are independently adopting 3rd-party MCP servers without a governed approach to discovery, onboarding, and authentication.
|
|||||
|
Need to Securely Enable MCP in Developer IDEs
Security teams must evaluate and approve MCP server usage within developer IDEs before enterprise-wide adoption can proceed.
|
|||||
|
Need MCP Streaming to Work with Enterprise Security
HTTP streaming and SSE connections required by MCP and AI services conflict with existing corporate security policies and infrastructure.
|
|||||
|
Need Agent-to-Agent Identity Propagation
Identity and authorization tokens must be properly propagated when AI agents call other agents or services in multi-hop scenarios.
|
|||||
|
Need AI FinOps
Organizations need to understand and control the total cost of ownership across AI models, MCP servers, and third-party services.
|
|||||
|
Need MCP to Integrate with Existing Governance Tooling
Organizations need to understand how MCP fits into existing API infrastructure and governance tooling they have invested in over the past decade.
|
|||||
|
Need Semantic Search for API and MCP Discovery
Traditional filter-based catalog search doesn't match how developers think about their problems, leading to duplicate API development.
|
|||||
|
Need AI-Powered Enrichment of OpenAPI Metadata
API documentation and metadata quality must improve so that both developers and AI agents can effectively discover and use internal APIs.
|
|||||
|
Need to Define and Govern MCP Servers Not One-to-One
MCP servers that combine multiple APIs into business-oriented capabilities need a standard way to be described and governed.
|
|||||
|
Need MCP Documentation
The assumption that AI will figure out how to use MCP servers is wrong, and traditional documentation and discovery are still required.
|
|||||
|
Need to Prevent MCP Sprawl
Multiple teams are independently building MCP integrations for the same third-party services without coordination or visibility.
|
|||||
|
Need Auto-Discovery of API Artifacts
Building an accurate catalog of APIs and services requires automated discovery rather than manual registration that developers resist.
|
|||||
|
Need Governance Rules in Coding Assistants
Governance rules need to be available directly in developers' coding assistants and AI agents, not just in standalone tools and pipelines.
|
|||||
|
Need Governance Rule Distribution in Restricted Environments
Enterprise security restrictions prevent using standard distribution mechanisms to deliver governance rules to all API designers.
|
|||||
|
Need Governance Review Tracking
Morgan needs to track and report on API governance reviews across the portfolio.
|
|||||
|
Need to Define What Reuse Means
Pat has been asked to drive API reuse but the organization has never defined what reuse means.
|
|||||
|
Need Discoverability Not Just Governance
Pat realizes the organization has been focused on governance when the actual problem is that teams can't find what already exists.
|
|||||
|
Need Reuse Metrics That Connect to Business Outcomes
Laura needs reuse metrics that show business impact, not just activity counts.
|
|||||
|
Need to Discover and Govern Shadow API Gateways
Riley has an accurate central API inventory but cannot account for APIs on teams' own AWS API Gateways.
|
|||||
|
Need to Map APIs to Products and Business Capabilities
Riley has a clean API inventory but needs to understand how APIs map to products and business capabilities.
|
|||||
|
Need Artifact and Data Element Reuse
Riley realizes reuse isn't just about whole APIs—it's about reusing schemas, data elements, headers, and parameters.
|
|||||
|
Need to Quantify and Incentivize API Reuse
Riley was asked by leadership to answer how well they are reusing APIs and how they are incentivizing improvement.
|
|||||
|
Need Reuse Assessment in Architecture Review
Tina needs a mechanism during architecture review that provokes teams to assess existing capabilities before proposing new ones.
|
|||||
|
Need Central Catalog of 3rd-Party APIs
Noah needs a single catalog where internal teams can discover what 3rd-party APIs the organization uses.
|
|||||
|
Need Centralized Credential Management
Morgan needs teams to obtain API tokens and keys from an internal gateway rather than directly from 3rd-party providers.
|
|||||
|
Need to Manage Spend Across All 3rd-Party APIs
Noah needs to manage and attribute spend across all 3rd-party APIs consumed by many different teams.
|
|||||
|
Need to Govern AI-Generated Code
Morgan needs to ensure AI coding assistants follow security policies when generating code, with attestation of compliance.
|
|||||
|
Need API Documentation Rewritten for AI
Nico discovered that MCP servers built from existing API documentation fail because the docs were written for humans, not AI agents.
|
|||||
|
Need Task-Oriented MCP Tools
Nico sees MCP servers exposing every API option when agents only need task-specific subsets, wasting context and causing confusion.
|
|||||
|
Need Developer Sites to Be AI-Scrapable
Developer documentation sites must be rebuilt to enable AI agents to efficiently consume them, including markdown endpoints for full content access.
|
|||||
|
Need Agent Evaluation Framework
Context engineers need to evaluate whether AI agents called APIs correctly—with right parameters, in right order—not just whether the final output looks correct.
|
|||||
|
Need to Translate Many MCP Tools
Context engineers need to consolidate many upstream APIs and MCP servers into a smaller set of efficient tools that agents can use effectively.
|
|||||
|
Need Unified View of Integration Landscape
The head of integration needs a single view of the integration landscape, but the data isn't in enterprise architecture tools, API repositories, or any individual platform.
|
|||||
|
Need to Balance Vendor Lock-In
The head of integration must minimize vendor lock-in while recognizing that proprietary solutions sometimes offer 2x performance over standards-based alternatives.
|
|||||
|
Need to Know When to Exit Technologies
The head of integration must determine optimal timing for technology exits—too early wastes investment, too late increases migration cost.
|
|||||
|
Need Governance Framed as Golden Path
Developers perceive governance as friction and avoid it unless compliance is the easiest path.
|
|||||
|
Need Observability Across Multi-Hop Integration
The head of integration needs observability across systems where requests traverse multiple layers with principal propagation, but gateway-level observability isn't enough.
|
|||||
|
Need Integration Platforms That Scale
Vendor integration platforms work for typical enterprise scale but break down at extreme scale with thousands of interfaces.
|
|||||
|
Need Governance to Be Seamless
API governance must be embedded seamlessly into the developer workflow so that the compliant way of building APIs is also the easiest and most secure way.
|
|||||
|
Need Documentation to Teach What Questions to Ask
MCP-enabled documentation disproportionately benefits experienced developers because junior developers don't know what questions to ask.
|
|||||
|
Need MCP Documentation to Provide Operational Context
Developers need to understand how an API behaves in production, but most documentation remains reference-only.
|
|||||
|
Need Developer Experience Treated as Product Discipline
Documentation efforts are treated as a publishing exercise rather than a product discipline that actively enables and teaches developers.
|
|||||
|
Need Question Formation Embedded in MCP Workflows
MCP-enabled documentation should accelerate implementation work inside IDEs and copilots, but 'ask anything' interfaces fail when users don't know the right prompts.
|
|||||
|
Need Clear Ownership for Context Layer
The repo context layer (README, CONTRIBUTING, AGENTS) has no clear owner as AI copilots roll out across IDEs.
|
|||||
|
Need Governance for Agent-Driving Docs
Organizations can enforce coding standards and CI gates but cannot enforce equivalent governance for the Markdown files that shape AI agent behavior.
|
|||||
|
Need Minimum Agent Operational Documentation
Repositories can look documented but still fail basic agent tasks because the docs were written for humans, not for agent execution.
|
|||||
|
Need Explicit Agent Boundaries
Repositories need to explicitly declare what AI agents are allowed to change and what is off-limits.
|
|||||
|
Need Continuous Agent Readiness Checks
Scaling IDE copilots across hundreds of repos requires a repeatable way to verify each repository is agent-ready.
|
|||||
|
Need Standardized Structures for Agent-Consumable Markdown
Markdown docs must follow predictable, machine-reliable structures so agents can consistently locate authoritative answers.
|
|||||
|
Need Knowledge Graphs and Semantic Layers for API Context
Organizations need knowledge graphs and semantic layers to give AI agents structured, contextual understanding of API relationships, business logic, and entity models — not just flat catalogs.
|
|||||
|
Need to Govern the Proliferation of Agent Communication Protocols
Beyond MCP, protocols like A2A, ACP, AP2, and x402 are proliferating — enterprises need unified governance across all agent communication protocols, not just one.
|
|||||
|
Need Context Engineering Practices Across the API Lifecycle
API teams need to adopt context engineering as a discipline — curating the optimal set of instructions, knowledge, and feedback that enables agents to effectively discover, understand, and consume APIs.
|
|||||
|
Need APIs Ready for Agentic Commerce and Autonomous Transactions
Agentic browsers and AI workspaces will autonomously discover, evaluate, and transact via APIs — organizations need APIs that are not just discoverable but transactable by agents with proper governance guardrails.
|
|||||
|
Need Synthetic Testing and Simulation for Agent-API Interactions
Organizations need to simulate how AI agents will discover, consume, and interact with their APIs at scale before production — using synthetic agent personas and AI-powered simulation environments.
|
|||||
|
Need AI-Native Data Formats for Agent-Consumable API Responses
Traditional API response formats like JSON and XML aren't optimized for AI agent consumption — organizations need data formats and response structures that minimize token usage while maximizing agent comprehension.
|
|||||
|
Need APIs Discoverable by Agentic Browsers and AI-Native Workspaces
Agentic browsers and AI-native workspaces are becoming the primary interface for discovering and consuming services — APIs need to be optimized for Generative Engine Optimization (GEO), not just traditional developer portals.
|
|||||
|
Need an Internal MCP Server Registry as an Allow-List
Enterprises need an internal registry of approved MCP servers that surfaces inside the developer IDE, acting as an allow-list so developers discover only vetted servers.
|
|||||
|
Need to Separate MCP Discovery Registry from Package Distribution
The MCP discovery registry (which servers are approved) and the package registry (where the binary actually lives) are two different systems with different governance requirements.
|
|||||
|
Need to Align Enterprise AI Rollout with Product GA Timing
Enterprise contracts only cover generally-available features, so AI tooling rollouts at scale must wait for GA even when developers are already asking for preview capabilities.
|
|||||
|
Need Disease-Specific Information Models
Iris finds that EHRs are deliberately disease-agnostic, so the right information is rarely captured at the first patient encounter — sending patients on multi-month detours through the wrong specialists. She needs disease-specific information models that scaffold what to capture and when.
|
|||||
|
Need Cross-Organizational Patient-Centered Data Flow Across Legal Silos
Iris sees the patient's data sit in adjacent organizations that legally cannot share it — region vs municipality, primary vs secondary purpose, country vs country — even though all of them care for the same person. She needs a patient-centered data fabric that the law can actually permit.
|
|||||
|
Need Synthetic Data Generation for Regulated-Domain Research Access
Iris waits months to years for ethical approvals and data extractions before she can touch real patient data. She needs a synthetic-data pipeline that's data-driven, schema-conformant, and privacy-preserving — so research can move while the legal track runs in parallel.
|
|||||
|
Need Standards Adoption Forced by Regulation
Iris has watched well-designed healthcare data standards stall for years until regulation made them mandatory — FHIR via 21st Century Cures, openEHR via the European Health Data Space. She needs the regulation-to-implementation path to be cheap, demonstrable, and reusable.
|
|||||
|
Need Multi-Stakeholder Patient-Centered Interoperability
Iris's project pulls in a vendor, a consultancy, a healthcare provider, and a university — each cares about a different slice of the same patient. She needs an interoperability fabric that lets every stakeholder see only what they should and contribute only what they own.
|
|||||
|
Need EHR-to-Open-Standards Mapping (OMOP, openEHR, FHIR)
Iris and peers across Sweden are starting to ask the same question — how do we map raw vendor EHR records into open standards (OMOP, openEHR, FHIR) without doing it by hand for every region. She needs a declarative, reusable mapping layer that survives EHR vendor changes.
|
|||||
|
Need MCP Documentation in Existing Portal Pipelines
Enterprises with mature OpenAPI portal pipelines need MCP-server documentation that flows through the same build process — not vendor-coupled extensions or a parallel doc system.
|