Blog

Stop drawing the maze: the shift to intent-driven agents

Rule engines drown in edge cases because they try to enumerate every path through a high-entropy domain. The agent era replaces imperative steps with a declared destination: an intent, a measurable goal, and fences the model cannot cross. On the three tiers of autonomy, what each one costs, and why the hard limits must live outside the model.

ShareXLinkedInFacebookTelegramRedditEmailCopy linkMarkdown
Give the agent a goal, and good fences: an amber agent path wandering inside a dashed teal sandbox fence labeled timeout, token budget, read-only and no mutations, reaching a goal ring.

Classical automation is an attempt to describe business logic as a graph of conditions, and the graph never stops growing. For predictable domains this is exactly right: parsing valid JSON needs a parser, not a plan. But point the same approach at a high-entropy domain - incident triage, complex ticket routing, code generation - and the state space explodes. Every new edge case becomes another if-block, every if-block constrains the next one, and the system hardens into a rule engine that everyone depends on and nobody dares touch.

This year the working answer stopped being “draw a bigger graph.” The shift underway is from imperative steps to declared destinations: you stop telling the system how to move and start telling it where it must arrive, inside which walls.

Intent and goal: the two new primitives

An intent is not a longer system prompt. It is a contract: a declarative description of the desired end state, and it is what steers the model at the exact moment its instructions run out. A sloppy intent fails precisely there - at the first anomaly the agent either hallucinates a path or optimizes a metric you never meant to set.

A goal is the intent made observable: a measurable state, not an action. “Write to the customer” is an action, and it can be performed uselessly forever. “The customer confirmed the fix and the ticket stayed closed for 24 hours” is a state - the system either reached it or it did not, and both outcomes are checkable by code that is not the agent. This intent-to-goal decomposition is the core of Pawel Huryn’s Intent Engineering framework, published this June, and it is the cleanest formulation of the discipline so far.

Three tiers, priced honestly

Making everything an autonomous agent is an expensive mistake. Anthropic’s engineering guidance from last December says it plainly: find the simplest solution possible, and add agency only when the task demands it. Their taxonomy draws the line between workflows - LLMs and tools orchestrated through “predefined code paths” - and agents, which “dynamically direct their own processes.” Stretch it one notch down and you get the three tiers every architecture discussion now orbits:

Three tiers of autonomy: a script as a fixed chain of steps, a workflow as a fixed graph with the model deciding at one node, an agent as an amber path exploring inside a fenced sandbox

The three tiers. Determinism buys predictability, autonomy buys coverage of the unknown, and the bill grows to the right.

Script. Deterministic code, no model anywhere. The right tier for every task with zero variance - and that is more of your system than the agent era’s marketing admits.

Workflow. The pipeline is a fixed directed graph; the model sits at specific nodes - classify this, extract that, route there - and decides nothing about the shape of the graph itself. Most of the predictability of a script, a useful slice of the model’s judgment, moderate cost. This is where the majority of production “AI systems” honestly live.

Agent. The model plans, chooses tools, evaluates its own progress, loops. Expensive in tokens, expensive in latency, and the only tier that works when the path genuinely cannot be enumerated in advance. Uncertainty is not a defect of these tasks; it is their defining feature, and it is what you are paying to cover.

The failure mode is using tier three where tier one belongs - burning agent tokens on problems a regex solves, then calling the resulting bill “the cost of AI.”

Fences: the control plane

Delegating the path does not mean surrendering control. It means moving control from the route to the perimeter.

Hard constraints are enforced where the model cannot reach them: orchestrator timeouts, token and cost budgets checked before execution, read-only credentials, mutating APIs absent from the tool list entirely. The agent does not experience these as rules to follow; it experiences them as physics.

Soft constraints live in the prompt: preferred tone, suggested search order, heuristics. The agent may bend them under goal pressure - and a good agent sometimes should. That is not a bug; it is the definition of the boundary between the two kinds.

The design rule follows directly, and it is one this blog has paid for in case studies: anything that must hold, holds outside the model. The system prompt is a suggestion - we watched five companies learn that in production. A fence inside the model’s own context is a fence the model can talk itself over. A fence in the orchestrator is not.

What the job becomes

The engineering deliverable shifts. Less control flow, more contracts: formulate the intent, define the goal as a checkable state, engineer the fences, and validate at checkpoints that code - not the model - gets to grade. The routine in between belongs to the agent, because the routine in between is exactly the part that never survived contact with reality anyway.

The counterweight is cost discipline. Agents are the luxury tier: spend them on entropy, keep scripts on everything deterministic, and let the workflow tier carry the middle. The teams doing this well are not the ones with the most agents; they are the ones with the sharpest line between the tiers.

A script encodes what you know. An agent explores what you do not. The architecture question is no longer “what are the steps” - it is “where does knowledge end,” and putting the fence exactly there.

Reading

Integrate with one key across every product direction.

Get API keyDocsFamily