The atmospheric development dictionary, terms for the AI agent system around your work

Atmospheric development

When you reach for it

When the thing you are building is not a product or a single agent but the standing system that carries work between the moments a human is involved. It is the right term when the design question is what your setup does while you are busy doing something else, and the wrong term when the question is how one agent handles one task.

Worked example

The site this dictionary sits on is the working example. The definition above, the layers architecture, the free files under /files/, and the campaign around them run on bounded owner attention with the system carrying the rest. A practice that needed more of its owner than the bounded block would be failing its own premise, which is why the campaign's own operation is treated as a receipt rather than a slogan.

Why it matters

Model capability got cheap and human decision bandwidth did not. Once that asymmetry is the design constraint, most setup decisions invert. You stop optimizing for what a model can do in one call and start optimizing for how little of the person a finished piece of work costs. Everything else in this dictionary follows from that one move. The market pays for output rather than for cost per output, so the input worth maximum optimization is the one that does not scale, which is your time. It also makes upgrades cheap. When a better model lands it plugs into the same system in seconds, through the provider's sanctioned access path, and the whole operation gets the upgrade automatically.

Limits

This is a practice, not an umbrella over multi-agent AI in general. Good work already sits under agent orchestration and agentic workflows and none of it is being renamed. On authorship: Aaron Browne-Moore named the practice in August 2026 and developed the framework behind it. Objective-driven agents have prior art going back years and no invention of them is claimed here.

Model capability is the honest constraint. Systems raise the floor of what your work looks like on an average day, and models raise the ceiling of what it can reach at its best. The practice amplifies model quality rather than substituting for it, so a cheaper model running the same system tends to act more independently and still hand back work that needs redoing, which spends the attention the practice exists to save. That is reported behavior, from one external practitioner who ran the published file unmodified and reported twice: more conscientious, and the output still took as long or longer to check and correct. Whatever capability class you run, reach it through the provider's sanctioned access paths.

Then the fair-weather objection, stated the way it was put in the first outside test. A system this autonomous is only as good as whatever keeps a model on the rails when it is working past its limits, and the file you can download today does not teach that part. The criticism is correct about the file and incomplete about the practice. What the file teaches is the posture. The rails are a separate layer: verification gates that have to pass before work counts as done, telemetry on false-done claims, refusal discipline that lets an agent decline to mark unverified work complete, and self-healing when something drifts. The pattern that proves the layer is real is an agent executing a bad order and the system catching it, rather than a human finding out later. That layer is unnamed here because it has not been published yet, and it gets published the way the first one did, as something you can use. Until you have rails of your own, treat any highly autonomous setup as a fair-weather system and check its work at the boundaries where it is most likely to be wrong.

The objective layer

The objective layer is the first named layer of an atmospheric development practice, the part of the AI agent system around you that holds your objectives and manages the prompting so you do not have to. Its operating rule is to carry work to the next decision, not the next step.

When you reach for it

When you are describing the part of a setup that owns intent between sessions: what the objective is, what state it is in, what was decided, what is queued. It is the layer people are reaching for when they say their agent keeps forgetting what they agreed on yesterday.

Worked example

The working style for this layer is published in full as a plain file at /files/objective-driven-agents-v3.txt, about 19,800 characters, with a compact twin under 1,400 characters for an instruction box that will not take the full one. You paste it where your agent reads standing instructions, which is a rules file, a system prompt, or project instructions depending on what you run. That file is the layer, in the only form that transfers.

Why it matters

The prompt was never the unit of work. Once a system holds the objective itself, it can write its own next prompt, decide when it sends, and decide who does the work, which removes the human from the middle of every step without removing them from the decisions. Naming that as a layer also makes the practice extensible: the next area of the system gets its own name when it earns one, instead of the whole practice being renamed each time it grows.

Limits

One layer is live today, and anything presented as a complete stack of layers is ahead of the evidence. Naming a layer before it runs daily is how a vocabulary stops being worth trusting. The layer also does not supply judgment. It moves work up to the point where judgment is required and stops there, which is the design rather than a shortfall.

It does not supply rails either, and that is the honest boundary on the published file. The working style teaches an agent how to behave. What enforces the behavior when a model is working past its limits is a different layer, covering verification gates, false-done telemetry, and the discipline to refuse to mark unverified work done. Run the objective layer without that enforcement and you have a system that is excellent in fair weather, which is workable as long as you know that is what you have.

