Loop Engineering and the Future Evolution of AI Engineering
- Jun 26
- 4 min read
There is a new phrase catching wind in the AI community: loop engineering.
It’s best explained when compared to the first generation of large language models, the interaction was simple:
User asks a question -> Model gives an answer
The focus was on writing better prompts. If the answer was not good, we adjusted the prompt. We called it prompt engineering.
But agentic AI works differently. We no longer ask the AI only to answer a question. We ask it to complete an objective.
For example:
“Research this company and prepare a short investment memo.”
An agentic system may do something more like this:
Understand the goal
↓
Break it into steps
↓
Search for information
↓
Read documents
↓
Extract key points
↓
Notice missing information
↓
Search again
↓
Compare sources
↓
Draft the memo
↓
Review its own work
↓
Improve the final output
That repeated cycle of planning, acting, observing, checking, and improving is the loop.
In other words, the intelligence of the system no longer comes only from the model. It also comes from the process wrapped around the model.
Loop Engineering vs Harness Engineering
I find it useful to separate two related ideas: loop engineering and harness engineering.
Loop engineering is about the agent’s thinking process during a task.
It answers questions such as:
How does the agent plan?
When does it use tools?
When does it check its own work?
When does it retry?
When does it decide the task is complete?
A simple loop may look like this:
Plan → Act → Observe → Reflect → Retry → Finish
Harness engineering is broader. It is the entire operating environment around the model and the loop.
It includes:
User interface
Identity and permissions
Tool access
Memory
Context management
Model routing
Logging
Audit
Security controls
Cost management
Human approval
Failure recovery
A simple analogy is Formula 1.
Loop engineering is the driver’s racing technique: when to brake, when to overtake, when to adjust strategy.
Harness engineering is the whole race system: the car, tyres, pit crew, telemetry, weather data, radio communication, and engineering team.
The driver matters, but the driver alone does not win the race.
Manus as an Example
This is why Manus attracted so much attention.
Manus did not feel like a normal chatbot. It felt more like an autonomous worker. You could give it a goal, and it would plan, browse, create files, revise outputs, and deliver something closer to finished work.
The important point is that Manus was not impressive simply because of one model response. It was impressive because of the full execution loop.
In addition, Manus is also a good example of harness engineering. It has a browser, file system, sandbox, task memory, artifact generation, and a user experience designed around delegation rather than conversation.
That is why the product feels different. It is not just “a better answer machine.” It is closer to a lightweight AI worker.
My Suspicion: Frontier Models Are Not Just Models
This leads to a suspicion I have had for some time.
When people say, “Claude is so intelligent,” or “GPT feels more capable,” we may not always be comparing pure models.
We may be comparing entire systems.
This matters because open-weight models, including many strong Chinese models, are often experienced in a much thinner harness.
You download or call the model, give it a prompt, and judge the answer.
But a frontier closed product like ChatGPT / Claude may have hidden advantages: better context handling, better tool use, better planning, better internal routing, stronger verification, better memory, and more polished product design.
So the performance gap we feel may not be just:
Western frontier model is smarter than Chinese open weighted model.
The model still matters enormously. A weak model cannot become world-class simply because we wrap it in a good loop. But a strong model without a good harness can feel surprisingly limited.
The future competition may not be model versus model. It may be AI operating system versus AI operating system.
I feel the progress of AI is increasingly driven by engineering of AI than science part of AI.
What This Means for Enterprise AI
In enterprise settings, the hard part is often not generating answers. The hard part is making the AI operate safely and reliably inside real business processes.
For example, imagine an AI operations supervisor.
It may need to:
Read incident reports
Check CCTV analytics
Understand SOPs
Check manpower roster
Review customer SLA
Escalate to the right manager
Recommend action
Record audit trail
Ask for human approval when needed
The intelligence required here is not just language intelligence. It is operational intelligence.
That requires:
Enterprise knowledge
System integration
Permission control
Auditability
Human-in-the-loop governance
Workflow orchestration
Exception handling
Performance monitoring
This is where harness engineering becomes critical.
The Shift from Assistant to Workforce
The biggest shift may be this:
AI is moving from assistant to worker.
An assistant helps you think.
A worker completes tasks.
A workforce coordinates many workers.
That changes the way we design enterprise AI.
Instead of asking only:
What can this model answer?
We need to ask:
What work can this agent own?
What tools can it access?
Who supervises it?
How do we measure its performance?
How do we control its risk?
How do we improve it over time?
This is why concepts like AI identity, agent permissions, memory, model routing, observability, and governance will become more important.
In the human workforce, every employee has a role, manager, access rights, KPIs, and escalation path.
AI workers will need the same.
The Future: Models Become Infrastructure
My personal view is that models will increasingly become like CPUs or cloud infrastructure.
The real enterprise platform will sit above them.
Enterprise AI Platform
↓
Model Router
↓
GPT / Claude / Gemini / Qwen / DeepSeek / Llama
↓
Enterprise Tools, Memory, Governance, Audit
In this world, the model is important, but the platform is strategic.