Agents are strong — should we give up on chat?

Recently I heard a pretty radical view:

stop using AI as a chat tool. Move to agentic tools like Codex, Claude Code and Cursor as soon as possible.

The reason: context is an asset.

If background, files and past decisions are scattered across different chats, you have to explain everything again every time you start work. What you built up before rarely makes it into the next task.

Agents, on the other hand, can read project files directly, call tools, modify content, run code, and keep pushing toward a goal.

That view correctly names chat’s real limits.

But jumping from there straight to “we should give up on chat” goes too far, I think.

First, to be clear: what do chat and agent actually mean?

These concepts have blurred together by now.

Chat can search, read files and call tools; agents often look like chat windows too.

So what’s being discussed here isn’t product names but two ways of working.

Chat: the person keeps deciding the next step through round after round of conversation.

AI mainly provides analysis, suggestions and content; the person keeps driving the process.

Agent / agentic tool or mode: once the person gives a goal, AI can break it into steps, operate the environment, use tools and carry out a stretch of the task continuously.

The real difference isn’t which is smarter.

It’s:

how often the person steps in during execution, and how much continuous freedom to act is handed to AI.

Why do more and more people want to leave chat behind?

Because a lot of work really is inefficient through conversation alone.

Say I want to change a real project.

The code, requirements docs and test results are all in the workspace already. But in chat, I often have to keep copying background, uploading files, explaining the current state, and then manually putting what AI gives me back into the project.

The real work happens in the project, but AI hears about it secondhand through a chat window.

The value of agentic tools is letting AI into the real working environment.

It can see the current files directly, make changes, run tests, and keep adjusting based on the results.

For code, data processing, bulk edits and document maintenance, the difference is very clear.

Keeping some tasks in chat really does make people act as couriers between systems.

But agents solve execution problems, not every problem

Agents are better at pushing a task forward continuously.

But not every job’s biggest bottleneck is execution.

Sometimes what I’m really stuck on is:

• What problem do I actually want to solve?
• How should I choose between two directions?
• Is the problem with the current approach poor execution, or a premise that doesn’t hold?
• Am I just unwilling to let go because I’ve already done so much?

None of these has a clear “next operation.”

What’s needed is questioning, comparing, redefining the problem, even doing nothing for a while.

Of course, these discussions can happen inside agent tools too.

So this isn’t a simple split of “chat for thinking, agents for execution.”

More precisely:

when a task still needs its goals and judgments changed often, the person should keep tighter control; only when the goal and acceptance criteria are fairly clear does it make more sense to let AI execute continuously.

The point isn’t which product you open.

It’s not prematurely packaging a problem that still needs judgment as a task that only needs execution.

Context is an asset, but it can also become a burden

“Context is an asset” makes sense.

Project files, past decisions and real data really are more reliable than describing things anew every time.

But only if they’re still accurate.

A real workspace may also contain:

• directions that have been abandoned;
• outdated requirements;
• temporary scripts and test files;
• AI-generated content that was never confirmed;
• contradictory instructions;
• lots of intermediate output that was only useful for one task.

I’ve felt this problem clearly using coding agents recently.

AI is very capable, and because of that it creates lots of process files: temporary scripts, logs, test results, drafts and intermediate output.

None of this is a mistake in itself.

But without rules, it gradually scatters across the workspace. In the end you may not be able to tell:

which files are official and which are just byproducts of the process;

which conclusions still hold and which were just one attempt.

Chat’s problem is that it easily forgets.

A workspace’s problem may be that it remembers too much, without telling what matters from what doesn’t.

So the key isn’t saving as much context as possible, but maintaining a trustworthy working state.

The more an agent can act, the higher the cost of verifying

When chat gives a wrong answer, the impact usually stays in the text.

When an agent misjudges, it may keep modifying files, running commands and writing data, carrying out many steps on a wrong premise.

That doesn’t mean you shouldn’t use agents.

It means that once a tool gains more freedom to act, the way you verify has to be upgraded too.

For example:

• can you view the diff of changes;
• do important operations need confirmation;
• do files have version history;
• can you recover when something goes wrong;
• does the final result have clear acceptance criteria.

AI can take on a lot of execution, and handle local judgments along the way.

But the task’s goal, the key trade-offs and the final acceptance can’t be outsourced by default just because the tools got stronger.

So when is an agent a better fit?

These days I mainly look at three questions.

First, does the task need to operate in a real environment?

If it involves multiple files, code, data or outside tools, an agent is usually better than shuttling information back and forth in chat.

If it’s just understanding a concept or discussing a choice, chat may be enough.

Second, are the goal and definition of done clear?

If the goal keeps changing, the person needs to step in and adjust more often.

If you can already say what to change, what to keep and what counts as done, it’s a better fit to let AI keep pushing ahead.

Third, can the result be verified and recovered?

The easier it is to check and roll back, the better it suits an agent.

If even the user can’t judge whether the result is right, more automatic execution won’t automatically reduce the risk.

Chat isn’t obsolete, and agents aren’t a more advanced status

AI really is moving from “answering questions” to “taking action toward a goal.”

That will change how a lot of people work.

But chat and agents aren’t necessarily two generations of product, one replacing the other.

They’re more like different modes of control:

sometimes you need round-by-round conversation to keep the judgment open;

sometimes the goal is already clear and you can let AI into the real environment to get the work done continuously;

and if a problem with the premise surfaces during execution, you need to stop and discuss again.

What really matters isn’t leaving chat behind as fast as possible.

It’s knowing whether the problem in front of you is missing stronger execution, or still missing a clear judgment.