Glossary
API & Agent Glossary
Canonical definitions for API product teams building what agents want.
Agent Access Stack
The Agent Access Stack is the layered model for how an AI agent actually reaches a product: your API as the foundation, with MCP, CLI, and Skills as layers built on top of it, and OpenAPI/documentation describing all of it. Emmanuel Paraskakis teaches this stack, building on Aakash Gupta's public analysis of how companies like Stripe, Cloudflare, GitHub, and Shopify ship for AI agents, with a consistent conclusion: get the API layer wrong and every layer above it inherits the problem.
Read the definition →Agent-Facing Product
An Agent-Facing Product is a product built so an AI agent can use it directly on a user's behalf, not just a product with a human-friendly UI. In practice that means the value of the product is reachable through an API, an MCP server, a CLI, or a Skill — the same surfaces an agent looks for when a UI isn't an option. Emmanuel Paraskakis developed this framing for his "What Agents Want from Your Product" workshop.
Read the definition →Agent-Ready API Checklist
The Agent-Ready API Checklist (published as "Build AI-Ready APIs — API Checklist") is Emmanuel Paraskakis's free, 12-insight, 2-pitfall framework for auditing whether an API can be used correctly by an AI agent. It covers description accuracy, error design, resource discovery, idempotency, pagination, response design, and deprecation signaling — the full set of places agent usability tends to break. It's the primary free lead magnet behind Emmanuel's AI-Ready API positioning.
Read the definition →AI-Ready API
An AI-Ready API is an API designed so an AI agent, not just a human developer, can discover, understand, and call it correctly on the first try. It follows predictable, well-documented conventions instead of relying on a developer reading the docs or asking a question when something is unclear. Emmanuel Paraskakis coined and popularized the term through his "Build AI-Ready API Products With MCP" course and the free AI-Ready API Checklist.
Read the definition →API Design Review
An API Design Review is a structured, multi-stage process for catching API design and implementation issues before they become expensive rework, rather than relying on one large review at the end. Emmanuel Paraskakis's version uses three gates — Design Review, Pre-Implementation, and Pre-Release — each with specific participants and specific questions, delegating anything a linter or automated tool can catch so human reviewers focus only on what automation can't judge.
Read the definition →API Developer Experience
API Developer Experience (API DX) is how easy or hard it is for a developer, and increasingly an AI agent, to go from discovering your API to succeeding with it in production. Emmanuel Paraskakis teaches it as a 4-stage funnel — Discover, Learn, Succeed, Retain — that mirrors a marketing funnel but for developer adoption instead of consumer purchase. It's the practical, measurable version of "is my API good," broken into stages you can actually diagnose and fix independently.
Read the definition →API Governance
API Governance is the set of shared standards, automated checks, and review gates that let multiple teams design consistent, secure APIs without a slow, centralized approval process for every decision. Done well, it removes repeated debates (naming conventions, pagination, error formats) by pre-deciding them once, and it delegates what tools can catch to tools, saving human review for what automation can't judge. Emmanuel Paraskakis's core position, taught in API Product Mastery: strong governance makes teams faster, not slower.
Read the definition →API Lifecycle
The API Lifecycle is the full sequence of stages an API moves through — design, documentation, security, deployment/operations, versioning, and eventually deprecation — not just the moment it's built and shipped. Treating an API as having a lifecycle, rather than a single launch event, is what makes long-term maintenance, versioning, and eventual sunset predictable instead of ad hoc. Emmanuel Paraskakis teaches this as a foundational concept in API Fundamentals for Product Managers.
Read the definition →API Product Manager
An API Product Manager is a product manager whose product is the API itself, with developers and other systems as the buyer/user, not an end-user-facing screen. The role covers the same responsibilities as any PM — strategy, roadmap, adoption, monetization — applied to a product that's consumed entirely through code rather than a UI. Emmanuel Paraskakis has taught this discipline through three Maven courses (API Fundamentals, API Product Mastery, and Build AI-Ready API Products With MCP) built around one career message: become the PM who builds what agents want.
Read the definition →API-First
API-First is an approach to building software where the API contract is designed and validated before any implementation code is written, treating the API as the product's primary interface rather than an afterthought bolted onto existing code. It's distinct from, but complementary to, "design-first" tooling practices — API-first is the organizational commitment, design-first is often how it's executed in practice. Emmanuel Paraskakis teaches this as a foundational concept in API Fundamentals for Product Managers.
Read the definition →DX Assessment
A DX Assessment is Emmanuel Paraskakis's enterprise engagement that audits a company's API developer experience across four stages — Discover, Learn, Succeed, Retain — and delivers a report with prioritized, actionable recommendations. It's aimed at companies with 10+ public or partner APIs where developer friction is costing adoption, support load, or partner revenue.
Read the definition →Headless Product
A Headless Product is a product whose value can be fully delivered through APIs, CLI, MCP, and Skills, just as well as through its own UI, so an AI agent can use it without ever touching the interface a human would use. The term borrows from "headless CMS" but extends it to the whole product, not just content delivery. Emmanuel Paraskakis's framing adds a growth condition: the product has to stay profitable and growing while operating headless, not just technically capable of it.
Read the definition →MCP Hub
An MCP Hub is an internal, company-wide registry or gateway that aggregates multiple MCP servers so different teams' agents can discover and use them consistently, similar in spirit to an API gateway or catalog but purpose-built for MCP tools.
Read the definition →MCP Server
An MCP server is a program that implements the Model Context Protocol, Anthropic's open protocol for connecting AI applications (like Claude) to external tools, data, and actions in a standard way. It exposes a product's capabilities as callable "tools" an AI agent can discover and use, the same way a REST API exposes endpoints for developers. In Emmanuel Paraskakis's framing, an MCP server is a wrapper on top of your API, not a replacement for it — the API is the foundation.
Read the definition →Partner API
A Partner API is an API a company exposes specifically to external business partners, not to end consumers or internal teams, designed around a specific partner business outcome rather than pure technical completeness. The design question isn't "what should our API look like" but "what business problems can our partners solve with it" — success is measured by partner-generated business value, not just API usage. Emmanuel Paraskakis covers this as a specific API category in API Product Mastery for Experienced PMs.
Read the definition →