The Chatbot is Dead. Long Live the Agent

Keep the headline in perspective

The original headline is a provocation, not evidence that chatbots have disappeared. A conversation can be the right interface for explaining a policy, exploring options, or preparing a draft. The practical change comes when software can choose steps and act in connected systems.

That shift matters because a helpful answer and a completed action have different failure modes. An inaccurate suggestion can be reviewed before use. An incorrect update to a customer record may already have affected the next employee, report, or automated process. Decide where that boundary sits before connecting tools.

Choose an architecture before choosing a label

Anthropic distinguishes predefined workflows from agents that dynamically direct their processes and tool use. Its guidance recommends starting with the simplest approach that works and adding complexity when the task warrants it. That is a useful architectural distinction, rather than a claim that every process needs an agent.

Source: Anthropic: Building effective agents →

Write a small operating agreement

Our suggested starting point is a one-page agreement between the process owner and the implementation team. Describe a single completed outcome and list the actions needed to reach it. Decide which actions can run automatically, which need review, and which remain unavailable.

For a hypothetical customer-service pilot, the system might gather relevant policy passages and prepare a case summary. Updating an address, issuing a refund, and sending a customer response would each require a separate decision about authority. A broad instruction to resolve the case should not silently settle all three.

• Outcome: what must be true before the system marks the job complete?
• Scope: which records and tools can this workflow access?
• Authority: which specific actions require a named approver?
• Uncertainty: what should happen when required evidence is missing?
• Recovery: who investigates an incorrect action, and what can be restored?

Enforce the agreement where actions occur

OWASP identifies excessive functionality, permissions, and autonomy as sources of excessive-agency risk. Its mitigations include narrower tools, limited privileges, and approval of high-impact actions. Those controls belong in the application and connected services, not only in an instruction the model is expected to remember.

Source: OWASP: LLM06:2025 Excessive Agency →

Test the handoff, not just the happy path

A useful pilot should show the operator what remains unresolved. Give it a request with two plausible customer records, an outdated policy, and a tool response that arrives after a timeout. Observe whether it asks for the missing decision or confidently continues.

For an uncertain write, check the destination before retrying. For a partial result, preserve completed work without calling the entire job finished. For an approval request, show the intended change clearly enough that the reviewer can catch a wrong account or amount. These are suggested acceptance tests, not claims about how every agent behaves.

Expand only after ownership is visible

Review the pilot with the people who inherit its mistakes. Track whether they can identify the affected record, understand the intended action, and restore a workable state. Count unresolved jobs and operator interventions alongside successful completions.

Choose the next permission based on a demonstrated need. If a fixed sequence handles the task reliably, keep it. If flexible planning helps, add that capability within a defined boundary. The valuable outcome is dependable work with a responsible owner, whatever the interface is called.