A lot of AI agent workflows are becoming expensive for a very boring reason:
We keep giving the agent too much context and not enough direction.
The usual pattern looks like this:
Here is my whole repo.
Here are 12 tools.
Here are 9 docs.
Here is the bug.
Please figure it out.
Sometimes it works.
But it is also how you end up with huge token usage, messy tool calls, slow runs, and an agent that spends half the session rediscovering what a human already knows.
More context feels safer.
In practice, it often makes the workflow worse.
The problem is not context. The problem is unfiltered context.
AI agents do need context.
They need the right files, the right constraints, the right examples, and the right definition of done.
What they do not need is every possible thing that might be relevant.
That is where many workflows go wrong.
A small task becomes a giant investigation because the agent has no boundary.
For example, imagine asking an agent to update a pricing component.
Bad version:
Read the app and update the pricing page.
Better version:
Update the pricing card component.
Only inspect files under components/pricing and app/pricing.
Do not change billing logic.
Run the component test and TypeScript check.
Return a short summary plus changed files.
The second prompt is not just shorter.
It is a smaller workflow.
That is the part that matters.
Tools make this easier and harder
MCP and other tool protocols are useful because they give agents cleaner access to external systems.
That is a real improvement.
But tool access also creates a new problem:
The agent can now search more, read more, call more APIs, and collect more context than it actually needs.
A connected agent is powerful.
A connected agent with no workflow boundary is expensive.
This is why I think a lot of teams are asking the wrong question.
The question is not only:
What tools can my agent access?
The better question is:
What is the smallest reliable workflow this task needs?
That one question changes how you design the agent.
A workflow beats a giant prompt
When I say “workflow,” I mean a repeatable operating pattern:
- when to use it
- which files or tools are in scope
- which files or tools are out of scope
- what steps to follow
- what checks to run
- what output format to return
- what should trigger a human handoff
This is different from a one-off prompt.
A prompt is a request.
A workflow is a habit.
And agents need good habits more than they need another 2,000 words of instructions.
Example: debugging without reading the universe
Here is a simple debugging workflow I use mentally all the time.
Instead of telling the agent:
Debug this issue.
I want the agent to follow a narrow loop:
1. Reproduce the error.
2. Identify the smallest failing command or test.
3. Inspect only the files directly involved.
4. Make one focused change.
5. Re-run the failing check.
6. Stop if the fix requires product judgment.
That workflow does two useful things.
First, it keeps the agent from wandering through unrelated code.
Second, it creates a clear stopping point.
A lot of agent waste happens because there is no stopping point.
The agent keeps searching, summarizing, and patching because “done” was never defined.
Example: code review with a smaller surface area
The same idea applies to code review.
A vague agent review sounds like this:
Review this PR.
That can produce a long list of generic comments.
A smaller workflow is better:
Review only for:
- data loss risks
- auth or permission mistakes
- broken edge cases
- missing tests for changed behavior
Ignore style unless it affects correctness.
Return only high-confidence findings.
This turns the agent from a noisy reviewer into a useful filter.
It also saves attention.
The goal is not to make the agent say more.
The goal is to make the agent say fewer, better things.
This is where skills help
This is why I like packaging repeatable workflows as skills.
A skill can tell the agent:
For this kind of task, use this workflow.
Use these tools.
Avoid these traps.
Verify with these checks.
Return this output.
That is much more useful than repeatedly writing giant prompts.
For example, a media-processing skill could teach the agent the standard FFmpeg workflow.
A deployment skill could teach it the exact deploy and verification steps.
A code-review skill could teach it what kinds of issues matter and what kinds of comments to ignore.
A security skill could tell it when to stop and ask for human approval.
The skill is not magic.
It is just reusable judgment.
And reusable judgment is exactly what most agent setups are missing.
The smallest workflow test
Before giving an agent a task, I like to ask:
What is the smallest workflow that can finish this safely?
Then I reduce the task until the answer is clear.
That usually means:
- fewer files
- fewer tools
- fewer open-ended instructions
- more explicit checks
- a clearer definition of done
This sounds less impressive than “agent with full repo access and every tool connected.”
But it works better.
Small workflows are easier to test.
Small workflows are easier to repeat.
Small workflows are easier to trust.
My rule of thumb
If an agent keeps burning tokens, I do not immediately add a better model.
I ask:
- Is the task too broad?
- Did I give it too many tools?
- Did I define done?
- Did I tell it what not to inspect?
- Can this become a reusable skill?
Most of the time, the fix is not more intelligence.
It is less ambiguity.
Why this matters
AI agents are getting better fast.
But better models will not remove the need for workflow design.
If anything, stronger agents make workflow design more important because they can do more damage, spend more tokens, and move faster in the wrong direction.
The next layer of useful agent work is not just bigger context windows.
It is smaller, clearer, reusable workflows.
That is what I am collecting at Terminal Skills: practical examples of skills that give agents narrower, repeatable ways to do real work.
More context is not always the answer.
Sometimes the best thing you can give an AI agent is a smaller job.
AI-assisted. Human reviewed.
Top comments (0)