Jason A. Hoffman, PhD
Applied AI apparently keeps producing new engineering disciplines. In September 2025, Anthropic described context engineering as the natural progression of prompt engineering. Two months later it published a method for building long-running agent harnesses. By August 2026, two preprints were proposing loop engineering and graph engineering as the next stages.
The work behind these names is often useful. The claim that each name defines a durable new discipline is much weaker.
A fashionable category usually begins with a model that cannot reliably do something a user needs. Builders compensate with instructions, context assembly, memory files, critics, routers, state machines, or multiple agents. The workaround improves results, so it earns a name. Products and consultancies gather around the name. Then models improve, the platform absorbs the generic machinery, and the surviving work returns to requirements, data, interfaces, distributed systems, security, testing, or operations.
The phrase and the work therefore have different half-lives. A phrase can disappear while the underlying responsibility becomes more important.
I use half-life as a review discipline, not a literal decay constant. After each material model or platform change, ask how much of the named category still earns its place in the system.
For any new form of “AI engineering,” ask five questions:
- What model limitation created it?
- What workaround was built?
- Which part will the model or product absorb?
- Which established engineering responsibility remains?
- What evidence would tell us to delete the workaround?
That last question matters most. A temporary solution becomes permanent architecture when nobody defines the condition for removing it.
One complete cycle
I watched this cycle run from beginning to end in forty-three days.
On December 24, 2025, I built a framework of fourteen agent roles, shared memory files, task assignments, dependency tracking, session summaries, and custom commands because the coding agent I was using lacked those capabilities. The framework helped me ship a large application. On February 5, 2026, the agent product added native teams, memory, tasks, planning, exploration, and context compaction. I deleted most of my framework.
The experiment produced the disintermediation principle: keep frontier models in the critical path, and avoid hardcoding a substitute for capabilities the model vendor has both the access and incentive to improve. What survived the deletion was domain knowledge, data access, tools, architectural constraints, and setup work the agent could not perform. The generic choreography disappeared.
A February essay on enterprise software later named the surviving responsibilities more precisely: schemas, identity, authorization, transaction semantics, durable state, observability, and recovery. The half-life map adds sequence and direction. Category names rise and fall as model limitations move; systems still have to discharge those responsibilities.
That case was not special. It was an unusually fast example of a pattern that now repeats across the AI tooling market.
Already fading
The following judgments describe direction, not measured market share. Each category still has useful implementations. The question is whether its model-compensating form can remain a durable product boundary.
| Phrase or product form | Model limitation it addressed | Temporary form | What remains |
|---|---|---|---|
| Prompt engineering | Weak instruction following | Incantations, personas, elaborate templates, repeated behavioral instructions | Clear objectives, constraints, examples, schemas, and acceptance criteria |
| Prompt chaining | Weak multi-step reasoning | Fixed sequences that tell the model how to think | Actual workflow dependencies and checkpoints |
| Prompt marketplaces | Difficulty reproducing model behavior | Collections of magic wording detached from a task and evaluation | A small role for tested templates and examples |
| Multi-agent debate | Weak self-criticism | Several model instances arguing until one sounds convincing | Independent evidence, adversarial tests, and accountable review |
| Autonomous-agent frameworks | Weak planning, tool use, and persistence | Generic role choreography, planners, critics, and hand-built memory loops | Tools, state, isolation, permissions, observability, and recovery |
| Vector database as memory | Small context windows and weak retrieval | Embedding every interaction and calling the result memory | Search, databases, retention rules, provenance, and user-controlled records |
| RAG as the application | Models could not access private or current information | Retrieval wrapped around a model and presented as a complete product | Governed retrieval from authoritative sources |
Prompts will persist because users must express objectives and supply facts the model cannot know. Prompt engineering fades where it means special wording that compensates for weak instruction following. The durable part is requirements work: deciding what success means, stating constraints, and providing representative examples.
Retrieval will persist for the same reason. A larger context window does not grant access to a company’s current records, establish which record is authoritative, or decide who may read it. What fades is the idea that chunking documents into a vector database constitutes an application or a memory system by itself.
Multi-agent debate exposes the distinction most clearly. Running the same model several times can improve a result under some conditions. It does not create independent evidence. If every participant reads the same false source or shares the same blind spot, agreement adds little. Tests, primary sources, separate measurement, and human accountability survive because they observe something outside the conversation.
Currently inflating
The current vocabulary moves outward from the prompt toward the system around the model. This is progress in one sense: builders are paying attention to state, tools, execution, and evaluation. It is category inflation when a point-in-time technique is presented as a new foundation rather than a temporary implementation of an older responsibility.
| Phrase | Model limitation it addresses | Likely absorption | Durable responsibility |
|---|---|---|---|
| Context engineering | Limited attention and degraded use of long contexts | Manual packing, chunking tricks, and model-specific compaction policies | Authorized data selection, provenance, freshness, and relevant task state |
| Memory engineering | Weak continuity across sessions | Synthetic summaries and bespoke memory-file rituals | Durable state, retrieval, versioning, retention, and deletion |
| Harness engineering | Weak tool use, planning, persistence, and context management | Generic agent loops, role choreography, and model-specific behavior patches | Isolation, identity, credentials, budgets, tools, event logs, and recovery |
| Loop engineering | Agents stop early, drift, or fail to verify | Fixed reflection, critique, and recursive-prompt routines | Trigger, execute, observe, verify, retry, stop, recover, and escalate |
| Graph engineering | One agent struggles to coordinate complex work | Prescribed reasoning graphs and fashionable agent topologies | Real task dependencies, assets, authority, provenance, and physical relationships |
| Intent engineering | Models pursue the wrong interpretation of a request | A new vocabulary around eliciting intent | Requirements, product definition, and decision rights |
| Specification engineering | Models need explicit boundaries before implementation | AI-specific packaging of the specification | Established specification and systems engineering |
| Tool or skill engineering | Models call capabilities poorly or lack them | Model-specific descriptions and packaging conventions | API, interface, and integration design |
| AgentOps and reliability engineering | Long-running agents fail in production | Agent-specific dashboards and wrappers | SRE, security, observability, incident response, and recovery |
| Fleet engineering | Many agent instances require coordination | Agent personas and supervisor choreography | Scheduling, identity, isolation, distributed state, and cost control |
| Trajectory engineering | A successful outcome depends on a sequence of actions | Attempts to prescribe an ideal reasoning path | Evaluation, trace analysis, and outcome verification |
Context engineering is useful today because context remains finite and models do not use every additional token equally well. Yet the context window is only a temporary projection of the information available to a task. The source record, its permissions, its freshness, and its provenance must live elsewhere. Better retrieval and larger windows change what gets projected; they do not remove the source system.
Harness engineering contains an equally sharp division. Anthropic described a harness workaround that reset context when Claude Sonnet 4.5 appeared to anticipate its limit and finish early. When the team moved the same harness to Opus 4.5, the behavior had disappeared and the resets became dead weight. Anthropic used that case to explain why harness assumptions go stale as models improve.
The same system retained a durable session log, isolated execution environments, credential separation, and recovery after a harness failure. Those components do not exist to make a model think better. They preserve state, control authority, contain untrusted code, and restore work after failure. A better model can use them more effectively, but cannot make their responsibilities disappear.
Loop engineering makes an old distinction sound new. The August 2026 preprint describes event-triggered agent runs, machine-checkable stopping conditions, persistent state, token budgets, verifiers, and human escalation. The authors confirmed active autonomous loops in 217 of the 256 repositories matched by their heuristics, while almost none committed the state files prescribed by the surrounding discourse. They leave the effect on effort and outcomes to planned controlled work. The recursive prompting may change with the next model. Triggers, observations, stopping conditions, budgets, and recovery belong to control systems and operations.
Graph engineering needs the same separation. Its proponents describe dynamic graphs of tasks, agents, and system state. A graph can be useful when it represents dependencies that exist outside the model: which component supplies another, which person may approve an action, which asset connects to a power path, or which source supports a claim. A fixed graph of how agents should reason is more fragile. A stronger model may find a better decomposition, combine roles, or reject the graph’s assumptions.
The supervisory model follows the rule too. A second model that tells the first to reflect, debate, or try harder is another model-facing technique. Independent supervision observes execution, checks external evidence, enforces limits, and can stop a consequential action. The supervising model may change. The separate observation and control path remains.
The next wave has started
The next category names can be inferred from the places agents now fail. A check of the exact phrases on September 3, 2026 found that the naming cycle was already underway. The evidence falls into four groups.
Already arriving
| Phrase | Evidence that it is circulating | Established work underneath it |
|---|---|---|
| Attention engineering | A July 2026 preprint explicitly proposes it as a direction for allocating attention across multi-agent graphs | Information retrieval, scheduling, resource allocation, and model design |
| Environment engineering | A June 2026 survey of agentic environment engineering organizes the subject around modeling, synthesis, evaluation, and application | Simulation, data engineering, interface design, evaluation, and digital twins |
| Outcome engineering | AWS guidance and an agent-development product both use the exact term | Requirements, testing, product management, state verification, and audit |
A preprint, a vendor guide, or a product name proves that a phrase circulates. It does not prove that the phrase identifies a coherent discipline or that the market has adopted it.
Older fields receiving new attention
Collective-intelligence engineering is not a prediction. A 2023 journal survey used “artificial collective intelligence engineering” to connect work in multi-agent systems, distributed computing, robotics, and control. The LLM-agent wave gives that work a new object of study, not a new origin.
Human-agent systems are also an established research subject. Current work draws on cognitive systems engineering, adaptive automation, and human-computer interaction to study how people and agents divide and reconfigure work. The exact phrase “human-agent systems engineering” does not yet appear established, but the underlying field is not waiting to be invented.
Isolated early uses
“World engineering” appears in a 2026 practitioner preprint about constructing useful habitats for artificial minds. “Autonomous operations engineering” appears as the positioning of at least one AI consultancy. These are signals of category formation, not evidence of a research community or durable market.
Still predictive
I found no credible exact use of the following labels in the AI-agent sense. That is search evidence, not proof of absence. The problems and the established disciplines underneath them already exist.
| Possible phrase family | Point-in-time problem | Established work underneath it |
|---|---|---|
| Delegation or authority engineering | Agents assign work or exercise permissions badly | Requirements, organizational design, IAM, authorization, and policy enforcement |
| Supervisor engineering | One agent needs oversight from another | Control systems, evaluation, audit, and separation of duties |
| Agent organization engineering | Many agents fail to coordinate | Multi-agent systems, distributed systems, scheduling, communication, and governance |
| Model portfolio engineering | Different models vary in capability, cost, and risk | Routing, procurement, evaluation, and portfolio economics |
| Inference-economics engineering | Token use, latency, and serving cost become binding | Performance engineering, capacity planning, and managerial economics |
| Human-agent systems engineering | Work moves between people and agents | Human-computer interaction, cognitive systems engineering, organizational design, and ergonomics |
The boundary work has already started without the inflated names. A July 2026 paper defines a delegated-autonomy boundary, including purpose, authority, information, coordination, assurance, and evolution. Its authors correctly place that work in requirements engineering. They add an artifact for an agent-specific operating regime without pretending that authority itself was newly discovered.
Each name can point to a genuine specialization. Inference engineering, for example, operates concrete serving systems with queues, batches, caches, accelerators, latency targets, and capacity limits. Evaluation engineering produces task sets, graders, baselines, and regression evidence. Those artifacts can be tested independently of a fashionable label.
The marketing move occurs when the name claims more novelty than the work. A probabilistic model may change the operating regime, but it does not repeal requirements, database consistency, access control, queueing, experimental design, or incident response. The new component changes how those disciplines are applied and which failures dominate. It rarely erases their first principles.
Phrase durability is not work durability
This matrix is a judgment about category boundaries, not a forecast of employment or market size. “Conditional” means the work persists when it attaches to an external dependency or observable outcome rather than a prescribed model behavior.
| Phrase | Phrase durability | Underlying work durability |
|---|---|---|
| Prompt engineering | Low | Medium |
| Context engineering | Medium | High |
| Memory engineering | Low | High |
| Loop engineering | Low | Conditional |
| Harness engineering | Medium | High |
| Graph engineering | Low | Conditional |
| Evaluation engineering | High | High |
| Inference engineering | High | High |
| Security and authorization | High | High |
| Data and state engineering | High | High |
Evaluation and inference engineering rate differently because they own measurable objects. An evaluator defines tasks, trials, graders, and outcomes. An inference system serves requests under explicit latency, throughput, energy, and cost constraints. Better models change the measurements and workloads, but the systems still need to measure and serve them.
Anthropic’s evaluation vocabulary offers a useful test. A transcript records what an agent said and did; the outcome is the resulting state of the environment. A flight agent can claim it booked a seat. The durable check asks whether the reservation exists in the database. The trajectory may change completely with a new model while the outcome requirement stays fixed.
Start with responsibilities
Before naming another discipline, describe the system without AI vocabulary:
- Objective: What must the system accomplish, and what counts as acceptance?
- State: Which facts are authoritative, current, and recoverable?
- Authority: Who or what may read, decide, spend, and act?
- Action: Which interface changes the world, and what transaction rules apply?
- Observation: What evidence shows that the action produced the intended result?
- Failure: How does the system stop, retry, reconcile, roll back, or escalate?
- Economics: Which limits on time, compute, energy, and money must it obey?
These responsibilities precede the choice of model, agent framework, protocol, or orchestration pattern. They also reveal where open-ended cognition belongs.
Put open-ended cognition in frontier models. Keep authoritative state, domain tools, consequential action, measurement, and recovery in systems you own.
This does not mean writing every plan in code. Give the model the objective, evidence, tools, and limits, then allow it to choose a path. Keep code around the consequences: validate the tool input, enforce authorization, record the effect, inspect the outcome, and recover when the action fails.
The deletion tests
The ten-times-better-model test remains useful: if the model became ten times more capable, would this component gain value or lose its reason to exist? Governed data, bounded tools, and evaluations usually gain value. Elaborate role prompts and fixed reasoning flows usually lose it.
A second test covers system responsibility:
If the model were ten times better, compromised, replaced, or unavailable, would this component still be required?
If yes, the component probably owns a durable fact, control, or consequence. Authentication must still protect credentials. A transaction must still balance. A session must still recover. A test must still distinguish success from a fluent claim of success.
Then make deletion empirical. On each material model or platform upgrade:
- Run the same evaluation with the workaround enabled and removed.
- Compare outcome quality, failure rate, latency, cost, and recovery behavior.
- Test the platform’s native capability against the external layer.
- Remove the layer when it neither produces a material benefit nor independently enforces a requirement.
- Preserve the evidence and the rollback path in case the apparent improvement does not survive production.
An intervention that improved one model on one evaluation proves that the intervention helped that model-system pair at that time. It does not establish a permanent architecture. The burden should remain on the extra layer, because every layer adds another interface, failure mode, dependency, and maintenance obligation.
Prompts persist; incantations fade. Context persists; manual packing changes. Loops persist where actions meet observations. Harnesses persist around authority, state, and failure. Graphs persist when they represent relationships in the world.
Treat the new names as field reports from the current capability boundary. Extract the durable responsibility, connect it to the engineering discipline that already owns it, and state what result would let you delete the rest.
Sources and further reading
- Anthropic, “Effective context engineering for AI agents”, September 29, 2025.
- Anthropic, “Effective harnesses for long-running agents”, November 26, 2025.
- Anthropic, “Demystifying evals for AI agents”, January 9, 2026.
- Anthropic, “Scaling Managed Agents: Decoupling the brain from the hands”, April 8, 2026.
- Jai Lal Lulla et al., “Loop Engineering: Building Blocks, Adoption, and Impact,” version 2, August 26, 2026. Preprint under review.
- Yuyuan Feng et al., “Graph Engineering in the Era of LLM Agents: From Individual Intelligence to System Intelligence,” version 2, August 26, 2026. Preprint.
- Roberto Casadei, “Artificial Collective Intelligence Engineering: a Survey of Concepts and Perspectives”, Artificial Life, July 2023.
- Jiachun Li et al., “Agentic Environment Engineering for Large Language Models: A Survey of Environment Modeling, Synthesis, Evaluation, and Application”, June 10, 2026. Preprint.
- Mingzhou Fan, Siyuan Xu, and Mingxuan Yuan, “Focus Is All You Need: Adaptive Goal-aware Attention Orchestration for Multi-Agent Graph Systems”, July 26, 2026. Preprint.
- Chetan Arora, Andreas Vogelsang, and Abbi Sharma, “Specifying the Delegated-Autonomy Boundary: Requirements Engineering for Agentic AI”, July 19, 2026. Preprint.
- Martijn IJtsma and Salvatore Hargis, “Envisioning the work of reconfiguring: A modeling perspective for designing adaptive human-agent systems”, AI Magazine, August 27, 2026.
- Edward Blair, “World Engineering: Building Habitats for Artificial Minds”, April 10, 2026. Practitioner preprint.
- AWS Prescriptive Guidance, “Generative AI Lifecycle Operational Excellence framework on AWS”, 2026.
Leave a Reply