New Names, Old Fundamentals: Decoding the Agent Era's Rebrands
The agent era shipped a fresh vocabulary in about eighteen months. Harness engineering, context engineering, loop engineering, the harness is the backend. Read the definitions closely and most of them describe fundamentals we have taught for decades. That is not a complaint. Knowing the old idea under each new name is the fastest way to tell what actually changed from what is just packaging.
Why the renaming happens
A new name does two jobs. It helps a new audience discover an old idea, and it signals that something in the world shifted. Both are useful. The problem starts when the name hides the lineage, because then every team relearns the fundamental by trial and error instead of reading the thirty years of writing that already solved it.
Here is the tell for the current wave. The people defining these terms keep citing the classics: reconciliation loops from control theory, capability-based security from the 1970s, the strangler fig for migrations, parse-don't-validate for boundaries. The frontier is reaching back for fundamentals and pointing them at a new kind of reader. The reader changed from human-only to human-and-model. The principles did not.
The map: new name to old idea
Here are the rebrands worth decoding, with the fundamental sitting underneath each.
Building the environment around a worker so it can do the job: context, tools, and checks. That is an internal platform and the developer experience around it, with the user being an agent instead of a person. I unpack this in harness engineering.
Deciding what to retrieve and where to place it. Keep a large store and a small working set, and load the relevant slice only when a decision needs it. That is demand paging and the working-set idea, applied to a context window.
Run settled work on a sensor, compare to a desired state, act, repeat. That is a reconciliation controller, the same pattern a thermostat and a Kubernetes controller share. We have renamed the control loop once a decade for a long time.
One accountable owner carries an outcome end to end instead of fragmenting it across handoffs. That is the directly-responsible-individual model and the operational ownership principle, restated for a non-human owner.
Separate what an actor can do from what it is allowed to do. Broad freedom in reversible sandboxes, scoped and revocable grants at the consequential edges. That is least privilege and separation of duties, plus the one-way versus two-way door framing for where a human belongs.
Match the evidence to the claim. A passing unit test proves one assertion. A user-facing claim needs a real journey, a production claim needs a canary and live signals. This is the testing discipline most teams already knew and skipped.
Promote a recurring correction to its earliest durable owner, from a note to a lint to a type to an architecture rule, and fix the whole population, not the one instance. That is mistake-proofing and the retrospective action item, done with discipline.
When code is cheap to regenerate, the durable asset is the spec, the contracts, and the proof set. Depending on a shared contract rather than a shared package is the same move that lets you target POSIX instead of one libc.
Decode the name and you inherit thirty years of writing about the problem. Take the name at face value and you relearn it the expensive way.
What is genuinely new
The honest version of this argument admits that not everything is a rerun. Two things in the agent era are real wrinkles, not renames, and pretending otherwise would be its own kind of hype.
Attention as a scarce resource across a long run. Where you place an instruction changes how long it competes for the model's attention over thousands of steps. The closest classic analog is cache eviction and working-set management, but the mechanic that instruction placement affects salience over time is specific to how these models read. It is worth studying on its own terms.
Requalifying on every model upgrade. When the worker you build on is a model, a version bump can regress capability in ways a normal dependency rarely does. A newer model can be less willing to attempt a hard task, not just faster or slower. That is close to not trusting a version number, but the non-monotonic, hard-to-predict capability shifts are a new failure mode that deserves real testing rather than a shrug.
How to use this
When a new term lands, run it through one question: what is the fundamental underneath, and who wrote the definitive treatment of it. If there is a classic answer, read that first. You will implement the trendy version faster and skip the mistakes the original already documented.
Keep the name if it helps your team find the idea. Just do not let it hide the lineage. The durable skill is recognizing the old fundamental wearing a new word, because the fundamentals are what still matter when this vocabulary is replaced by the next one.
FAQ
Is harness engineering a new discipline? Mostly not. It is platform engineering and developer experience aimed at a non-human user. You build the environment around a worker so it can do the job. The audience changed, the practice is familiar.
What is context engineering, really? Deciding what to retrieve and place at which decision point. Underneath it is caching, lazy loading, progressive disclosure, and information architecture: a large store with a small working set.
Why does the industry keep renaming old ideas? New names help a new audience find an old idea and signal that something changed. Often what changed is the context, not the principle. Decoding the name back to its fundamental separates substance from packaging.