Reading 06 of 8

What's an Agent—and Why They're Hard

An agent wraps a model in a loop with tools, state, and stopping rules. The capability is real; reliability and safe access are system-design problems.

An agent is not a new species of model. It is a system around a model: receive a goal, choose an action, call a tool, inspect the result, update state, and continue or stop. The runtime manages that loop.

The model supplies proposals. The harness supplies files, browser control, shell commands, APIs, credentials, memory, approvals, and execution environments. Change those layers and the same model can move from a harmless chat to a system capable of deleting data or deploying software.

Agents are useful because many jobs are not one prompt long. Research requires finding, reading, comparing, and citing. Coding requires inspecting, editing, running, and debugging. The loop lets the system react to evidence instead of guessing the whole path in advance.

But errors compound. If each step is usually right rather than always right, a long chain creates many chances to choose a poor source, misread output, call the wrong tool, or stop too early. Gartner predicted in 2025 that more than 40% of agentic-AI projects would be canceled by the end of 2027, citing cost, unclear business value, and inadequate risk controls. That is a forecast, not an observed failure rate, but it captures the implementation problem. 1

The hard part is not making an agent take an action. It is making the whole sequence observable, bounded, and worth trusting.

Security becomes harder because instructions can arrive through untrusted data. A web page, email, issue, or document can contain text designed to redirect the model. Prompt injection mitigations help, but a model reading attacker-controlled content should not also hold unlimited credentials and authority.

Use layers of control: give tools the least privilege they need; keep secrets out of prompts; isolate execution; restrict network and filesystem access; require approval for consequential actions; validate tool arguments; log calls and outputs; and make rollback possible where the external system supports it.

Verification must match the task. A coding agent can run targeted tests and show a diff. A research agent can provide source links and quoted evidence. A customer-service agent can stage a reply for approval. Passing one check does not prove the whole task: tests may miss behavior, citations may not support the sentence, and a diff says nothing about an external API call.

Stopping matters too. An agent needs limits for time, tokens, retries, cost, and tool calls, plus a clear way to ask for help. “Continue until done” is unsafe when “done” is ambiguous.

The best early agent workflows are narrow, observable, and reviewable. Let the system gather evidence or prepare a change; let a person approve the irreversible step. Increase autonomy only after real evaluations show that the workflow earns it.

Evidence

Sources

  1. 1