Layer

A layer is a named practice area inside the AI agent system built around a person's core work. Agents are the workers inside a layer, layers organize what the agents do, and a layer only gets named once it runs in production.

When you reach for it

When you need to talk about a slice of an agent system by what it is responsible for rather than by which tools it uses. Layers are how the practice grows without the vocabulary collapsing into one undifferentiated pile of automation.

Worked example

A made-up but typical case, not a report from a live system. An operator runs a single agent that drafts, checks and files their weekly reporting. That is an agent rather than a layer. It becomes a layer the day the same operator has standing rules for how any reporting work enters the system, who reviews it, what counts as done, and what happens when a number looks wrong. The naming follows the rules, not the ambition.

Why it matters

The naming discipline is doing real work. If every new capability gets a fresh grand name, the practice becomes a taxonomy nobody can use. If layers are only named when they run daily, each name carries evidence with it and the vocabulary stays honest as the system grows.

Limits

A layer is not an architectural tier, a product, or anything you install. Two people running the same named layer will have visibly different implementations underneath, and that is expected. The name describes the responsibility, never the wiring.

Personal control plane

A personal control plane is the one place where a person's objectives live, where decisions queue up with a recommendation already attached, and where the agents underneath carry work between them. It is the practical shape an AI agent system takes once it is genuinely built around one human core.

When you reach for it

When you are describing where a human meets their agent system. The term is useful precisely because it does not name a tool. A control plane can be a file, a board, a chat surface, or a terminal, and the definition does not change.

Worked example

Picture a control plane, invented here and framed as a pattern rather than a live setup. It holds four things per objective. What we are trying to achieve, where it stands, what has already been decided, and what is waiting on a human. A fresh agent with no memory of the work can open it and take the correct next action. If the agent would also need yesterday's chat history, the control plane is not finished.

Why it matters

Scattered state is the hidden tax in most agent setups. The work exists, but it exists across a dozen threads, so the human becomes the integration layer and pays that cost every morning. One control plane converts the human's job from reassembling context to answering the calls that are genuinely theirs.

Limits

Consolidation has a floor. A control plane that tries to hold every detail becomes another surface to maintain, and at that point the practice starts serving the system rather than the person. Keep what a stranger agent needs in order to act correctly, and leave the rest where it already lives. Worth stating plainly too: a control plane makes an agent system legible without making it correct. Bad judgment arrives faster through a good control plane.

Decision queue

A decision queue is the single ordered place where an AI agent system parks every call that needs a human, with each item arriving already worked, the action staged, and a recommended default attached. It is the interface between an agent system and the judgment it cannot supply itself.

When you reach for it

When the problem is interruption rather than capability. If your system is competent but keeps stopping you mid-thought to ask something it could have prepared, the missing structure is a queue.

Worked example

The live page carries an interactive illustration of the pattern, three items, no real work behind them. One reads: two campaigns have been running over target cost per lead for six days, recommendation is to pause both and move the budget to the one running under target. The human answers, the staged action runs, and the change is written to the log. Note the shape. The item states a situation, a recommendation, and what will happen when you agree, so the answer costs one keystroke instead of a fresh conversation.

Why it matters

An unqueued question is an interruption priced at the human's full context-switch cost, and it usually arrives at the moment their attention is worth the most. Queueing converts a stream of interruptions into one batch that can be cleared in a block, which is the difference between a system that runs around your day and a system that runs your day.

Limits

A queue is not a place to park work the system could have finished. Anything that lands there without a default attached, or that arrives before the system has taken every action it could take on its own, is a queue being used as a hiding place. Time-critical calls also do not belong in a batch, and a queue with no escalation path is a way to be late politely.

Decision-queue ops

Decision-queue ops is the operating discipline that keeps a decision queue answerable: batching calls instead of interrupting, attaching a recommended default to every question, and refusing to queue anything the system could have resolved on its own. The queue is the structure and the ops are the rules that keep it worth having.

When you reach for it

When a queue exists and is not working. Most queues degrade the same way, into a list of open questions with no defaults, which is a backlog wearing a queue's clothes.

Worked example

