AI Models, Workflows, and Agents: What Actually Changes

A practical distinction between models, deterministic workflows, and agents, including permission and evaluation boundaries.

· · 6 min read

AI Models, Workflows, and Agents: What Actually Changes

The word agent is now attached to almost every AI product. The useful distinction is not branding. A model generates an output. A workflow connects model calls and tools in a path chosen by the developer. An agent receives a goal and chooses the next step from intermediate results.

The agent does not have a magical new brain. The difference is the system around the model: tools, state, permissions, a loop, and a way to evaluate the result.

Three layers

A model can turn a support message into a draft reply. It does not automatically have access to an inbox or database.

A workflow makes the route explicit:

~text
input → classify → retrieve policy → draft → validate → output
~

An agent has more freedom:

~text
goal → plan → call tool → inspect result → choose next step → stop
~

That freedom helps when the number of steps is hard to predict. It is unnecessary when the process is already known.

Tools are the real risk boundary

A wrong chatbot answer wastes time. A wrong agent action can delete a file, send an email, or change a production record. Give each tool a narrow schema, least-privilege credentials, a timeout, a usage limit, and an audit trail. Do not give a shell when the agent only needs deployment status. Ask for human approval before writes, payments, and external messages.

Memory is stored state

Working context, checkpoints, preferences, and a knowledge base are different things. Each needs its own retention and access rules. Never place passwords or API keys in model memory. If an agent reads private documents, record which document informed an action.

When a workflow wins

Use a deterministic workflow when the order is known, auditability matters, latency must be predictable, or mistakes are expensive. Invoice validation and publishing pipelines usually belong here.

Use an agent when exploration and repeated tool use are part of the task and the result can be evaluated objectively. A repository debugging assistant is a reasonable candidate if it runs in a sandbox with tests.

Set maximum steps, time and token budgets, allowed tools, stop conditions, cancellation, and escalation. Treat web pages and documents as untrusted data, not instructions with system priority.

Start with one model call, add one read-only tool, make stable steps explicit, and add write actions last. Agent is not the goal; a bounded, explainable result is.

References

• NIST: Agent glossary
• Anthropic: Building effective agents
• Anthropic: Demystifying evals
• OWASP: Top 10 for LLM Applications