I Don't Want Your AI Copilot

If your AI feature needs the user to manually assemble all the context that your product already has, the product failed before the AI did.

The CRM already knows who I am. It knows which account I'm looking at, the last five emails, the deal stage, the open tasks, the fact that this lead went quiet three weeks ago, and that the company raised a Series A yesterday.

And still, in the corner of the screen, there's a helpful little panel asking me to type a prompt: "Ask me anything about this account."

I don't want to ask you anything about this account. You are the account. You have the data, the history, the buttons. You know what I'm looking at. Making me narrate my own screen back to a chatbot is making me do the product's job twice.

I've spent the last year putting LLMs into real workflows: documentation products, outbound systems, SaaS MVPs where the model is one judgment step among many. The pattern I keep seeing elsewhere is almost the opposite. Take an existing product, add a chat panel, connect an LLM, call it a copilot.

Sometimes that's exactly the right product. Often it's the wrong default.

The chat box became the AI product

"Add a copilot" became the default way to ship AI because it's easy to demo and difficult to argue with in a roadmap meeting. A chat interface is visible, flexible, and forgiving. Most importantly, it lets you postpone a difficult product decision: you don't have to decide what the product should actually do, because the user will ask.

Instead of ranking leads, let the user ask which leads matter. Instead of surfacing the next action, let them prompt for one. Instead of deciding where AI is useful, put a chatbot on the page and wait for someone to type. That is the trap: a chat box can turn product ambiguity into a feature.

I'm not against conversational interfaces. I'm against treating conversation as the only respectable way to ship intelligence.

Software used to earn its keep by knowing things so the user didn't have to restate them. Somewhere along the way, "AI-powered" started to mean: please explain yourself to the machine again.

Your product already knows more than the chatbot

Before anyone types a word, a typical SaaS product already knows a huge amount of context. It knows:

• who the user is
• what they are allowed to do
• which record is open
• what data is on the page
• what they did previously
• which workflow state the object is in
• which actions are available
• which business rules constrain the next step

A standalone chatbot doesn't have that context unless you assemble it, or worse, unless you make the user assemble it in natural language. The product owns structured reality. The chat panel often pretends it is starting from zero.

Picture the bad CRM copilot:

User: Which of these leads should I contact first and why?

Copilot: Based on the information provided...

The user just asked the product to interpret data the product already owns.

Now picture the same product without the confession booth. The CRM notices that the user is looking at a stale segment: three accounts raised funding, one has a new hiring signal, another replied two months ago but never received a follow-up, and two are already in active sequences and shouldn't be touched.

So it surfaces:

3 leads deserve attention today, with reasons, confidence, and one-click actions: open, sequence, snooze, dismiss.

The model still did judgment work. The user still stayed in control. But nobody had to open a chat window and perform the product's job for it.

Same intelligence. Different product. One makes the user work for the model. The other makes the model work for the user.

Exploration vs. execution

This is the distinction I actually care about, and it isn't "copilots bad, embedded AI good." There are two fundamentally different reasons to use AI in a product: exploration and execution.

If I'm exploring, I don't know what I want yet. The destination is unclear, the information might be unfamiliar, and I'm trying to understand a problem rather than complete a known task. Give me chat. Natural language is a great interface when the work is figuring out what the work is.

But if I already know what I'm trying to accomplish, don't make me chat my way through it. The product should use the context it already has, surface judgment where judgment is needed, and let me approve or edit the result.

Most bad copilots I've encountered treat an execution problem like an exploration problem. The user isn't lost. They're already halfway through a workflow. Asking them to open a blank text box and restate the obvious isn't helpful. It's friction dressed up as AI.

The copilot is sometimes a UX escape hatch

Sometimes a team builds a chat interface because the interaction genuinely is open-ended. That's fine. Sometimes they build one because they haven't answered a harder question: what should the product actually do here?

Ranking, recommendations, next-action suggestions, workflow automation, contextual buttons: these are all product decisions. A chat box can postpone every one of them. It looks like progress because there's an AI surface, but underneath, the product still doesn't know what "help" means on that screen. So the user invents the missing product through prompts.

That's not always the motive. But if your AI roadmap is mostly "ask me anything" surfaces, it's worth asking whether you're shipping intelligence or outsourcing unfinished product design to the user.

What I actually want from AI

I want AI at the places where software reaches uncertainty.

Deterministic software is excellent at questions like:

• Which leads replied?
• Which API routes exist?
• Which candidates meet the hard requirements?
• Which invoices are overdue?

Those are queries, filters, joins, parsers, and rules. Don't spend tokens on them.

AI earns its keep on the adjacent questions:

• Which replies indicate genuine buying intent?
• How should this endpoint be explained to a developer?
• Which remaining candidate is the strongest match?
• Which overdue invoice looks most likely to become a churn problem?

The product owns the workflow. The model handles judgment. The UI presents something the user can accept, edit, or reject.

If the model is a component inside the workflow rather than the whole product, the UX conclusion follows: why are we still making the user talk directly to the component? Talking to the model should be an option, not the default tax for getting help.

I built a copilot too

