Shipping and specialties
Copilot vs agent vs automation
Positioning is a product choice. Assist, act with tools, or run in the background — each implies different UX and liability.
Once a job fits AI, you still have to choose a shape. Copilot, agent and automation are product positions, not model features. Over-promising "autonomous" is the fastest way to destroy trust when the model improvises.
The interaction patterns live in AI product UX. This page is the decision: what the user thinks will happen when they let go.
The big idea
| Shape | User expectation | You must nail |
|---|---|---|
| Copilot / assist | I stay in control; you speed me up | Latency, inline UX, easy edit |
| Agent | I give a goal; you use tools | Tool reliability, permissions, audit trail, stop conditions |
| Automation | No UI until exception | Precision, monitoring, dead-letter queues |
A copilot is a junior pair sitting next to you. An agent is a junior you send to the other room with a badge and a radio. Automation is a machine on the factory line with a big red stop. The analogy breaks when the "junior" can spend money or change production data — then permissions and stop conditions are the product.
Trade-off
Ship copilot when taste, liability or ambiguity is high — code merges, customer email, medical notes. Ship agents when outcomes are verifiable and the workflow is multi-step (run tests, file a form, gather three sources). Ship background automation only with strong precision and an exception path.
Many products mix shapes: chat to scope, copilot to edit the artifact, human approval before tools with side effects.
Walking through a support product
Drafting a reply is copilot: the agent stays on screen, the human edits, send is a click. Filing a refund is an agent step: tools, permissions, an audit trail, a stop if the amount exceeds a limit. Nightly ticket tagging is automation: no UI until a confidence exception lands in a queue.
Write the shape into the PRD. "Auto-send stays off until faithfulness ≥ X" is a positioning sentence as much as a quality bar. Model swaps do not change the contract you made with the user.
Design workflows so a better model is a config plus an eval re-run, not a rewrite. Keep artifacts (docs, tickets, code) as the source of truth; treat the model as a worker. Prefer architectures where retrieval, tools and permissions do the heavy lifting.
Common mistakes
- Calling a copilot an agent in marketing. Users will expect tools to run without them.
- Automation without an exception path. Precision below 100% needs a dead-letter queue a human can see.
- Hard-coding today's failure modes as permanent UX. Gate the agent behind quality bars; do not wait for a hypothetical future model.
Check yourself
Code review suggestions that a developer accepts or rejects — copilot, agent, or automation?
Copilot. The human stays in control and the cost of a bad suggestion is an ignored hunk.
A bot that files expense reports from an inbox with no UI. What must you nail?
Precision, monitoring and an exception path. That is automation.
Key takeaways
- Shape is a product choice: copilot, agent or automation.
- Copilot when liability is high; agents when outcomes are verifiable; automation only with precision and exceptions.
- Mix shapes in one product. Gate irreversible tools behind approval.
Further learning
Next, turn "good enough" into a number in evals as product specs.
Related
AI product strategy
What to build with AI, how to defend it, how to price it, and how evals become product requirements.
When AI fits
Pick jobs with high value, tolerable errors and a verifier. Skip demos that cannot be checked.
Designing AI product experiences
Interaction design for probabilistic systems: trust, control, failure states and human-in-the-loop.