Weak, and the shape most setups produce by default: three separate messages, minutes apart, each asking an open question with no recommendation. Strong, and the shape the published working style asks for: one message, three calls, defaults attached to each, so the human can reply with a single word and all three proceed. Same information, and the second version costs the human a fraction of the first.

Why it matters

The causal chain is short. A question with no default forces the human to reconstruct the situation before they can answer, so the cost of asking is set by how much thinking the asker skipped. Requiring a default also improves the system upstream, because an agent that cannot form a recommendation has usually not finished its own work, and that is a useful signal rather than a formality.

Limits

Defaults are a discipline, not a rubber stamp. A default attached to a decision the system does not understand is worse than an open question, because it invites agreement without thought. Decisions that are irreversible, external, or expensive get presented with their tradeoffs visible, whatever the recommendation. Batching also has a ceiling. Past a certain queue depth, clearing decisions turns into a review shift, and the batching stopped helping some time before that.

One-letter decision clearing

One-letter decision clearing is the interaction pattern in which a queued decision has been worked far enough that a single keystroke both answers it and releases the action the system already staged. It is what a decision looks like when the system has done everything except the judgment.

When you reach for it

When you want to describe the end state of decision-queue ops in concrete terms. It is also the cleanest test of whether a queue is real, because a decision that cannot be cleared with one character was not fully prepared.

Worked example

The claim behind this entry is Aaron's own, published in the campaign: this morning the system swept every lane, brought each call with a recommendation already attached, and he answered with one letter, at which point the staged action ran itself. The page's interactive module reproduces the pattern with illustrative items so a reader can feel the shape without any real work being exposed.

Why it matters

The keystroke is not the point. The preparation behind it is. One-letter clearing is only possible when the objective was held, the work was carried to the decision, the action was staged, and a default was formed, so the pattern is a visible proxy for whether everything upstream is actually working. It compresses the design goal into something you can watch.

Limits

Cheap to answer means cheap to answer wrongly. The pattern belongs to reversible, bounded, observable actions, and a system that offers one-letter clearing on an irreversible external action has mistaken speed for design. Any setup using it needs the answers logged, so a fast approval can be traced back and undone.

Carry work to the next decision, not the next step

Carry work to the next decision, not the next step, is the operating rule of the objective layer: an agent continues through every action it can take and reason about, and stops only where a human judgment call is genuinely required. It converts a series of small prompts into one delivered decision.

When you reach for it

When deciding where an agent should stop. The rule replaces the usual stopping condition, which is whenever the agent runs out of instruction, with one that is tied to the human's actual value.

Worked example

Say an agent is asked to sort out why a page is losing traffic. Invented, and generic on purpose. Step-carrying returns after the data pull and waits. Decision-carrying pulls the data, checks the obvious causes, rules out what it can, drafts the fix for the cause it believes is real, and comes back with one call for the human, which is whether to ship the fix or investigate the second-most-likely cause first. The second version costs the human one decision instead of five prompts.

Why it matters

Every step that waits on a human to write the next prompt is a step where applied intelligence sits idle and human attention gets spent on transport rather than judgment. Moving the stopping point from step to decision is the single change that most reduces interventions per completed objective, which is why the rule sits at the center of the layer instead of in a list of tips.

Limits

The rule assumes the agent can tell a step from a decision, and that judgment is itself model-dependent. Carrying too far produces confidently finished work built on an unexamined assumption, which is more expensive to undo than an early question. The honest version of the rule carries the uncertainty with the work: when an agent had to assume something to keep going, the assumption arrives with the result rather than buried under it.

Judgment throughput

Judgment throughput is how much finished, verified work one person's judgment can be spread across in a day. It is the output measure atmospheric development optimizes, on the premise that model capability got cheap while human decision bandwidth did not.

When you reach for it

When explaining why a setup is worth building at all. Most agent-system pitches are framed in output volume. This term reframes the goal as coverage of the scarce input, which is the person.

Worked example

Take some invented arithmetic. An operator with capacity for roughly a dozen real decisions in a working day is the constraint on their own output, whatever the models can produce. If their system takes work to the decision point rather than the step point, the same dozen decisions now sit on top of more finished work. Nothing about the person changed. The ratio of finished work to spent judgment did.

Why it matters