There's an obvious objection here: I literally built an AI copilot into Peergrowth Pulse. Fair. I'm not arguing that copilots are bad. I'm arguing that the chat box cannot be the product.

Pulse has access to the context the conversation is actually about: campaign performance, spend, leads, attribution, historical data, and the rest of the workspace. If I ask it why CPL increased, I don't want a generic answer about the five things that can cause CPL to increase. I want it to reason over the data Pulse already has. The user shouldn't have to paste campaign data into a prompt and explain what happened. The product already knows.

That's the standard I care about. A copilot should be an interface into product intelligence, not a substitute for product intelligence. A chatbot with access to your database isn't automatically a smart product. The interesting part is what the product understands before the user says anything.

DocPilot made this obvious

When I built DocPilot, the wrong product would have been a documentation chatbot. Something like:

Paste your repository.

Ask me to document your API.

Tell me which folders matter.

Clarify which framework you're using.

That's a copilot fantasy of the same job. It puts the burden back on the user to assemble context the product can obtain itself.

The actual product is much simpler: connect the repository. The system already knows the job. Classification, extraction, and generation happen inside that workflow, and the user reviews the resulting documentation. They don't narrate the pipeline into existence every morning.

The AI is still highly visible. Docs appear, regenerate, and improve. But the user isn't role-playing as an orchestration layer. They're reviewing work the product decided to do because the product understood the assignment.

One waits to be summoned. The other shows up where the work already is.

The outbound system is the same idea

The automated recruiting outreach engine makes the same point from another direction. Nobody should have to open a chat and say:

Find me some companies that might be interested in this candidate, explain why, and draft outreach.

That's a product spec wearing a prompt costume.

The system can discover companies, enrich them, evaluate signals, rank matches, and prepare outreach because those steps are known. The model sits inside the ranking and drafting moments where judgment is actually required. The operator reviews outcomes, not prompt transcripts.

The AI isn't invisible. Scores, rationales, and drafts are explicit. What disappears is the fake requirement that a human must summon intelligence by explaining the business to a blank text field.

If the user is typing the workflow, you don't have an AI workflow. You have a chatbot with extra steps.

When chat actually makes sense

I don't want this to become an anti-chat argument. Chat is excellent when conversation is the work. It makes sense when:

• the destination is unclear
• the user is exploring unfamiliar information
• brainstorming matters more than execution
• natural language is substantially easier than any structured interface
• the user needs to interrogate something they don't fully understand

A coding agent in an unfamiliar repository is a fair example: the environment is open, the next action isn't always enumerable, and conversation and tool use are part of the interface. Research across messy sources is another. So is "help me think through this pricing page." If I genuinely don't know what I want yet, I want something I can talk to.

The distinction is conversation as the interface versus conversation bolted onto an interface that already knew the answer. If exploration is the product, give people a conversation. If execution is the product, stop making them chat their way through a workflow your software could own.

A blank chat box inside a dashboard that already knows exactly what the user is doing is often just the cheapest way to look AI-native without becoming AI-native.

The test I use

Before adding an AI copilot, I ask seven questions.

1. Does the user actually need natural language? Or could the UI offer this capability directly?
2. Does the product already have the context? If yes, don't make the user restate it.
3. Can the product infer when this is useful? If the moment is detectable, the feature should often appear without being summoned.
4. Is this exploration or execution? Exploration can justify chat. Execution usually wants a recommendation, draft, or action.
5. Would a recommendation or action beat a paragraph? A surprising number of "AI answers" are unfinished UI.
6. Does the AI need to be invoked manually? Manual invocation is fine for rare, open-ended work. It's a smell when it's used for a recurring workflow step the product already understands.
7. What does the user do with the answer?

That last one catches most fake copilots. If the honest answer is "then they copy the answer and do the thing themselves," you haven't integrated the AI into the product yet. You've generated text adjacent to it.

The output should usually become a ranked list, a suggested next step, a draft ready to send, a classification the workflow can branch on, or an action the user can approve. Prose is allowed. Prose as the entire product surface usually means the last mile is still missing.

This isn't a law. Mixed products exist: a documentation tool can generate docs automatically and offer chat over the finished documentation; a CRM can recommend today's leads and let a user ask an unusual question about one account. The mistake is starting with the chat panel and hoping the rest of the product design emerges from prompts.

The AI should know where it lives

Don't ask "where can we put AI?" Ask "where does the product encounter uncertainty?" That's where the model belongs.

Sometimes the best AI feature is a button. Sometimes it's a ranked recommendation, a background job, a generated draft waiting for approval, or a quiet classification nobody ever sees. And sometimes it should absolutely be a chat box, because conversation is the honest interface for the problem.

What it shouldn't be is a strategy. "We added a copilot" is not a product strategy. It's a UI pattern, useful when earned and embarrassing when it becomes the substitute for designing software that already understands what the user is trying to do.

I don't want my tools to interview me about my own data.

I want them to already know, and to get better at acting on it.

Related: Why Most AI Products Don't Need Agents · Schema-First LLM Systems · Two-Step LLM Pipelines · Scope You Kill on Purpose · DocPilot case study · Automated Recruiting Outreach