Founders describe AI products in features. Engineers build them in capabilities. Most failed AI MVPs ship the wrong thing first because the two sides were never working off the same noun. A founder writes “a research assistant” in the PRD. An engineer reads “a research assistant” and silently translates that into classification of the query, retrieval against a corpus, extraction of structured snippets, generation of the synthesis, and possibly tool-use to fetch the next document. Five capabilities under one feature noun, each with its own frontier behavior, its own failure mode, its own eval. If the founder and engineer do not agree on the five before the build starts, they will be in different rooms by week four.
This article is the translation layer — a chapter inside the broader idea-to-product manifesto. It maps the seven LLM capabilities every AI product is built out of, sits between the idea validation playbook and the AI PRD explainer, and pairs with the feasibility check. Name your capabilities, you scope it. Skip the step, you build it twice.
Why the capability map exists
A feature is a product noun. A capability is an engineering primitive. The two are not interchangeable, and the mismatch is the most expensive defect in early AI product design.
Consider three feature nouns and their capability decompositions:
| Feature noun | Capability decomposition |
|---|---|
| Research assistant | Retrieval + extraction + generation + planning |
| Triage agent | Classification + extraction + tool-use |
| Customer support copilot | Classification + retrieval + multi-turn dialog + generation |
Each capability has independent frontier behavior. As of 2026, classification on short clean inputs is near-perfect with a small model; planning across more than five steps remains the frontier’s weakest link. A product that needs both does not have one quality dial — it has two, and the worst caps the system. Features hide this. Capabilities surface it on day one.
The capability map is not a replacement for the PRD; it is the input the PRD needs. The eval-first build playbook explains why eval suites are the right unit of scope, and the editorial argument is in stop scoping AI projects in features.
Capability 1: Classification
The task. Map an input to one label from a small set. Triage a support ticket. Tag a sales lead. Decide whether a contract clause is standard or non-standard.
Frontier behavior in 2026. Strong. On short clean inputs with five to twenty well-defined labels, frontier models reach human-level agreement without fine-tuning. Smaller models (Claude Haiku 4.5, Llama 3.3) often match larger ones at one-tenth the cost.
Where it fails. Long inputs with multiple signals competing for the label. Fuzzy label boundaries that humans also disagree on. Rare classes underrepresented in pretraining. Domain jargon where the surface label does not match the model’s prior.
MVP-shippable scope. Ten to twenty labels, single-paragraph inputs, a published rubric a reviewer could agree with, and a fallback for low-confidence cases.
Eval shape. Confusion matrix on fifty to two hundred labeled examples. A 90 percent classifier that misroutes one critical class to a benign one is a worse product than an 85 percent classifier that distributes errors evenly. A single accuracy number hides that.
Capability 2: Extraction
The task. Pull structured fields out of unstructured text. Party names, dates, dollar amounts from a contract. Line items from an invoice PDF. Skills from a resume.
Frontier behavior in 2026. Strong on small schemas (under twenty fields), mixed on large schemas with interdependent or conditionally required fields. Structured-output APIs have made schema adherence near-perfect; the open problem is field-value correctness, not field-name correctness.
Where it fails. Nested or merged-cell tables in PDF. Fields that require reasoning across multiple pages. Fields with similar names but different meanings (effective date vs. signature date vs. execution date). Implicit fields the model has to infer.
MVP-shippable scope. Five to fifteen fields with explicit definitions, a document set covering the variants you actually see, and a literal “field not present” return (do not let the model hallucinate a default).
Eval shape. Field-by-field exact-match for verbatim fields, normalized-match for dates and amounts, plus a hallucination-check subset where the field is deliberately absent. Most extraction bugs in production are silent hallucinations on absent fields; eval them explicitly.
Capability 3: Generation
The task. Produce fluent text from a brief. A sales email, a meeting summary, a marketing draft, a code snippet.
Frontier behavior in 2026. Fluent across all major frontier models — Claude Opus 4.8, GPT-5, Gemini 2.5 Pro. Fluency is no longer a differentiator. The differentiators are faithfulness (does the output reflect the input?), tone control, and length control.
Where it fails. Faithfulness on long inputs. Tone drift over multiple turns. Length adherence — models routinely over-produce on “short summary” prompts. Citation accuracy when generating from retrieved sources remains a frontier-wide problem.
MVP-shippable scope. A bounded brief (one paragraph of instruction, named inputs, length budget, tone reference) and a downstream check — a validator, a human-in-the-loop edit step, or both. Pure-generation products without a check fail in production within weeks.
Eval shape. Pairwise comparison or LLM-as-judge on twenty to fifty briefs. Reference-based metrics (ROUGE, BLEU) are mostly noise for modern frontier output; use rubric-based judges instead.
Capability 4: Planning and decomposition
The task. Break a high-level goal into executable steps. “Book me a flight to Berlin under five hundred euros next Thursday” decomposes into search, filter, compare, book.
Frontier behavior in 2026. Good up to four or five steps in a clean domain. Reasoning-trained variants show clear improvement on multi-step planning. Beyond five to seven steps, error compounds — a 90 percent step-accuracy gives 48 percent end-to-end success across seven steps.
Where it fails. Long horizons. Plans that require backtracking. Domains the model has not seen represented in pretraining. Plans where steps interact.
MVP-shippable scope. Three to five named steps, in a domain the model has clear coverage of, with each step’s output checked before the next runs. Do not chain ten steps and pray.
Eval shape. End-to-end completion rate on twenty to fifty representative goals, plus per-step accuracy logged separately. The separation is the single biggest debugging accelerator on agent projects.
Capability 5: Multi-turn dialog
The task. Hold a conversation that remembers context, asks clarifying questions, and stays on-task across many turns. A coaching assistant. A customer support agent. A long-running analyst conversation.
Frontier behavior in 2026. Mixed. Context retention within a session is strong, but stay-on-task discipline degrades over long conversations — the model drifts toward over-helpfulness, agreement, and verbosity. Reasoning models are more steerable here than non-reasoning ones.
Where it fails. Sycophancy. System-prompt drift as turns accumulate. Hallucinated memory of things the user did not say. Failure to ask for clarification when input is genuinely ambiguous.
MVP-shippable scope. Conversations bounded to a single goal, a system prompt that defines when to stop and when to ask, and a turn-count cap. Open-ended dialog products fail faster than any other capability.
Eval shape. Multi-turn rubric eval on twenty to fifty conversation scripts, scored per turn for on-task, clarification quality, and prompt adherence. Single-turn eval misses the failure mode entirely.
Capability 6: Tool-use and function calling
The task. Call an API, query a database, write to a CRM. The model chooses the tool, fills the arguments, reads the response, decides the next move.
Frontier behavior in 2026. Increasingly competent. Frontier models reliably select from small tool sets (under ten) with well-formed arguments. Tool-selection accuracy degrades materially over twenty tools.
Where it fails. Tool selection under ambiguous intent. Argument hallucination — inventing IDs rather than retrieving them. Error recovery — retrying identically rather than diagnosing.
MVP-shippable scope. Five to ten well-documented tools, an explicit schema for each tool’s arguments and return shape, and an error-handling contract that distinguishes recoverable from unrecoverable errors.
Eval shape. Per-call accuracy plus end-to-end task completion. Log every tool call in production from day one — tool-use bugs are invisible without call-level telemetry.
Capability 7: Retrieval
The task. Find the relevant documents, passages, or facts for a user query. RAG is the dominant architecture: embed query, search index, return top-k, pass to the model.
Frontier behavior in 2026. Off-the-shelf retrieval with a strong embedding model is a solid baseline. The cliff is between baseline and production — a default RAG pipeline rarely ships at quality without re-ranking, query rewriting, or domain-tuned embeddings.
Where it fails. Queries that need synthesis across many documents. Queries with domain jargon the embedding model does not represent well. Documents with poor chunking where section boundaries cut across coherent units.
MVP-shippable scope. A corpus you have the right to use, a chunking strategy reviewed against the actual document structure, fifty to two hundred labeled question–passage pairs, and a re-ranker on top of dense retrieval.
Eval shape. Recall-at-k on the labeled set, then end-to-end answer accuracy with the retrieved context. Retrieval can be the bottleneck even when the model is fine; the two-layer eval tells you which.
Capability 8 (rising): Multi-modal
The task. Read a chart in a PDF. Parse a screenshot. Transcribe a video. Reason about an image alongside text.
Frontier behavior in 2026. Rapidly improving and uneven. Image understanding is strong; document-image (OCR + layout) is solid; video and chart-reading remain the frontier-shifting capabilities. Never assume the text leader is the multi-modal leader.
Where it fails. Dense documents with mixed tables and prose. Charts where axis labels approach the model’s resolution limit. Videos longer than a few minutes. Domain-specific imagery without specialized fine-tuning.
MVP-shippable scope. A narrow image type (invoice scans, not arbitrary documents), a representative sample set, and a fallback path on low confidence.
Eval shape. Same as the text task it supports — extraction, classification, or generation — applied to image inputs.
Worked example: mapping a contract review assistant
Take one feature noun: “a contract review assistant for a mid-market legal team.”
This is what a founder writes. Now run the capability decomposition.
| User-visible behavior | Capabilities involved | Notes |
|---|---|---|
| Identify the key clauses in an uploaded contract (parties, term, fee, termination, IP, indemnification). | Extraction | Small schema, six to ten fields. Solved at MVP scope. |
| Flag clauses that deviate from the firm’s standard playbook. | Classification + retrieval | Retrieval against the playbook; classification deviate vs. standard. Solid with clean data. |
| Draft proposed redlines in track-changes format. | Generation | Bounded generation with a strong tone reference; needs a human edit step. |
| Answer follow-up questions (“what’s the standard market termination here?”). | Retrieval + multi-turn dialog | The risky pair. Bound to single-goal Q&A, not open-ended conversation. |
Four capabilities. The MVP should ship the first three before the fourth. Each gets its own eval, threshold, and ship gate.
A team that scopes this as a single feature will likely ship the dialog capability first because it demos best — and discover four weeks in that extraction-and-classification quality is what decides whether lawyers trust the product. A team that scopes it as four named capabilities ships the load-bearing ones first. That is the difference the map makes.
What you do with the map
The capability map is an input artifact, not a deliverable. Once your idea is decomposed into named capabilities, three things happen:
-
The PRD becomes scope-able. Each capability gets its own section, eval threshold, and ship gate. See the AI PRD explainer for the section anatomy.
-
The feasibility check becomes targeted. Instead of asking “can AI do contract review?” you run the feasibility check against the load-bearing capability first — usually extraction or classification, rarely generation.
-
The build becomes staged. Ship the load-bearing capability first, prove the threshold, then layer the next. The eval-first build playbook is the operational pattern.
If your idea is too vague to decompose, it is too vague to build. The map is also a vagueness detector.
Map yours: pull the AI MVP scoping worksheet.
FAQ
Why seven capabilities and not three or twenty?
Three is too coarse for engineering scope. Twenty collapses into overlap. Seven (plus rising multi-modal) is the level at which engineers actually scope and eval distinct primitives, and it maps reasonably to how frontier vendors document their model capabilities.
Is reasoning a separate capability?
Reasoning is a property of how a capability is executed, not a separate primitive. Reasoning-trained models improve planning, dialog discipline, and complex tool-use selection. They do not change the taxonomy.
What about agents?
An agent is a composed system — typically planning plus tool-use plus retrieval plus dialog — not a primitive. The capability map decomposes an agent into its primitives so you can scope and eval each.
How does this differ from a feature list?
A feature list describes what the user sees. A capability map describes what the model has to do under each feature. Features hide whether two parts of the product have very different quality dials. Capabilities surface it.
Do I need this if my idea uses one capability?
Single-capability products are the easiest case. Even then, naming the capability forces the eval design, the failure-mode analysis, and the MVP-shippable scope. The map is shorter for you; the discipline is the same.
Are capability boundaries the same across vendors?
Yes for the primitive. The frontier-leader on each capability varies and shifts quarterly. Run the feasibility check against your top two or three models, not just your favorite.
Does the map change as frontier models improve?
The primitives are stable. The MVP-shippable scope for each capability shifts as frontier models get stronger — what was hard in 2024 is solid in 2026. Re-check scope guidance quarterly; capability names hold up across years.
Where does this fit in the idea-to-product flow?
Between idea validation and PRD. The idea validation playbook confirms the idea is real; the capability map translates it to primitives; the PRD writes those primitives into scope-able sections; the feasibility check tests the load-bearing primitive before commit.
What is the single biggest mistake when applying the map?
Assigning the same eval threshold to every capability. Extraction at 95 percent and dialog at 95 percent are not the same engineering ask. Set thresholds per capability, tied to user impact.
How long does it take to map an idea?
Thirty to sixty minutes for a clear idea. The decomposition is fast. The discipline is in writing it down — naming each capability, listing failure modes, and committing to a per-capability eval threshold before any engineer starts building.
Dirk Jan van Veen, PhD
