Stop Building Agents For Workflows The Tools Are Absorbing

The early instinct with agentic AI was to create a cast of characters.

Researcher agent. Planner agent. Reviewer agent. Legal agent. Writer agent. Each one gets a prompt, a tool list, a handoff rule, and a little routing layer around it.

That made sense when the model was just a text box.

But Codex, Claude Code, Cursor, and similar tools are not plain chat windows anymore. They are agent harnesses. They already know how to read files, edit files, call tools, manage context, run commands, use MCP servers, load instructions, and in some cases spawn subagents.

So the question changes.

The question is no longer, "How many agents should I build?"

The question is, "Which parts of this workflow are still mine to design?"

My answer: the durable layer is the environment. The file tree. The workflow definitions. The instructions. The tools. The test commands. The examples. The data boundaries. The permission model. The proof that the work is done.

The Wrong Bet

If Anthropic and OpenAI are baking more agentic behavior into Claude Code and Codex, then hand-rolling specialized agents for every repeatable task becomes a strange bet.

You are betting that your little routing layer will age better than the product teams whose entire job is improving routing, memory, tools, subagents, context management, and safety.

That does not mean you should never build agents.

It means you should stop building agents for things the platform is actively turning into primitives.

The public docs already show the direction. Codex supports layered AGENTS.md files. Codex skills are directories with SKILL.md, scripts, references, assets, and even agent definitions. Codex supports subagents for parallel specialized work, and MCP for connecting models to external tools and context.

Claude Code points the same way. It has CLAUDE.md memory, skills, commands, subagents, MCP, hooks, and project-scoped configuration. Even the leaked-prompt discussions around Claude Code point at the same pattern, but I would not build a public thesis on leaked internal text. The official surface is enough.

The providers are absorbing the harness.

Your job is to stop rebuilding the harness and start designing the workspace it operates in.

File Trees Keep Surviving

Software keeps changing its fashionable architecture language.

We had MVC. We had layered architecture. We had Clean Architecture. We had microservices. We had monorepos. We had infrastructure as code. We had design systems. We had data pipelines.

The names changed, but one thing kept coming back: boundaries encoded in files and folders.

The filesystem is not glamorous, but it is one of the most stable interfaces in computing. It gives humans and tools a shared map. It says: this is the domain, this is the adapter, this is the test, this is the fixture, this is the migration, this is the runbook.

Agentic workflows do not escape that.

If anything, they make file structure more important, because the agent needs a map before it can act intelligently.

The Workflow Is The Architecture

Take a content research workflow.

The agent version sounds like this:

Create a researcher agent.
Create a strategist agent.
Create a writer agent.
Create an editor agent.
Route between them.

The environment version looks like this:

workflows/content-research/
  README.md
  instructions.md
  sources/
  examples/
  output-format.md
  verify.md
  tools.md

Now Codex or Claude Code has somewhere to stand.

instructions.md explains the job.

sources/ stores raw material.

examples/ shows what good output looks like.

tools.md says which MCP servers, scripts, or APIs matter.

verify.md defines the finish line.

If the platform later ships a better research subagent, you do not throw the system away. You plug that capability into the workflow. If it ships a better summarization skill, the workflow uses the skill. If it ships a better memory layer, the workflow becomes easier to run.

That is the difference.

A fragile agent graph competes with provider updates.

A well-designed workflow tree benefits from provider updates.

Agent, Skill, Workflow, Or Script?

This is the decision rule I would use.

Use a script when the step is deterministic. Formatting, migrations, data transforms, validation, retries, status-code routing, and build steps should usually be code.

Use a skill when the step is a repeatable method that benefits from model judgment but does not need its own long-lived identity. Drafting a changelog, reviewing a diff, creating a test plan, summarizing research, or generating a release note can often be a skill.

Use a workflow folder when the work has multiple artifacts, examples, data inputs, and verification rules. This is where most business processes belong.

Use an agent when the work needs separate context, separate permissions, parallel execution, long-running ownership, or a specialized model/tool budget. A security reviewer with restricted tools can be an agent. A background research worker can be an agent. A product runtime that serves customers with traceable state can be an agent.

But "I do this task often" is not enough reason to create an agent.

Many agents are just skills wearing a costume.

The Practical Shift

The practical shift is simple:

Stop asking, "What agent should I make?"

Start asking, "What filesystem would make this workflow obvious?"

For a codebase, that may mean better AGENTS.md rules, package-level instructions, test fixtures, and verification scripts.

For a business workflow, it may mean a folder per process with inputs, templates, examples, decisions, and acceptance criteria.

For a content system, it may mean saved research, source notes, hook examples, draft formats, editorial rules, and publishing checklists.

For an internal AI tool, it may mean MCP config, tool permissions, logs, eval cases, and runbooks before a single custom agent class exists.

That is less exciting than drawing a multi-agent org chart.

It is also harder to obsolete.

What I Would Build Instead

If I were starting a new agentic workflow today, I would build this first:

workflow-name/
  README.md
  task.md
  context.md
  inputs/
  examples/
  tools.md
  verify.md
  outputs/

Then I would add one of four things only when the workflow proves it needs it:

• A script for deterministic work.
• A skill for reusable model-guided work.
• A scoped instruction file when one folder has special rules.
• A subagent when isolation or parallelism is actually useful.

That is the architecture I trust more than a pile of custom agent wrappers.

The agent layer is moving fast because the providers are still figuring out the best harness. Fine. Let them.

The workflow layer is yours.

Design that part well, and every future Codex update, Claude Code update, model release, MCP server, skill, or subagent has a better place to land.

Sources: OpenAI AGENTS.md guide, OpenAI Codex skills docs, OpenAI Codex subagents docs, OpenAI Codex MCP docs, Claude Code memory docs, Claude Code skills docs, and Claude Code subagents docs.