Select your country

Not finding what you are looking for, select your country from our regional selector:

Search

| Blog

How AI Agents Changed Engineering Runtime: Tools, Context, and Continuous Loops

Author: Zexian Li, Orange Cyberdefense China

Note: This article is compiled from public disclosures by OpenAI and Hugging Face as of July 28, 2026, alongside media interviews with relevant individuals.

OpenAI has not yet released its final technical report. Select details on incident timelines and anomalous behaviors are sourced from media reports citing people familiar with the matter. This article makes every effort to clearly delineate officially confirmed facts, media-sourced information, and the author’s independent analysis.

This article covers comprehensive in-depth content and may take some time to read through.

From code generation to agents: the change is happening outside the model itself, too.

If you look only at model names and benchmark scores, it is easy to reduce the changes of the past few years to a simple story: “the models have become smarter.”

But from an engineering perspective, what has truly changed the way AI behaves is the entire runtime system surrounding the model.

Stage one: one request, one response.

The early programming-assistance workflow was usually:

The model cannot directly see the real engineering environment, nor can it know what happened after the code was executed.

If the program throws an error, the user has to paste the error message back into the model. Every modification depends on manually transferring context.

In this mode, the model is just a code generator within the software engineering workflow.

Stage two: the model enters the development environment.

Subsequently, AI began to be integrated into IDEs, terminals, and code repositories.

The model was no longer just generating code; it began participating in the full software development loop: after writing code, it could compile immediately. If compilation failed, it could read the error. If tests did not pass, it could search for relevant implementations again and keep iterating.

As a result, code-generation ability was no longer the only deciding factor.

The same model, when limited to outputting text, and when given access to a repository, terminal, test framework, browser, and deployment environment, can perform very differently in practice.

Stage three: agents gain tools and the ability to run continuously.

The basic interaction model of a standard chatbot is:  Input → reasoning → output

An agent system is closer to:

OpenClaw is a typical example of this kind of system.

Here we need to distinguish several concepts that have appeared frequently in recent years.

Prompt determines how the model interprets the current instruction, Context determines what information the model has access to, Harness determines what actions the model is allowed to take, and Loop determines whether those actions can continue over time.

An agent is a system composed jointly of the model, context, tools, permissions, runtime environment, and feedback loop.

This also explains why the same base model can exhibit completely different engineering capabilities and safety risks when placed in different agent frameworks.

24/7 incident hotline