When AI Operates the Software: What Replaces Feature Discovery

Product teams have spent years shipping features that few people find. Elena Verna argues that AI makes most of that work unnecessary, because people now state what they want and the software decides which features to use. The adoption problem does not disappear. It moves into three new places: whether the agent chooses the right capability, whether people can see what is possible, and whether they trust what was done. This article maps each one onto what is already built in CTI and the Document Substrate, and sets out what to build next.

The argument

In The end of feature discovery as we know it, Elena Verna, who works on growth at Lovable, describes the old loop: build a feature, then spend months on onboarding, navigation changes and nudges to get people to use it. Most never do. Products need more capability to grow, and simpler interfaces to reach mainstream users, and nav redesigns and personalisation never resolved the two.

Her point is that AI changes who operates the product. In her words, "We're changing who actually operates the software." A person states an outcome, and the AI picks the capability. When agents call a product through an API or MCP server, the person may never open it at all.

She then names what replaces feature discovery:

Trust. People have to trust what the software did without checking every step. That means showing what was decided and why, when a person should step in, and making actions reversible.
Use-case discovery. A prompt box gives none of the cues a menu did. People still need to learn what is possible.
Different measures. Engagement may fall while value rises. Growth comes from people handing over larger and more important work.
AI as the product. An AI feature added to an existing product is one more feature to discover.

At Lovable, she says, she barely thinks about feature adoption, except when the agent does not know a feature exists. That remark is where this article starts, because it is a problem that can be tested.

Three problems replace feature discovery

When the agent operates the software, a capability is used if the agent chooses it at the right moment, if the person knows to ask for it, and if the person trusts the result enough to ask again.

When AI operates the software: a person states the job, the machine finds what is possible, chooses the capability, runs it and shows the record, and a person reviews and signs. The three new problems map to the substrate wrappers: question archetypes, constraints and safety, and the grounding constraint

These three problems line up with the three wrappers of a substrate, the written record of a firm's expertise:

Question archetypes are the kinds of question that come up in the work, grouped by how they are answered. They are the use cases a person needs to see.
Constraints and safety are what the expert refuses, escalates or treats as out of scope. They are part of choosing the capability: knowing when not to use one is as important as knowing when to use it.
The grounding constraint is what every output is tied to. It is what a person checks before trusting the result.

Two systems are the worked examples here. CTI (Cycling Training Intelligence) is a cycling coaching product with a chat interface and an MCP server. The Document Substrate is the software that reads client documents for firms that produce signed work. Both were designed with the agent as the operator. Neither solves all three problems yet.

A capability the agent does not choose is not shipped

In CTI, a small model sorts each message into one of five intents before the main model answers. A rider asked: "List all hydro dams I have cycled past." CTI had a tool that searches the points of interest along a rider's routes. The router classified the request as off-topic, and the rider was refused.

The tool existed and worked. For that rider it had not been shipped. Feature adoption, in the old sense, would have meant a tooltip. Here it meant an eval: 29 cases that check the router sends a request to a usable intent, refuses what should be refused, and does not refuse what it can answer. The router prompt states the rule behind it: searching and finding nothing is recoverable; a refusal is not.

The fix exposed a second layer. The router eval passed while production still refused a request to list basilicas, because the safety instructions in the main prompt had their own scope rules. A second eval now checks that layer. A capability can be hidden at more than one point between the request and the tool, and each point needs a test.

The Document Substrate takes the same approach for its chat assistant:

A manifest instead of a menu. The model is given a short list of seven skills (find, compare, chase list, table, explain a finding, summarise, workpaper summary) and loads the full instructions for one only when it needs it.
A description generated from the code. A workflow manifest lists each document type, field, slot, rule and tolerance, with its purpose and the uses it must not be put to. It is generated from the same definitions the code runs, so it cannot drift from them.
A check on the choice. A skill-selection eval runs real requests through the production prompt and checks which skill the model loaded, exactly. Loading a skill during ordinary conversation counts as a failure.
A record of who chose. Each chat trace records whether the person asked for the skill directly or the model chose it.

A capability counts as adopted when the agent chooses it: write the description, list it in the manifest, route a real request, check the choice with a selection eval, record the choice, and turn each miss into a new case

What to build next.

Check the tool, not only the intent. CTI's evals check routing and the numbers in answers. No eval checks which of its chat tools the model calls once a request is routed. The Document Substrate's skill-selection eval is the pattern to copy.
Record the choice where it is reviewed. CTI's telemetry records each tool call, but the trace row an administrator reviews stores the intent, not the tools used. Without it, a missed capability can only be found by reading conversations.
Treat the description as part of the capability. A new tool is not finished until it has a description that says when to use it and when not to, and at least one eval case in the wording people actually use.

This is the adoption metric Verna's argument implies: for each capability, how often the agent chooses it when it should, and how often it chooses it when it should not.

A blank box does not show what is possible

Verna's second problem is that a prompt box gives no cues. Both systems start from a defined job rather than an empty box, and both stop short of showing people what they could ask.

The Document Substrate's main entry point is not the chat window. A person picks an engagement, such as rental property accounts, sole trader accounts or annual accounts, and the workflow states the documents it needs, the checks it runs and what it produces. The job is the use case. Chat is there for questions about the documents, and typing "/" lists the seven skills with a description of each.

CTI opens an empty chat to the history of earlier conversations, with "/" for a menu of commands such as a weekly review or a training plan. Its MCP server offers eight prompts, including a weekly review, a block review and a plan for the week, which appear as commands in the person's own AI client. There are no starter questions or follow-up suggestions in the interface. Session memory does keep the open questions from a conversation, but it uses them to steer the model, not to show the rider.

