The Surface Area Problem.A practical framework for deciding where your applied AI product should show up next.

The surface area problem.

At the start of 2026, the distribution map for most applied AI products still looked familiar. You had the surfaces you owned, usually web, mobile, and perhaps chat. Then you had the places where your customers already worked or stored data, such as Salesforce, Snowflake, Slack, or an industry system of record.

That map has blown apart.

ChatGPT, Claude, Gemini, and Grok are becoming places where users discover and invoke products. Claude Code, Codex, Gemini CLI, OpenCode, and Grok Build are becoming places where software gets chosen and used. Work agents such as Claude Cowork and ChatGPT Work are creating another category for knowledge work.

The platform announcements make the direction clear. OpenAI now lets developers build apps that run inside ChatGPT. Google is surfacing apps directly in Gemini. Anthropic moved from chat to code to Cowork. SpaceXAI added connectors inside Grok and launched a coding agent. The next surface is surely already being built.

Everyone building applied AI, which increasingly means everyone building software, now has more possible distribution work than any team can responsibly maintain.

The job is not to be everywhere. The job is to decide where your product must feel native, where it only needs to be callable, where you should run a cheap experiment, and where you should do nothing yet.

First, map the new surface area.

A flat list of integrations hides the strategy. Different surfaces play different roles in growth, and each role creates a different relationship with the customer.

The same product can participate in all four. That does not mean it should. Each step away from an owned surface can add distribution while reducing control, attribution, brand visibility, and direct customer learning.

Start by naming the role you want a surface to play. Is it a demand generator? A place to complete the core job? A retention channel? A data source? A way for another agent to call your capability? If the answer is “all of the above,” the strategy is not yet specific enough.

Write a distribution thesis before an integration spec.

Teams often begin with platform capability: “ChatGPT supports apps now, so what should we build?” That is backwards. Begin with a user, a job, and a moment of intent.

If you cannot complete the sentence without using “users” or “AI assistant” as the audience, stop. If the surface can begin the job but cannot complete it or hand it off cleanly, name that constraint. If your unique advantage disappears when the host controls the interface, say that too.

The purpose of the thesis is not to predict the future. It is to make the bet falsifiable before the excitement of a new platform turns into permanent maintenance.

Score opportunity and burden separately.

A surface can have enormous reach and still be a bad investment. It can also have a small audience and be strategically essential. Score each candidate from one to five on the factors below, but do not collapse them into one magic number. The scorecard is there to expose disagreement, not to automate judgment.

Put the candidates on a simple opportunity-versus-burden map. A high-opportunity, low-burden surface is an easy adapter bet. High opportunity and high burden may justify a focused native investment. Low opportunity and low burden is an experiment at most. Low opportunity and high burden belongs on the watchlist.

One warning: “the platform has millions of users” is not user pull. Reach only matters if your target user has relevant intent, can discover your capability, and can complete a valuable job.

Choose an investment mode.

Every new surface should be assigned one of four modes. This prevents an experiment from quietly becoming a permanent product line.

Protocol support is not a fifth mode. MCP and other standards can reduce adapter cost, but they do not create demand, guarantee discovery, or make a generic experience feel native. Protocols buy portability. They do not buy product-market fit.

Architect for portability, then earn nativeness.

Distribution has become an architectural concern. If every new surface requires a fork of your product logic, context, permissions, and evaluation system, your roadmap will be consumed by channel maintenance.

A portable applied AI product separates five layers:

1. Core capability. The durable job your product performs, independent of where it is invoked.
2. Context. The customer data, history, instructions, and domain model required to perform that job well.
3. Trust. Identity, delegated permissions, policy, audit, revocation, and safe failure behavior.
4. Surface adapter. The contract that translates a host’s inputs, actions, and outputs into your core capability.
5. Evidence. Shared telemetry and evaluations that tell you whether the job succeeded across every surface.

Centralize the first, second, third, and fifth layers. Keep the fourth thin until the evidence justifies a native experience. This is how a new channel becomes an adapter instead of a new company inside your company.

Portability also protects strategy. Platforms will change ranking systems, tool contracts, economics, and access rules. You should be able to follow attention without handing any one host the only working copy of your product.

Measure the job, not the visit.

Traditional product analytics assume the user arrives, starts a session, moves through a funnel, and converts. Agent distribution breaks that assumption. The host may select your tool, invoke it in the background, summarize the answer, and never send the user to your interface.

Replace the page funnel with a job funnel:

Useful metrics include:

• Successful jobs per eligible invocation, not raw calls
• Repeat delegated use by customer and workflow
• Human corrections, overrides, and failed handoffs
• Incremental activated accounts from the surface
• Retention and expansion by first surface of use
• Cost to maintain the surface per successful retained workflow

Compare those results with your owned experience and with a holdout whenever possible. Otherwise, a new surface can appear to grow while merely redistributing usage you already had.

Run a surface portfolio, not a platform parade.

Put surface decisions into the operating cadence. Keep one portfolio that shows where you are investing, what you are learning, and what you have chosen not to build.

For every active surface, record:

• The user, job, and observable behavior in the distribution thesis
• The investment mode and why it is appropriate
• A single accountable owner across product, growth, and platform work
• The full cost, including trust, evaluation, support, and maintenance
• The decision date and the evidence required to deepen, adapt, or stop

Protect investment in the owned experience and the portable core. Make only a small number of native surface bets at once. Use adapters to cover high-fit channels where the standard contract is enough. Keep experiments capped. Maintain a visible watchlist so the latest launch does not reset the roadmap every week.

Stop or step back when:

• The surface produces calls but not completed, repeated jobs
• Most usage comes from customers who already use you elsewhere
• Permission or reliability failures outweigh the workflow value
• The host absorbs the differentiating capability
• Maintenance repeatedly displaces work on the portable core
• The original learning question has been answered

A stopped integration is not necessarily a failed investment. If it answers an important question before you scale the maintenance burden, it has done its job.

The bottom line.

The Cambrian explosion of AI surfaces is real. It is also an observation, not a strategy.

The winning applied AI companies will not be the ones with the longest integration pages. They will know which user, which job, and which moment each surface serves. They will keep their core capability, context, trust, and evidence portable. They will build natively where the workflow earns it, adapt where availability is enough, experiment to resolve uncertainty, and watch when the signal is weak.

Be easy to invoke. Be difficult to replace. Be disciplined about where you show up.