Agents vs. wrappers: a field guide

The word “agent” has been stretched to cover everything from a genuinely autonomous system to a text box with a clever prompt. The distinction isn’t pedantic — it determines what the thing can actually do for you.

A wrapper answers; an agent acts

A wrapper takes a question and returns text. Useful, sometimes, but it ends where the conversation ends. An agent takes a goal, breaks it into steps, calls tools, reads and writes to your systems, checks its own work, and produces an outcome — not just a reply.

If the “AI feature” can’t do anything beyond talk, it’s a wrapper. That’s fine, as long as you’re not paying for an agent and getting a chat box.

Tools are what make it real

An agent is only as capable as the things it’s allowed to touch. Wiring it into your stack — your data, your APIs, your internal tools — is most of the actual work, and it’s the part demos skip. The model is rarely the hard part. The integration is.

When a wrapper is the right call

Not everything needs an agent. If the job is genuinely “summarize this” or “draft that,” a wrapper is simpler, cheaper, and easier to reason about. Reaching for an autonomous system when a single prompt would do is its own kind of over-engineering.

The test

Ask one question: at the end, did something change in the world — a ticket closed, a record updated, an order routed — or did you just get words back? Words are a wrapper. Change is an agent. Decide which one you actually need before anyone starts building.