There are two ways to code for AI. The first is a workflow. You write the path, hardcoded. The AI is just a cog in the route you determined. The second is an agent. The agent decides the path.
Most people don’t realize the difference. They still write the old way. Hardcoded workflows. Even when they think they’re building agents.
And most AI coding tools do the same. People rely on these tools to write their code more than ever, but the tools are surprisingly bad at writing for agents. They’ll tell you it’s done. You check the code and the execution is still the old way. Hardcoded paths everywhere.
It’s the number one thing I check when I’m building an app that uses agents.
AI workflows vs AI agents
Workflows are for fixed jobs. Document classification. Sentiment analysis. Pulling data from invoices. The input is known, the output is known, and the AI does one specific thing inside a process you defined. You hardcode the logic. If the user says X, do this. If they say Y, do that. You predict every input and write the branch for it.
Agents are for open jobs. The input is messy. The user could want anything. The right next step depends on the last one. Coding assistants. Research tools. Any assistant that has to handle whatever you throw at it. You don’t hardcode the logic. You give the agent tools and skills. Tools are the primitive actions it can take. Skills are bundles of instructions and tool sequences for handling a workflow. The agent picks which to use.
The mental shift is this. Workflow thinking asks: what are all the things the user might do, and how do I handle each? Agent thinking asks: what capabilities does the agent need to handle whatever shows up?
Meta tag generation or auto labelling is a great example of this. A user creates a document in your app and you want to auto-generate tags for it.
As a workflow, you write a function. Take the content. Call the AI with a fixed prompt: “Generate five tags for this document.” Parse the response. Save the tags. Same path, every time.
Now say those tags exist across your app, and a user asks the agent: “What’s the due date for this deal?” The agent first calls a search tool, which searches tags across the docs for that deal. It loads the five closest documents based on those tags. It ingests that context. Then it responds.
There’s no fixed path. The agent decided when to search, what to load, how much to ingest, and when to answer. None of that was hardcoded.
Here’s the rule. If there’s only one path to the result, hardcode it. It’s simple and reliable.
Document in. AI reads it. Tags get assigned. Result uploaded. One path. Use a workflow.
If there’s more than one path to the result, use an agent. Users won’t ask things one way. They’ll ask:
“What was the deadline client Y mentioned for deal X?” “On the deal about the finance app for HSA, what’s the deadline?” “What are all the upcoming deadlines for deals in the last 30 days?”
Three different questions, three different paths. The agent figures out which one to take.
Tradeoffs
Workflows are great when you want to control the path. They’re predictable. They’re easy to manage. You optimize cost and latency by tweaking the model or the prompt. Same call, same shape, every time.
The limit is flexibility. The more cases you want one hardcoded path to cover, the more complex it gets. Eventually you’re writing prompts that try to handle every situation at once. Quality dips. Debugging gets harder. The thing you built for predictability becomes its own mess.
The agent is the flip side. Way more flexible. The model handles paths you didn’t write. But it’s expensive. Every tool call and skill call consumes tokens, sometimes four or five to complete one task. It’s slower for the same reason. Multiple round trips. Users feel it.
Agents also need infrastructure workflows don’t. Evals and observability stop being optional. They become necessary. They’re how you know what the agent is doing and how you catch it when it isn’t.
Because the agent mostly does the right thing. Mostly. Sometimes it picks the wrong tool. Sometimes it makes up an answer instead of searching. Sometimes it spins on the same step until you cut it off. Without observability, you don’t see any of that. Debugging means reading logs and inferring what the model was thinking.
Neither is the default. Workflows for fixed jobs, agents for open ones. Pick the one the job actually needs.
The shift
In a workflow, you define a function. Input goes in, output comes out, and the path between them is yours. You wrote it.
In an agent, you define capabilities. The tools it can use. The skills it can invoke. The goal it’s trying to reach. You don’t write the path. You define what’s possible.
That’s the paradigm shift. From writing paths to defining capabilities. From functions to environments.
If you’re still writing the path, you’re building a workflow. Not an agent.