Naming the throughput measure changes what counts as an improvement. A faster model that still needs the same number of check-ins has not moved judgment throughput. A boring change to how work is queued often does. The market pays for output rather than for cost per output, which is why the measure sits on finished work instead of on how efficiently that work was produced. It is also why the practice tends to produce simpler systems than the loop-and-graph architectures it is often mistaken for.

Limits

Judgment throughput is not a number to publish, and this is the term most easily turned into a vanity metric. Spreading judgment thinner works right up until it becomes rubber-stamping, and past that point the measure goes up while quality goes down. Systems raise the floor and models raise the ceiling, so a gain from changing your system and a gain from changing your model are different goods and should not be added together. Anyone tracking it needs a false-done rate beside it, or they are measuring the sound of their own agreement.

Interventions per completed objective

Interventions per completed objective is the count of how many times a human had to step in before a piece of work was finished and verified. It is the practice metric of atmospheric development, because it rewards an agent system that returns finished rather than one that returns fast.

When you reach for it

Whenever you want to know whether a change to an agent system actually helped. It is the one number that moves for the right reasons when the system improves and refuses to move when only the vocabulary improved.

Worked example

The method is deliberately manual. Count the interventions on the next handful of objectives you finish, change exactly one thing about how work is queued or carried, then count again. Whether the number moves is the whole signal. Aaron has published his position on this on the record: he is not publishing his own figure, because a number from his setups, against his kind of work, would tell you nothing about yours.

Why it matters

Counting messages, tokens, or elapsed hours rewards an agent that returns fast and wrong, which is the failure mode most agent metrics quietly encourage. Anchoring on completed and verified objectives puts the denominator where the value is. The one published number in this campaign shows why measurement beats assumption: 86% of 518 real work sessions in one month started work without opening a single required document, from 897 sessions scanned, 518 of which did real tool work, counted as actual file opens rather than mentions. The lesson was not to enforce the reading. Instructions get used when a job depends on them and ignored when they are ceremony.

Limits

The metric needs a definition of done that you trust, so it is only as honest as your verification. It also does not compare across people. Two operators with different work will produce numbers that mean different things, and using someone else's number as a benchmark will point you at the wrong changes. Its blind spot is quality, because a system can lower interventions by lowering the bar for finished, which is why false-done rate belongs next to it. The count also mixes two causes, so record what you changed beside each number. Without that note you will credit your architecture for a model upgrade, or the model for a change you made to how work is carried.

False-done rate

False-done rate is the share of work an agent system reported as complete that a human later found unfinished or wrong. It is the honesty check on every other agent metric, because a system that reports done too early moves work back onto the human without telling them.

When you reach for it

When an agent system feels productive and the person running it feels busier. That gap is usually false-done work returning in a less convenient form.

Worked example

A made-up case with a very common shape. An agent reports a page fixed and verified. A human later finds the fix was written but never loaded in the place it had to run. Nothing was fabricated, and the claim of done rested on an assumption that was never checked. The repair is a rule rather than a scolding. A done claim states what was observed rather than what was expected, so the next reader can see which part was verified and which part was inferred.

Why it matters

False-done is expensive twice. The work has to be redone, and the human's trust in every other report drops, so they start re-checking everything, which is exactly the attention the practice was built to protect. Logged assumptions also double as error telemetry: when an agent turns out to be wrong, the assumption it recorded shows precisely where its model of the situation broke.

Limits

The rate is only measurable if someone actually catches the misses, so a low number can mean good work or thin checking. It is most useful early, when you are changing how a system reports, and it gets noisier as verification becomes routine. It is also a lagging measure, so it reports what already went wrong and gives no warning about what is about to.

Agentic engineering

Agentic engineering is Andrej Karpathy's term, named in April 2026, for engineers building software with coding agents. It is scoped to the code, and it sits beside atmospheric development rather than underneath it.

When you reach for it

When the work in question is shipping software. If the subject is a repository, a test suite, a refactor, or a build, agentic engineering is the accurate term and this dictionary defers to it.

Worked example

Two invented operators, both running agents all day. One is directing coding agents through a codebase, reviewing diffs, and shipping releases. That is agentic engineering. The other is running an operation through agents where code is one of several outputs alongside campaigns, analysis, and decisions, and their own job has narrowed to setting direction and judging output. The second is what atmospheric development, the practice of building the agent system around your core, describes. Neither is a subset of the other.

Why it matters

