This is blog post on the AI Context use case concerned with encouraging the discoverability and reuse of existing APIs, leveraging existing API infrastructure to quantify what API, schema, and tooling reuse looks like, and incentivizing reuse of APIs and schema across the software development lifecycle—reducing API sprawl and hardening the APIs that already exist.
As organisations rush headlong into the AI revolution, a familiar pattern is emerging. For integrations, we’ve seen it before with APIs, with microservices, and now with the Model Context Protocol (MCP). The technology arrives, excitement builds, adoption accelerates—and then the cracks begin to show. Today, many enterprises find themselves in precisely this position with MCP, caught between ambitious AI investments and the sobering realisation that their governance practices are failing to keep pace.
If you’re running an API product business—one where APIs are your primary revenue stream—you’re likely grappling with a critical question right now. What should our strategy be for MCP (Model Context Protocol) in the age of agentic AI? This has moved on from being a theoretical concern. The signals are everywhere. Your established API business is humming along nicely—you’ve got sophisticated infrastructure, mature governance practices, strong customer onboarding, and the revenue numbers to prove it all works. But then the landscape shifts. Agentic AI arrives. Suddenly, you’re fielding questions about how agents will discover and use your APIs. You’re watching competitors experiment with MCP servers. You’re wondering if your current approach is future-proof.
For software solution providers in the SaaS space, the journey towards artificial intelligence integration has become increasingly complex. Many organisations have invested heavily in building their own branded AI experiences—co-pilots, assistants, and intelligent features designed to showcase their deep industry expertise. However, a quiet revolution is taking place in how AI agents interact with services, and it’s forcing even the most API-mature companies to reconsider their strategic priorities.
This is blog post on the AI Orchestration use case, focusing on he data, skills, and capabilities that artificial intelligence agents used internally can use to automate and orchestrate tasks while discovering and negotiating with other agents to accomplish specific goals. This use case employs the open-source Agent-2-Agent specification to securely and confidently enable agentic activity across operations.
This is blog post on capabilities meant for the API Evangelist blog, providing an opionated look at what capabilities are and why is the time we need them to align engineering with business outcomes, but also provide the much needed context for powering AI copilots and agents, help increase we will achieve the outcomes we desire.
This is blog post on managing costs when it comes to integrations and automation using a capabilities-driven approach, focusing on the cost, spend, and budget manage aspects of integrating primarily across 3rd-party services, but also possibly with internal APIs, helping bring more attention to the cost of operation integrations and automation.
This is blog post on the AI Context use case, focusing on empowering companies to take control of their data that resides across the third-party SaaS solutions they use regularly. The data sovereignty movement is centered on establishing more control over the data generated across the different services you depend on, ensuring data is integrated, migrated, and synced to data and object stores where a company has full control and access.
This is blog post focus on innovation, helping shine a light on how managing cost, velocity, and risk can help lead to more innovation, helping enterprises achieve an agreed upon around what innovation looks like by focusing on capabilities that consistently drive conversations around cost, velocity, and risk of integration and automation.
This is blog post announcing the Nafitko Signals progam on the API Evangelist blog, providing a different perspective on how the program came to be and why it is turning into something more, helping provide a behind the scenes snapshot on what is going on with the research, but also the conversations we are having with design, service, and market partnrs.
This is a blog post about the Naftiko Signals white paper that was published in December, providing an overview of the paper and the program behind, and why Signals provides an important way of looking at the enterprise system whether you are inside or outside of that system, helping generate more leads using the white paper.
This is a business outcomes blog post focused on managing risk when it comes to integrations and automation, helping demonstrate how a capabilities-driven approach can help with security, privacy, compliance, and other common approaches to managing risk across enterprise operations, from the dimensions business care about.
This is blog post on the SQL Data Access use case, focusing on consistently unlocking the data companies currently depend upon across multiple third-party SaaS providers and a variety of existing database connections via JDBC and ODBC to ensure AI integrations have the data they require. Data today is spread across many internal and external systems, and making it consistently available as part of AI integrations has significantly slowed the delivery of new products and features.
This is business outcomes blog post focued on velocity associated with integrations and automation, helping shine a light on moving the right velocity when it comes to the 3rd-party and internal systems we use, helping ensure we have a solid map of the services and the domains in which they are used to help teams move faster when using.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.