What to build next.

Write the question archetypes as starters. A substrate already lists the kinds of question that come up and how each is answered. Each archetype, worded the way people ask it and filled in from the person's own data, is a starter: "How did last week compare with the plan?" for a rider, "What is missing for this rental property?" for a preparer.
Offer the next step after each result. CTI already stores open questions; showing one or two of them after an answer turns memory into a suggestion the rider can see.
Use the same list for people and agents. The archetypes that become starters in the interface are the same ones that become MCP prompts, so a person in CTI and a person using CTI from another AI client see the same things they can ask.

Trust comes from checks, not explanations

Verna asks how to show what the AI decided, when a person should step in, and how to make actions reversible. For a firm that signs its work, the answer cannot be an explanation written by the model. It has to be a record the reviewer can check without asking the model again.

The Document Substrate is built around that record:

Every figure is traced to its page. A citation opens the page and highlights the text. A figure that cannot be found is marked and left for a person.
Checks run in code. Twenty-two document types have field definitions and sixteen have arithmetic checks. Same figures, same verdict.
Uncertain items come first. Each comes with a plain-language reason, in one queue.
Corrections are kept, not overwritten. A reviewer's correction is stored beside the model's reading, and it can be reverted. Accepting a finding can be undone.
Rule changes are tried first. A new rule starts as a warning and is run against past jobs before it is enforced.
The work stays DRAFT. A workpaper is stamped DRAFT until every slot is filled and every rule passes, and a person signs.

This is the principle the site calls doer to reviewer: the model reads and suggests, code checks and decides, a person signs.

CTI has some of the same pieces. Fitness figures are computed in code, not by the model. The model may link only to rides a tool returned. A change to a rider's FTP or heart rate thresholds is held until the rider confirms it. Two gaps remain: the label showing which tool is running disappears once the answer arrives, and edits to rides and points of interest have no undo.

What to build next.

Keep the trail after the answer. Show which tools were called and which rides or documents were read, collapsed under the answer. The trace already holds it.
Make every write reversible or confirmed. The confirm step CTI uses for FTP is the pattern; apply it, or an undo, to every tool that changes stored data.
Ask for review where the stakes are. Not every step needs a person. A change to a threshold that drives every later calculation does; renaming a ride does not.

Delegation grows on evidence

Verna's growth lever is getting people to hand over larger tasks, from one question to whole workflows. For signed work, each step up needs evidence that the previous step was right, and the evidence differs at each step.

The delegation ladder: answer a question, run a skill, run a workflow, apply results without a person, and be called by another agent, with the evidence needed before each step is handed over

The fourth step is the one that matters most. The Document Substrate applies a document classification without a person only when the classifier is confident, and holds the rest. That is delegation decided by a measured threshold, not by how comfortable anyone feels. The six stages for accounting staff describe the same move from the staff side: the system owner decides which results are applied automatically, on evidence.

Engagement is the wrong measure for this. A reviewer who spends less time in the queue because fewer items are uncertain is getting more value, not less. The measures that fit:

How often the agent chooses the right capability, from the selection evals and the record of who chose.
How often a reviewer accepts an item unchanged, by document type and field. The corrections and acceptances are already stored.
How far work gets without a person: the share of jobs that leave DRAFT on the first pass, and the share of classifications applied automatically.
Which step people hand over next: whether someone who used a skill goes on to run the workflow.

None of these is reported yet in either system. The records they need are kept.

When the agent is outside the product

Verna notes that people may never open the product at all, because their own agent calls it. CTI is already used this way. Its MCP server offers 18 tools, from searching rides to the coach itself, and a tool appears only if the rider granted the matching permission. Tools that change data need a separate permission, and access can be revoked.

The Orbital site has a small MCP server of its own. One of its tools, get_pricing_summary, exists only to say that fees are not published and where to ask. Without it, an agent asked about price would guess. Designing for an agent operator includes deciding what it should say when the answer is "no".

The Document Substrate has no agent-callable interface yet. The design sets one rule before any code is written: nothing that identifies a client crosses that boundary, in any field. The checks, the trace to the page and the DRAFT stamp have to hold when the request comes from another agent, because the reviewer signing the work will not see that agent's conversation.

AI is the product, if the expertise is in it

Verna's last point is that an AI feature added to an existing product creates one more feature to discover. The Document Substrate is built the other way: the workflow is the product, and the model reads documents and words letters inside it. The Document Substrate revisited says the most useful capability is not the chat window.

What makes the AI the product, rather than a wrapper on a model anyone can buy, is the expertise it applies: what a right answer looks like, which checks it must pass, and when to stop and ask a person. That is the substrate. When the agent operates the software, the substrate is also what tells the agent which capability to use, what to refuse, and what every answer is tied to.

Where to start

Three questions show how ready a product is for an agent to operate it.

Would the agent choose each capability? List the capabilities. For each, write three requests in the words people actually use and check which one the agent picks. A capability it never picks is not shipped.
Can a person see what to ask? Write down the question archetypes, the kinds of question your best people answer, and check that each one appears somewhere a person or their agent can see it.
Can a reviewer check the result without asking the model? Pick one output and trace each figure to its source. Anything that can only be checked by asking the model again needs a record.

Worked examples across six professions · The Document Substrate in detail · CTI's reinforcing evals loop · CTI's MCP server · Principles