The gap between an agentic AI demo and an agentic AI system that ships is enormous, and the way to understand it is to look at the ones that made the crossing. This is a survey of agentic patterns that earn their keep in production, grouped by the shape of the problem they solve rather than by vendor — because the vendors change and the shapes do not.

If you have not read what makes a system agentic, the short version: an agent is given a goal and runs a loop of act, observe, act again, on its own, until it is done. Every example below is a variation on that loop with different tools and different guardrails.

Coding agents — the category that actually landed first

Software is the domain where agentic AI crossed from novelty to daily tool fastest, and the reason is instructive: code has a built-in oracle. The agent writes something, runs the tests or the compiler, reads the failure, and fixes it. The reflection loop closes automatically because the environment tells the truth.

  • Terminal coding agents — Claude Code, Aider, and their kin — live where the code does. Given a task, they read the relevant files, make edits across many of them, run the test suite, and iterate until it passes. The good ones keep the chain short and show you the diff before anything lands.
  • IDE agents — Cursor, Cline, and the assistant built into most editors now — do the same inside the editor, with the open file and the project as context.

What makes these work is not a cleverer model than the chatbots use. It is the oracle: an agent that can run the tests is an agent that can tell whether it succeeded, which is exactly the reflection capability that everything else struggles to fake.

The lesson generalises. If you want an agent to be reliable at a task, give it a way to check its own work that does not depend on the model's own judgement. A test suite, a validator, a second independent check — anything the agent cannot talk itself past. Tasks with a cheap correctness oracle are the ones where agents shine; tasks without one are where they confidently hand you plausible nonsense.

Research and synthesis agents

The second pattern that ships: point an agent at a question, let it search, read, and synthesise, and have it come back with an answer and its sources.

  • Deep-research agents — the "research" modes now built into the major assistants — run many searches, read across the results, follow leads, and assemble a cited report over several minutes. They are a genuine step up from a single search because they iterate: read one source, notice a gap, search again to fill it.
  • Grounded document assistants like NotebookLM invert the trust model — instead of searching the open web, they answer strictly from a corpus you supply, with citations back to your own sources. Narrower, and far more trustworthy for exactly that reason.

The failure mode here is confident fabrication when the sources do not actually support the answer, which is why the citation trail is not a nicety — it is the only way to catch it.

Computer-use and personal agents

The most ambitious pattern, and the least mature: an agent that operates a whole computer — clicking, typing, browsing, running commands — on your behalf.

  • Computer-use agents drive a browser or desktop by looking at the screen and issuing clicks and keystrokes. Impressive, slow, and brittle: a moved button breaks the plan, and the failure modes are hard to bound.
  • Local personal agents like OpenClaw run on your own hardware, connect to the messaging apps you already use, and carry out tasks — manage files, run commands, handle email — with memory across sessions.

This is the category where the security story stops being theoretical. An agent that can both browse the web and act on your machine is an agent that can be instructed by a web page. Prompt injection through a page the agent reads, an email it processes, or a document it opens is the live threat, and "the model usually ignores that" is not a control. Give these agents the narrowest capability set the task needs, and gate anything irreversible behind explicit approval.

Operational and back-office agents

Quieter than the headline categories, and often the ones producing actual return:

  • Support triage — an agent reads an incoming ticket, pulls the customer's history, drafts a reply grounded in the knowledge base, and either sends it (for the routine 40%) or routes it to a human with the context already assembled. The win is not full automation; it is the assembly.
  • Log and alert triage — an agent takes a firing alert, gathers the relevant metrics and recent changes, and posts a first-pass diagnosis to the channel before a human has opened their laptop. Read-only, low-risk, and genuinely useful at 3am.
  • Data pipeline agents — given a natural-language request, an agent writes the query, runs it against a read replica, checks the result is plausible, and returns it with the SQL it used. The read replica and the visible SQL are the guardrails.

Notice the shape these share: the agent does the tedious gathering and drafting, and a human — or a hard constraint like a read replica — owns the consequential action. That is not a limitation to be engineered away. It is why they work.

The through-line

Across every example that ships, three things are true. There is a cheap way for the agent to check its own work, or a human who checks it. The chain of autonomous steps is kept short. And anything irreversible is gated behind a control the agent cannot bypass.

The demos that go viral usually violate all three — a fully autonomous agent doing something dramatic and irreversible in one take. The systems that are still running six months later almost never do. When you evaluate an agentic product, or build one, that is the checklist: what is the oracle, how long is the chain, and what stands between the agent and the irreversible.