Dear AI Chat: Stop Making Us Choose Between Chat and Work
The user should state the outcome once. Chat should decide when to answer, when to start an agent, how much model to use, and when to ask for help.
Dear OpenAI, Anthropic, Google, Microsoft, Perplexity, xAI, Cursor, Notion, and everyone else building an AI chat box: please steal this idea.
Stop asking people to choose between chat and work. Stop asking them to choose a model before the system even understands what they want. Let chat supervise the work.
I am saying this because we built the interface inside Polyform for data analysis, and the feedback surprised us. People liked it enough that they kept asking whether they could use it as their normal AI interface instead of the general chat products they already had.
The part they liked was not a smarter model. Underneath, our Deep Work agents use Codex or Claude Code. The part they liked was that they never had to decide when to leave the conversation and become an agent operator.
The toggle is the product handing its routing problem to the user
OpenAI now describes Chat as the place for fast conversational help and everyday questions, while Work is for longer, multi-step work and finished deliverables. Its current instructions tell people to choose between them. OpenAI, Anthropic, and Google also expose model selection in their chat products.
Those distinctions are real. They are useful to an expert who wants control. But they are a terrible first question for an everyday user.
The user does not arrive thinking, “This is a medium-reasoning task that should run in an agentic computer.” The user arrives thinking, “Compare these three options and make me a recommendation,” or “Fix this report,” or “Help me understand what changed.”
Before the request is understood, the interface asks the person to predict the required system:
The user routes the system
Choose Chat or Work. Choose a model. Choose a reasoning level. Then explain the outcome.
The system routes the work
Explain the outcome once. Chat decides what it can answer, what needs work, and what needs judgment.
That first version turns every new request into a small gamble. If you choose Chat, will it stop at a nice answer when you needed a finished artifact? If you choose Work, will a simple question become a slow, sprawling project? If you choose the fast model, will it miss the hard part? If you choose the biggest model, did you just spend more time and money than the job deserved?
Most people solve this by forming a habit. They always choose Chat. Or they always choose Work. Or they always choose the strongest model. None of those is the right answer for every request.
Chat and work should remain different systems
I am not arguing that chat and agentic work are the same thing.
Chat is good at conversation. It is quick, friendly, interruptible, and close to the user's intent. It can ask a question, do a bounded lookup, explain something, or help shape the request.
Work is different. A coding agent can operate a computer, inspect files, use tools, write and run code, create documents, change systems, validate outputs, and keep going for a long time. That power comes with more latency, more cost, more state, and more ways to drift.
The mistake is not building two systems. The mistake is making the person pick which system should hear the request.
Make chat the supervisor
Anthropic has already described the core architecture. In its guide to building effective agents, it calls one version the orchestrator-workers pattern: a central model breaks down a task, delegates work, and synthesizes the results. Anthropic used a related lead-agent and subagent structure in its multi-agent research system.
I think this pattern should become the default user interface, not only an architecture diagram for agent builders.
In Polyform, the person talks to Poly. Poly can answer a bounded question, retrieve relevant permitted context, or decide the request needs substantial execution. When it does, Poly starts Deep Work in a dedicated computer environment using Codex or Claude Code. The person does not have to operate the terminal, choose a repository tool, or manage an agent session.
Poly can start more than one Deep Work task when the job has independent parts. It can inspect their progress, send a follow-up to one exact task, pull the result back into the conversation, and preserve the relationship between the original request, the work, and the resulting artifact.
Add the goal, constraints, and any decision that must remain with you.
Handle the bounded question or start the right Deep Work task.
Investigate, use tools, create the artifact, and validate the work.
Inspect the last N meaningful messages from the exact task in order.
Follow up from confirmed chat context or carry verified objects into separate work.
Return the useful state, one real decision, or the finished result.
The loop repeats around the worker. The user remains in one conversation instead of becoming the message bus.
The important part is steps four and five. Poly can retrieve a bounded window of the last N meaningful messages from one exact Deep Work task, in chronological order. It can turn that slice into a clean update: what changed, what is blocked, what evidence exists, and what happens next. The user gets the state of the work, not a transcript of the work.
Suppose you say, “Reconcile last quarter, use our existing channel definitions, and do not change the source tables.” Deep Work later asks which definitions to use or whether it may alter a source. If the existing Ask Poly conversation already answers that question and authorizes the follow-up, Poly can send the confirmed constraint back to that exact worker. You do not have to repeat yourself. If the worker needs a new business decision, Poly asks you one clean question.
Separate work needs a more deliberate bridge. Poly can inspect the relevant prior Deep Work and carry the verified product objects the new task needs. It does not have to dump every old log into every new worker. That is how context should move across Deep Work: selectively, through the supervisor, with the task boundaries still visible.
This is where the usability improvement becomes much bigger than removing a toggle.
The supervisor can keep the small context small
A long-running worker accumulates implementation details: files, commands, source records, failed attempts, plans, tool output, and validation evidence. That context is necessary for the worker. It is not the conversation the user wants to live in.
The supervisor can keep a smaller record of the things that matter to the person: the goal, constraints, decisions, known preferences, accepted definitions, open questions, and finished results. The worker gets the details it needs. The user gets continuity.
That separation creates a useful behavior. A worker may ask a question whose answer already exists in the conversation: keep the source tables unchanged, use the existing board format, do not contact anyone, compare against last quarter. The supervisor does not need to bounce every one of those questions back to the user. It can answer from confirmed context and let the worker continue.
When the worker is genuinely blocked on a new decision, the supervisor can ask one clean question instead of forwarding a wall of logs.
- 01User
Goal, constraints, judgment, and approval.
- 02Supervisor
Intent, routing, context, progress, redirection, and synthesis.
- 03Deep Work
Files, tools, code, investigation, execution, and validation evidence.
Do not make the user carry the worker's entire context just to remain in control.
The supervisor should choose effort and escalate
Model choice belongs in the same layer.
A quick lookup should not automatically receive the most expensive reasoning and a full computer. A consequential multi-system change should not quietly run on the smallest model because the user forgot to open a picker. The system has more information about its models, tools, cost, latency, permissions, and task history than the user does.
So let the supervisor choose an initial work level. Let it inspect what comes back. If the worker is stuck, off track, or underpowered, let the supervisor clarify the instruction, raise the effort, continue the exact task, or start a better-scoped replacement. If three approaches are genuinely useful, let it run three bounded workers and compare their evidence.
This does not mean removing control. Experts should be able to pin a model, force Chat, force Work, cap spend, inspect logs, stop a task, or require approval. Those are good overrides.
They are not a good welcome screen.
The conversation can continue while the work runs
Once chat supervises durable work, the interface no longer has to hold the user hostage.
In Polyform, a person can ask Poly to email the next result. If Deep Work is still running, the system waits for its next completed result or question and sends that. The person can reply to the email and continue the same Ask Poly conversation.
The deeper idea is not email. It is that the supervisor owns the open loop. The user should be able to leave, come back, ask for a summary, change direction, or answer a real decision without watching every command scroll past.
Please steal this idea
I genuinely mean it.
OpenAI, Anthropic, Google, Microsoft, Perplexity, xAI, Cursor, Notion: build the expert controls. Keep the modes. Keep the model picker. Keep the raw logs. Just stop making those things the first decision every person has to make.
Give the user one friendly conversation. Let that conversation understand the goal, do the quick work, start the deep work, choose the effort, coordinate several workers, carry confirmed context between them, interrupt bad work, and return the result.
The best AI interface will not make us choose between chat and an agent.
It will be chat that knows when to become the supervisor of agents.
References and further reading
- OpenAI: ChatGPT Work and Codex
- OpenAI: ChatGPT release notes on model selection
- Anthropic: changing the model in Claude
- Google: choosing a model in Gemini Apps
- Anthropic: Building effective agents
- Anthropic: How we built our multi-agent research system
- How Poly supervises durable execution in Polyform
- How maintained business context supports the work