DEV Community

Cover image for The Leverage Hierarchy of Agent Engineering
Harry Floyd
Harry Floyd

Posted on • Originally published at harryfloyd.substack.com

The Leverage Hierarchy of Agent Engineering

The agent kept choosing the wrong table. Six prompt rewrites later, nothing had changed. The bug was never in the prompt. The schema layer did not distinguish logged-out sessions from logged-in sessions, and the metadata never exposed which table was the right one. No amount of prompt tuning teaches an agent something the metadata layer does not surface.

Most agent-engineering work happens at the bottom of the stack: prompts, retrieval-k, model swaps, retry policies, context windows, tool additions. Each move is real, each compiles, each lands in the Friday demo. But the gains that survive three model upgrades come from somewhere else. The structure of information flow. The rules of action. The goal the system is being asked to optimise for. Teams optimise for the demo, and the high-leverage work goes undone.

This is a layer problem, and Donella Meadows had a name for it. In 1999 she published a ranking of twelve places to intervene in a system, from the weakest (#12) to the strongest (#1). Her diagnosis: most teams identify the right place to push and then push the wrong way. The ranking maps onto the agent stack.

The mapping lands in three bands.

Bottom band, low leverage (ranks #12-#9).

Prompts, model swaps, retrieval-k, retries, async timing.

Middle band, mid leverage (ranks #8-#7).

Validators, evaluators, feedback loops.

Top band, high leverage (ranks #6-#1).

Information-flow architecture, rules of action, goals, framework choice.

The twelve-rank table

A note on the table. Ranks #1 and #2 are conceptual horizons most teams will not touch in a given sprint. Rank #7 is rare in production agent systems today. The bound action lives in ranks #10 through #3.

A live worked example of teams making the move. OpenAI's Data Productivity team published an engineering post in January about the internal data agent serving 3,500 of their employees across 70,000 datasets. They named three lessons. Less is More. When they exposed the full tool catalogue the agent got worse, so they consolidated. Guide the Goal, Not the Path. Prescriptive prompting degraded the agent on varied queries, so they switched to high-level goal specification. Meaning Lives in Code. Schemas describe what data looks like, but the pipeline code that produces it captures intent, so they crawled the codebase with Codex and made the code itself a context layer.

The lessons look like engineering wisdom. Read against Meadows' ranking, they are three layer-shifts that most agent teams have not noticed they need to make.

Less is More is the shift from #12 to #10. The team had been treating the tool catalogue as a parameter to tune by exposure. They moved up to material-flow structure: which tools exist at all. They did not improve the agent's ability to disambiguate redundant tools. They removed the redundancy. A #10 intervention. The same move applied to the wrong-table problem from the opener: make only the right table visible to the agent. The selection ability is not the layer to fix.

Guide the Goal, Not the Path is the shift from #12 to #3. Prescriptive prompting is parameter tuning under a different name: encoding the agent's behaviour token by token. They moved up nine ranks. They stopped encoding the path, started encoding the destination, and trusted the model's reasoning to find the route. The gain came from a structurally different intervention layer.

Meaning Lives in Code is the shift from #11 to #6. The naive #11 fix to "the agent does not understand this dataset" is a larger context window or a higher retrieval-k. They did not pull more snippets. They added an entirely new source: pipeline code, crawled by Codex, surfacing intent that schemas cannot. The information-flow structure changed.

Three lessons. Three shifts. None of the three moves would have been findable from inside the #12 frame.

None of this is moral failing. Higher-rank work demands coordination the org chart does not yet support. Low-rank work is sometimes prerequisite; teams discover the schema is broken while doing prompt tuning, not before. The fix is not to skip the bottom ranks. It is to notice when the rank where the work is being done is not the rank where the bug lives, and then move. The work at #6 and #5 and #3 ages well. A thoughtful permission model survives three model upgrades. A thoughtful prompt does not.

Three questions to run on your last week of agent-engineering work.

What fraction of your hours went below rank #10? For most teams the honest answer is above 70 percent. The gravitational pull of the lower ranks is strong; the point of asking is to notice.

Which question at ranks #6 through #3 have you been avoiding because it has no fast win? There is usually exactly one. Naming it is half the work.

Which one rank up from where the team currently lives could you move to next sprint, made concrete enough to fit on a Friday demo? Pick that one. Do not apologise for the demo being smaller than the previous one.

The model is rarely the binding layer. The next serious gain lives one rank up from where your team works now.

What rank does your team operate at today, and which rank do you most need to climb to next?

Top comments (0)