AI agents are supposed to save humans from clicking through repetitive workflows. Yet many agent systems quietly recreate the same problem one level higher: the model itself becomes the person clicking every button.

The agent decides which tool to use. Then it decides which file operation to use. Then it decides whether to patch or overwrite. Then it decides how to deploy. Then it decides how to verify. If the sequence is already known, none of those choices are intelligence. They are orchestration overhead.

The model should reason where the world is uncertain. Code should own the parts we already know.

When a workflow has a proven path, asking the model to rediscover that path on every run adds latency, cost, and avoidable failure surface.

Agents and workflows are not the same thing

This distinction is already visible in mainstream agent architecture. Anthropic separates agentic systems into workflows, where tools and models follow predefined code paths, and agents, where the model dynamically controls its own process. Their guidance is explicit that workflows are useful when predictability and consistency matter, while dynamic agents are valuable when flexibility is actually required.

OpenAI's current Agents SDK documentation describes the same architectural split: orchestration can be left to the LLM, or it can be controlled in code. The documentation notes that code-driven orchestration can be more deterministic and predictable in speed, cost, and performance.

The mistake is not using agents. The mistake is treating every step inside an agent run as though it deserves fresh model judgment.

Tool choice has a hidden latency tax

Every model-controlled tool decision creates work. The model has to inspect the available capability surface, infer which action fits, format the call, wait for the result, interpret that result, and decide what comes next.

That loop is useful when the next step depends on what was just discovered. It is wasteful when the next step is already mechanically determined.

open-ended problem → model reasons → new evidence changes the next decision → model reasons again known workflow → compiler emits fixed primitive sequence → runtime executes → verification returns evidence

OpenAI's Programmatic Tool Calling documentation reflects this pressure toward collapsing related tool work into a more compact orchestration layer. A program can coordinate multiple calls, use loops and conditions, and process intermediate results in one execution environment rather than forcing every intermediate operation back through the conversational loop.

That is a useful direction, but there is an even stronger pattern for mature workflows: once a sequence is proven, the model should not have to generate that sequence again at all.

Keep the primitive set small

The obvious reaction is to create a custom tool for every workflow: publish article, replace asset, ship game build, update storefront, and hundreds more.

That solves one problem by creating another. Tool surfaces grow, names overlap, selection gets harder, and specialized buttons slowly recreate the same routing entropy they were meant to remove.

A cleaner architecture keeps a small universal instruction set and moves complexity into compilation.

owner intent → domain skill → workflow compiler → fixed primitives → deterministic runtime → verification

The primitives remain stable. A repository skill declares the known workflow. The compiler binds the genuine variables, validates that every step belongs to the approved primitive kernel, and emits the sequence. The runtime executes it.

The model is not selecting a special "publish article" tool. It is providing the part only the model can produce: the article.

We caught this in our own publishing system

The problem became obvious while publishing a Lensically Research article.

The first version of the workflow worked, but the model manually rediscovered mechanics that the system already knew. It resolved the repository, probed file mutation behavior, determined which release primitive was correct, and searched for the verification path. The writing was not the slow part. The orchestration was.

That was a design failure, not a model failure.

We kept the primitive kernel unchanged and moved the known sequence into a repository-owned workflow contract. The first improvement compiled the publication into five file writes followed by a release. But the model was still being asked to supply precomputed versions of the Research index, search index, sitemap, and RSS feed.

Those were not creative inputs either, so we removed them too.

The resulting contract asks the model for only five pieces of article intelligence:

  • slug
  • title
  • description
  • topic
  • article HTML

The server reads the current discovery surfaces, derives their updates, computes timestamps and reading time, writes the article plus all supporting files, runs the release, and verifies deployment. The model never decides which file primitive comes next.

The rule is not “use code instead of AI”

There is a false choice hiding in a lot of agent discussion: either build rigid automation or give the model autonomy.

The better architecture uses both, at different boundaries.

Use the model when the problem contains genuine ambiguity: research, synthesis, prioritization, interpretation, writing, debugging hypotheses, design judgment, or deciding among materially different strategies.

Use deterministic execution when the winning path is already known: exact file updates, schema transforms, deployment sequences, validation gates, canonical routing, identity resolution, and repeatable postconditions.

The model can still trigger the workflow. It simply does not need to impersonate the workflow engine.

Memory makes the distinction more important

Persistent memory is useful because future runs should require less exploration. OpenAI's agent-memory documentation explicitly describes reducing future agent cost, user cost, and context cost by preserving lessons from prior runs.

But memory alone is not enough. If a system remembers the winning workflow and still asks the model to manually choose every step next time, it has preserved knowledge without operationalizing it.

A learned workflow should become cheaper to execute, not merely easier to remember.

Persistence reaches its full value when proven knowledge changes the execution surface itself.

This is where AI systems start to compound

A useful failure should remove a future decision. A successful workflow should become a reusable plan. A stable plan should compile into a small set of tested primitives. And a model arriving six months later should inherit that machinery without needing to rediscover why it exists.

This is the operational version of the argument we made in AI Memory and Context Engineering: How a Frozen Model Gets Better Without Retraining. Persistent state can make the same model more capable over time. Workflow compilation pushes that idea one step further: accumulated knowledge can also make the same model faster.

The goal is not fewer decisions. It is fewer fake decisions.

Agents need freedom when the environment is uncertain. That is where model intelligence earns its cost.

But when every successful run teaches the system a path that never changes, continuing to ask the model to choose that path is artificial autonomy. It is latency disguised as intelligence.

The architecture we want is simple:

reason about what is unknown compile what is known verify what actually happened persist what should never need rediscovery

That does not make the agent less capable. It gives the agent more of its time back for the parts that actually require a brain.

Stop making the model press every button.

Lensically Research documents the execution systems, failures, and reusable architecture we discover while building AI-operated software.

Explore Research