Keeping the boundary clean is what makes the newer term usable. A term that quietly annexes a well-named neighboring practice gets treated as marketing, and correctly so. Docking beside agentic engineering also gives readers an accurate way to place the practice on the first read, which is how vocabulary actually propagates.

Limits

The attribution is not decorative. The term is Karpathy's, the scoping is his, and it should be cited that way in any copy that uses it. Where the two practices overlap, which happens constantly for operators who also ship software, use the term that fits the work being described rather than the one that fits the argument.

Context engineering

Context engineering is the practice of designing everything a model can see at the moment it acts, rather than tuning the phrasing of a single prompt. It is the precedent coinage for this vocabulary and the rung that atmospheric development builds on.

When you reach for it

When the unit of work is what one agent can see: instructions, retrieved material, tool definitions, memory, and history. If fixing the problem means changing what is in front of the model, the term is context engineering.

Worked example

The published working style for the objective layer is a context engineering artifact by construction. It is a plain file, about 19,800 characters, written to be pasted where an agent reads standing instructions, with a compact twin under 1,400 characters for setups that cannot take the full one. It changes no code and installs nothing. It changes what the model can see, which is the whole mechanism.

Why it matters

Context engineering settled a real argument, which was that the prompt was never the unit of work. Atmospheric development takes the next step out: once you accept that everything the model sees is the input, the question becomes what the whole system does around a person while they are occupied elsewhere. The lineage is worth stating because it tells a reader exactly how much is new.

Limits

No origin claim is made here. The term spread through practitioner usage as the successor to prompt engineering, and this dictionary defines how it is used in this practice rather than adjudicating who named it. Public copy should not attribute it to a single person without a verifiable source. Worth noting for anyone planning a vocabulary: search interest in a coined term can fall sharply within a year of its peak, so plan for a term to be carried by what gets published under it rather than by the attention at launch.

Agentic workflows

Agentic workflows are task-level sequences in which AI agents plan, call tools, and iterate toward an outcome with limited human input. They are the unit of work inside a layer, and most of what gets called an agentic workflow stops at the task rather than at the human's day.

When you reach for it

When describing a specific repeatable job an agent does end to end. The term is precise at task scale and gets vague the moment it is stretched to cover an entire operation.

Worked example

Picture an ordinary one, invented for this entry. A workflow takes a weekly export, checks it against last week, flags what moved beyond a threshold, and drafts the summary. That is an agentic workflow, and it is a good one. It becomes part of a layer when there are standing rules for what happens to the flags, who decides, and how the decision gets recorded, because at that point the work no longer ends at the task.

Why it matters

The distinction matters for diagnosis. Teams with excellent agentic workflows often still feel like their AI setup is not paying off, because every workflow returns to the same human and nothing carries between them. Naming the task layer separately from the system around it is what makes that failure visible rather than mysterious.

Limits

The term has no single owner and it is used loosely across vendor and practitioner writing, so it carries less precision than it appears to. This dictionary defines how the term is used in this practice and claims no authority over anyone else's usage. Anyone reaching for a stricter definition should specify the scope they mean rather than assuming the word carries it.

Agent orchestration

Agent orchestration is the machinery for coordinating multiple AI agents, covering routing, handoffs, shared state, and supervision. Atmospheric development is what that machinery gets pointed at and who it is built around.

When you reach for it

When the subject is the coordination mechanism itself. Questions about how agents hand work to each other, where state lives, and what supervises them are orchestration questions, and they have real engineering answers that this vocabulary does not replace.

Worked example

Say two invented setups run the same orchestration machinery. One points it at maximizing autonomous task volume and produces a great deal of output that a human then has to sort. The other points it at delivering decisions to one person with the actions staged. The machinery is interchangeable. The design goal is not, and the second setup is the one practicing atmospheric development.

Why it matters

Separating machinery from intent stops a common and expensive mistake, which is judging an agent system by its architecture diagram. The published position on this is blunt and comes from having built the elaborate version first: more time went into building the system than came back out as high-quality work, and the version that survived is simpler. What changed the outcome was where the human sat in it.

Limits

Orchestration is a mature field with its own literature and no part of it is being renamed here. Nothing in this dictionary is a substitute for the engineering work of making agents coordinate reliably. Where an orchestration term already exists for a mechanism, use it.