Suggesting or acting?

A copilot proposes and the person decides. An agent decides and acts, reporting afterwards. The underlying models and tools can be identical; the difference is where the decision sits.

That difference is not a technical detail. It determines who is accountable for a bad application, and in a job search the consequences land entirely on the candidate.

It is really a spectrum rather than two categories, and the useful question is per action rather than per product. The same tool can propose a cover letter, ask before submitting it, and silently send a follow-up email — three different positions on the spectrum inside one workflow.

Copilots are better where judgement matters and quality is visible: writing, deciding what to emphasise, choosing whether a role is worth the effort. The user contributes information the system does not have, and the output is better for it.

Agents are better where the work is repetitive and the answer is known: filling the same fields on the fortieth portal, checking whether postings are still open, chasing follow-ups on schedule. Nobody wants to supervise that.

The dividing question that works in practice is whether a person would catch the error. If a user reviewing the output would reliably spot a mistake, a copilot adds real safety; if they would skim and approve it — as everyone does by the fortieth identical form — the review is theatre and you may as well automate honestly.

• Copilot — anything an employer reads, anything requiring taste
• Agent — repetitive mechanics, monitoring, scheduled chores
• Copilot — decisions with personal consequences
• Agent — reversible work with a known correct answer

Someone targeting a small number of specific roles wants a copilot: each application matters, and automation adds risk for little gain. Someone running a high-volume search in a competitive market gets more from an agent handling the mechanics.

Both are legitimate. The mistake is a product deciding for the user, or quietly moving from one to the other as the team adds automation.

The same person also moves between them over a single search. A candidate is a copilot user in week one, when six roles look interesting, and an agent user in week ten, when the market has not responded and the strategy has shifted to coverage — and a product that only supports one position loses them halfway.

Copilots do not save as much time as people hope. Reviewing a suggestion takes real attention, and for a long search the total remains large.

Agents produce output the candidate has not read. That is exactly what makes them useful and exactly what makes them risky, and no amount of quality work removes the fact that something went out in someone’s name unseen.

Copilots carry a second, quieter failure. Presented with a fluent draft, most people edit rather than reconsider, so the suggestion anchors the answer — and a copilot that consistently proposes the same competent, generic framing produces a hundred applications that all sound the same despite each being individually approved.

Once a system acts without asking, three things become mandatory that were optional before: a record of what it actually did, a way to stop it immediately, and a rule about what it will never do without permission.

The third is the one teams skip. "Never submit to an employer not on the approved list", "never claim a qualification not in the profile", "never send more than ten applications a day" are cheap to implement and they are what turns a bad afternoon into a contained one.

A visible log matters more than it seems, too. The difference between a user who trusts an agent and one who quietly stops using it is usually whether they could see what it did while they were asleep.

• A log detailed enough to reconstruct any single action
• A stop control that works in one click, not a support ticket
• Hard rules the system will not cross whatever it concludes
• A daily digest, so nothing accumulates unseen for a week

The design that holds up is a copilot for everything an employer sees, with agent automation for the mechanical parts around it. The candidate decides and writes; the system does the tedious work of getting it there.

Whatever mix you build, be explicit about it. A user who believes they are supervising every application and is not has been misled about the thing they care about most.

Explicit means visible at the moment it matters, not disclosed in settings. The place to say that something will be sent without further review is the screen where the user turns it on, in a sentence they will actually read.