#5: The three disciplines of agentic engineering
Ken Huang, founder of Agentic AI and author of OpenClaw AI in Production, maps the three disciplines shaping the future of production AI systems
Most teams first encounter AI agents through a demo. A user sends a request, the model reasons through it, a tool is called, and a useful answer comes back. It feels almost magical. For a moment, it is tempting to believe the hard part is simply choosing the right model and writing a better prompt. Production quickly proves otherwise.
When an agent has to serve real users across real channels, with real credentials, tools, permissions, memory, failures, latency, and cost constraints, the problem changes. It stops being only a prompting problem. It becomes an engineering problem.
This is where agentic engineering begins.
Agentic engineering recognizes that an AI agent is not just a model wrapped in an interface. It is a runtime system. It needs boundaries, identity, observability, recovery paths, and a way to explain what happened when something goes wrong. It must be designed like infrastructure, not like a clever script.
Three practices define this shift: harness engineering, context engineering, and loop engineering.
Harness engineering is the discipline of building the runtime around the agent. It includes gateways, tools, permissions, hooks, retries, telemetry, memory, sandboxes, and recovery paths. The harness is what lets an agent act safely in a real system. Without it, autonomy becomes fragility.
Context engineering is the discipline of selecting, shaping, compressing, refreshing, and protecting the information given to the model. Context is no longer just “stuff in the prompt.” It is an operational resource with a budget, lifecycle, security posture, and failure mode.
New to context engineering?
We recently dedicated an entire issue to the topic, with Denis Rothman exploring how engineered context helps transform probabilistic models into more reliable AI systems.
Loop engineering is the discipline of designing the cycles through which agentic systems act, learn, improve, and produce software. At the runtime level, this means structuring the agent’s observe-decide-act-evaluate cycle with termination conditions, policy gates, retry limits, rollback paths, and human escalation points.
But loop engineering goes further.
One loop is the recursive self-improvement loop. A production agent system should be able to detect weakness, diagnose failure, propose improvement, test that improvement, validate it against policy, and only then adopt it. This does not mean giving agents uncontrolled permission to rewrite themselves. It means creating bounded, observable, auditable improvement cycles where agents can help harden the system without bypassing engineering discipline.
Another loop is the continuous software factory. In agentic engineering, software development itself becomes a loop: requirements become designs, designs become code, code becomes tests, tests become deployment signals, deployment produces telemetry, telemetry informs the next requirement, and the cycle continues. Agents can participate at every stage, but the factory still needs gates, evidence, review, and rollback.
This is one of the central themes of my upcoming book, OpenClaw AI in Production. OpenClaw treats agent behavior as something that must be routed, bounded, observed, and corrected through architecture. The Gateway becomes the control plane. The request pipeline separates context assembly, authorization, directive handling, tool execution, and model invocation. Hooks allow cross-cutting concerns such as telemetry, policy, billing, and remediation to operate outside the core agent logic.
That architecture matters because agent failures rarely appear as simple crashes. A stale memory, a slow tool, a partial outage, a malformed directive, or an over-permissive policy can quietly distort the loop. The agent may keep acting, but each step moves it further from safe and useful behavior.
Production systems need to detect that drift.
This is why observability for agents has to go beyond CPU, latency, and HTTP response codes. A 200 OK from a model provider does not tell us whether the agent used the right tool, respected the right policy, retrieved the right memory, or stopped at the right time. Agentic systems need semantic observability: traces that show the agent’s observable decisions without leaking sensitive data or private reasoning.
The deeper opportunity is self-correction. If an agent platform can detect degraded state, isolate the failing component, reduce privileges, pause risky workflows, retry safely, or route through a fallback path, then we move from passive monitoring to active resilience. If the software factory can learn from its own incidents, tests, deployments, and user feedback, then engineering itself becomes more adaptive.
The future will not be won by prompts alone. It will be built by engineers who understand harnesses, contexts, and loops - and who can turn model intelligence into systems that are secure, observable, resilient, and continuously improving.
OpenClaw AI in Production is my attempt to map that territory in detail: from Gateway-centered architecture and policy enforcement to distributed state, semantic observability, self-correcting stacks, fault injection, high-throughput design, and decentralized deployments.
Agentic engineering as a discipline is still young. But one thing is already clear: building agents that work in demos is very different from building agents that survive, learn, and improve in production.
Ken Huang is an AI researcher, author, educator, and founder of Agentic AI and DistributedApps.ai. He serves as CEO and Chief AI Officer at DistributedApps.ai, is an Adjunct Professor at the University of San Francisco, and co-chairs multiple AI safety initiatives at the Cloud Security Alliance and OWASP. A prolific author of books on AI, security, and distributed systems, his latest work, OpenClaw AI in Production, explores the engineering practices required to build reliable AI agents at scale.
This article is a glimpse into the ideas behind Ken’s OpenClaw AI in Production. If you’re interested in building AI systems that are resilient by design rather than optimistic by default, the book expands on the engineering principles that separate production platforms from impressive prototypes.
Building agents that work in demos is very different from building agents that survive, learn, and improve in production." That gap is where most agentic projects quietly die.
The harness vs prompt distinction is the one most teams learn too late. A clever prompt is not a runtime. It has no recovery path, no permission boundary, no telemetry. The moment something fails at step seven of a twelve step workflow, you need architecture, not better wording.
The semantic observability point is underrated. A 200 OK from the model provider tells you nothing about whether the agent used the right tool, respected the right policy, or stopped at the right time. Knowing the agent responded is not the same as knowing it behaved.
Context as an operational resource with a budget, lifecycle, and failure mode reframes everything about how most teams think about prompting.
The gap between a demo and a production agent is a graveyard of abandoned architectural integrity. Most teams optimize for the first turn, ignoring the quadratic growth of operational debt. When the context window fills with fragmented history, your model doesn't get smarter, it gets expensive. We’re moving toward a model where every tool call exists inside a transactional cage. If the SMT solver can't verify the state-space transition, the call doesn't fire. Secure engineering isn't a post-process audit. It’s a compile-time constraint. Are your agents self-healing or just self-mutating?