02 / Action

Intelligent agents need boundaries.

Agents combine a model with tools, memory and a goal. That makes them useful—and operationally different from chat.

An agent is a workflow with judgment inside

A chatbot returns language. An agent can inspect a ticket, search a knowledge base, query an account system, draft a response and create a follow-up task. The language model selects or sequences actions; software tools do the work. This is powerful for processes that contain variation but still have clear objectives and accessible systems.

Useful early examples include sales research, service-ticket triage, invoice exception investigation, security questionnaire drafting and internal knowledge assistance. They have bounded inputs, observable outputs and people who can review edge cases. “Run the department” is not an agent use case; it is an untestable ambition.

Design the action perimeter first

Classify every tool by consequence. Read-only tools can search CRM records, retrieve policies or inspect order status. Draft tools can prepare emails, reports and proposed updates. Write tools create records or change fields. High-consequence tools issue refunds, alter permissions, sign contracts or move money. Start agents at read-only and draft levels, then add narrowly scoped write authority after measured performance.

Tool descriptions must be precise. Instead of “update customer,” expose a function such as set_shipping_address with required fields, validation and an audit record. Validate arguments server-side; never trust a model to enforce business rules. Use short-lived credentials and give each agent its own identity rather than sharing a human administrator account.

Where agents succeed and fail

  • Strong fit: repeated knowledge work with a clear finish state, reliable tools and measurable quality.
  • Weak fit: tasks requiring tacit political judgment, unstable policies or unstructured permissions.
  • Risk signal: a process where nobody can define what “correct” looks like.

Agent failures are often not hallucinations. They are poor tool selection, stale retrieval, infinite loops, missing permission checks or optimistic assumptions about incomplete data. A robust system limits the number of steps, sets a cost budget, times out cleanly and escalates when confidence or evidence is insufficient.

Supervision is a product feature

Human-in-the-loop does not mean a person rubber-stamps every action. Design review where it has value: approval before external communication, approval above a refund threshold, or spot checks for low-risk classifications. Show reviewers the evidence, proposed action and policy rule—not a vague claim that the agent is confident.

Maintain an event trail for each run: user request, retrieved sources, tool calls, arguments, outputs, approval state and final outcome. This enables incident investigation and continuous evaluation. It also helps teams spot process defects that existed before AI arrived.

Measure outcome, not conversation quality

Track completion rate, escalation rate, correction rate, average handle time, cost per completed task and harm events. Compare the agent against the existing baseline, including human rework. A low escalation rate is not automatically good: it may mean the agent is acting when it should ask for help.

Start with one process, one team and one accountable business owner. Run in shadow mode before enabling action. Then increase scope only when monitoring shows reliable benefit. The most valuable agents feel less like autonomous robots and more like well-designed colleagues: quick, documented, constrained and easy to correct.