The Leverage Hierarchy of Agent Engineering

This is an operator framework, not financial advice.

 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 full ranking is below for operators who want the granular version. Read from the bottom up. Reference table. Skim now, return to it when applying the framework.

Rank	Meadows’ phrasing	Agent-engineering equivalent
	Bottom band (low leverage)
12	Constants, parameters, numbers	Prompt tokens, temperature, top-p, max-tokens, model selection
11	Sizes of buffers and stabilising stocks relative to flows	Context window size, embedding dimension, retrieval-k
10	Structure of material stocks and flows	Tool catalogue, MCP topology, sub-agent inventory
9	Lengths of delays relative to rate of system change	Async response timing, retry intervals, polling cadence
	Middle band (mid leverage)
8	Strength of negative feedback loops relative to impacts corrected	Validators, evaluators, monitors, output gates, regression tests
7	Gain around driving positive feedback loops	Reinforcement loops (RL, online fine-tuning) and operator-improvement cycles (skill discovery, agent self-improvement passes)
	Top band (high leverage)
6	Structure of information flows (who has access to what, when)	Context architecture: what the agent sees, sourced from which layer
5	Rules of the system (incentives, punishments, constraints)	Tool permissions, action gates, system prompts as constraints
4	Power to add, change, evolve, or self-organise system structure	Skill discovery, sub-agent spawning, dynamic delegation
3	Goals of the system	Objective function, intent specification, success criterion
2	Mindset or paradigm from which goals, structure, rules arise	The mental model of what an agent IS (a model that calls tools, or a structured pipeline that uses a model). Implementation architecture follows from the paradigm
1	Power to transcend paradigms	Questioning whether “agent” is the right primitive at all (e.g. harness-only systems with no LLM in the control flow)

A note on the top of 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.

The OpenAI case study

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.

This publication tracks the layer of agent-engineering leverage most teams have not noticed they need to climb to. [Subscribe here.]

Why the bottom of the stack wins anyway

Higher leverage implies more resistance. Meadows’ own diagnosis of why the ranking exists at all.

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.

The audit

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?

Footnotes

1. Donella Meadows, Leverage Points: Places to Intervene in a System (1999-10-19). Archived by The Donella Meadows Project. https://donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/ ↩

2. OpenAI, Inside Our In-House Data Agent (2026-01-29). Authors: Bonnie Xu, Aravind Suresh, Emma Tang of the OpenAI Data Productivity team. The three lessons (Less is More / Guide the Goal, Not the Path / Meaning Lives in Code) and the six-layer context architecture (schema, annotations, code, institutional, memory, runtime) are direct quotes from the post. https://openai.com/index/inside-our-in-house-data-agent/ ↩

---