The infrastructure for AI professional tools has become remarkably accessible. FastMCP means a working MCP server takes an afternoon. The underlying models are available via API. PDF extraction is a solved problem. Deployment infrastructure is standard. The gap between “idea” and “running code” has never been smaller.

What hasn’t become accessible is knowing what to tell the model to do.

In an AI-native professional tool, the prompt — or more precisely, the set of prompts that define what the tool extracts, how it structures its output, what it flags, what it ignores, and how it communicates results — is the actual product. The infrastructure is just the delivery mechanism. Two tools built on identical infrastructure with different prompts will produce completely different results, and the gap between them will be immediately obvious to any professional who uses both.

This distinction matters for how you think about building. Most engineering effort in AI tool development gets directed at infrastructure: the server, the integrations, the API connections, the deployment pipeline. This is sensible in the short term because infrastructure problems are concrete and tractable. But it misallocates effort relative to where the durable value is created. Infrastructure is replicable. A well-engineered set of domain-specific prompts — developed through sustained attention to how professionals actually work, what they look for, and what they need to flag — is not.

The prompts encode the domain knowledge. They determine whether the tool extracts the right fields from a lease, whether it flags the provisions that matter, whether the output hierarchy matches the professional’s review process, whether the language used fits the professional context. These decisions require knowing the domain. They can’t be derived from documentation. They improve through iteration against real professional feedback. The first version is almost always wrong in ways that are invisible until a domain expert sees the output and immediately spots what’s missing.

This is also why building professional AI tools from within a domain is a genuine advantage. When the builder has accumulated the relevant domain knowledge — not through literature review, but through sustained, specific, detailed study of how professionals work — the prompt engineering reflects that knowledge. It produces outputs that fit the professional’s actual workflow rather than a developer’s model of what that workflow looks like. That fit is the product.

The infrastructure took an afternoon to build. The prompts took months.

+++