What AI agents actually do (and what makes them hard to build well)

Most people encounter AI as a question-answering tool. You type something, the model responds, the conversation ends. Agents are a different category entirely. They receive a goal, build a plan, call external tools, read the results, and repeat that cycle until the task is done or they run out of tries.

The observe-think-act loop

Every agent runs the same core cycle. It observes the current state of its environment (what it knows, what just happened, what tools are available), thinks through what to do next given its goal, and takes an action — usually a tool call. That loop repeats.

What makes this powerful is also what makes it failure-prone: the agent's decisions at step three feed directly into step one of the next loop. If the agent misreads a tool result, every subsequent action is built on that error. The trajectory — the full record of every observation and action the agent has taken — is how you diagnose where reasoning went wrong.

Tools are the agent's interface with reality

A model alone can't book a flight, check current stock prices, or read a file. Tools are the bridge between the model's reasoning and the outside world. In practice, a tool is a function the agent can call with specific parameters. The tool runs, returns a result (usually in JSON), and the agent reads that result as its next observation.

The design of those tools matters enormously. Vague tool descriptions produce vague tool calls. Clear descriptions, specific parameter names, and structured output formats are what let an agent use tools reliably across a chain of calls. Chaining is where things get interesting: the hotel search in a travel-booking example only works because the agent correctly extracted the arrival date from the flight search result and passed it to the next call.

Error recovery is a design decision

Agents encounter tool failures constantly: invalid dates, empty results, API timeouts. A well-designed agent treats an error message as new information and adjusts. A poorly designed one retries the same failed action until it hits a limit, or halts entirely.

Two things make error recovery work. First, the error messages your tools return need to be readable by the agent, not just by a developer. "Date '2025-02-30' is invalid" is actionable. "Error 400" is not. Second, retry limits are not optional. Set the limit, and log the failure so you can see what the agent was attempting when it gave up.

Agentic coding takes this further

Agentic coding applies the same loop to software development. The agent reads a codebase, proposes a change, runs tests, reads the test output as a new observation, and iterates until the tests pass or it determines the goal is unachievable.

The gains in speed are measurable: roughly 12% of real-world GitHub issues have been resolved autonomously by agents. But autonomy also amplifies failures. A hallucinated code change that passes a shallow test can cause a silent regression elsewhere. The same properties that make agents productive make oversight non-optional.

Why this changes how you write tasks

When you know how the loop works, you can write tasks differently. You give agents complete goals, not micro-instructions, because the agent's planning layer is what makes it useful. You write tool descriptions that would make sense to someone reading them for the first time, because the agent is always reading them for the first time. And you design for failure explicitly, because a system that only works when everything goes right is not a system you can rely on.

Take the course: https://app.outlier.ai/en/expert/course?id=691f74476df203fee129fb3b