> ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. --- title: "Agentic Engineering: Core Ideas" url: https://daily.dev/agentic-ai-hub/agentic-engineering-core-ideas/ description: "\"Agentic coding\" is an overloaded term." lastUpdated: "2026-07-22" --- "Agentic coding" is an overloaded term. Stripped down, it means you delegate a *goal* to a system that runs its own investigate-implement-verify loop with tools (a shell, a filesystem, tests, search) rather than hand-authoring each step. The craft is less about writing the perfect prompt and more about **designing the system that iterates.** A cluster of ideas defines this shift. ## What an agent actually is After a year of definitional chaos, the field has settled on a simple answer. Simon Willison, who [collected 211 competing definitions](https://simonwillison.net/2025/Sep/18/agents/), landed on one: *"An LLM agent runs tools in a loop to achieve a goal."* Anthropic's ["Building Effective Agents"](https://www.anthropic.com/engineering/building-effective-agents) adds one distinction worth keeping: **workflows** run LLMs through predefined code paths, while **agents** let the model direct its own process and tool use. Tellingly for a company that sells the models, the post tells you to reach for the simpler option and add complexity "only when it demonstrably improves outcomes." Just how simple is the core? Thorsten Ball's ["How to Build an Agent"](https://ampcode.com/how-to-build-an-agent) builds a working coding agent in under 400 lines of Go, because *"it's an LLM, a loop, and enough tokens."* That is the key lesson: if the loop itself is a few hundred lines of boilerplate, then almost everything that makes one agent better than another lives in the scaffolding around the model, what this handbook calls the harness. ## Inner loop vs. outer loop, and owning the outer one The single most useful decomposition comes from Osmani's ["Own the Outer Loop"](https://addyosmani.com/blog/own-the-outer-loop/). The **inner loop** is the agent's own cycle of investigate, implement, verify, repeat. This is where model capability lives and where you should increasingly *not* be. The **outer loop** is where a human decides whether the work is safe to ship. Evidence crosses that boundary. A person renders a verdict. Osmani's line, *"The model may write the line, but the Verdict is mine,"* compresses the whole stance. The stance has independent pedigree too. Willison likes to cite a 1979 IBM training slide, *"a computer can never be held accountable. Therefore a computer must never make a management decision."* Accountability is non-transferable, and that is why the outer loop exists. Owning the outer loop means owning **quality** (installing checks that produce evidence), **verdict** (making the ship/no-ship call on that evidence), and **answerability** (being able to explain the decision later). The failure this guards against is generating faster than you can verify, a "trust-verification gap" that widens the more capable your agents get. The practical move is to place yourself in the *constraint-setting and sampling* loops (define the guardrails, spot-check the output) rather than the inner execution loop, and to build enough back-pressure (tests, audit logs, sandboxes) that the outer loop has something real to judge. ## Loop engineering: design the system, don't hold the tool ["Loop Engineering"](https://addyosmani.com/blog/loop-engineering/) is the constructive counterpart. Hand-prompting means you hold the tool continuously (write prompt, read output, write next prompt), and *you* are the bottleneck. Loop engineering means you build the machine once and let it run. *"You designed it one time. You did not prompt any of those steps."* Osmani names five components, **automations** (scheduled discovery/triage), **worktrees** (isolated parallel workspaces), **skills** (reusable project knowledge), **plugins/connectors** (issue trackers, Slack, APIs), and **sub-agents** (separate maker and checker), plus a sixth, **persistent state** on disk or a board, because models forget between runs. The honest caveat is that loops don't remove your responsibility. They *sharpen* three risks. Unattended loops make unattended mistakes, comprehension debt grows quietly, and cognitive surrender tempts. Osmani's closing is the ethos of this whole part of the handbook. *"Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go."* ## The harness as a first-class artifact If loop engineering is the practice, ["Agent Harness Engineering"](https://addyosmani.com/blog/agent-harness-engineering/) is the object. The equation is **Agent = Model + Harness**, and its corollary is bracing. *"If you're not the model, you're the harness."* Everything you control (system prompts, tool definitions, sandboxes, hooks, memory files, context-management strategy) is the harness. One claim is worth internalizing. *"A decent model with a great harness beats a great model with a bad harness."* Most agent failures are harness gaps, not model gaps, or in HumanLayer's blunt phrase, "skill issues." Dex Horthy's [12-Factor Agents](https://github.com/humanlayer/12-factor-agents) makes the point from production experience: most software that calls itself an agent is really "mostly deterministic code, with LLM steps sprinkled in at just the right points." His twelve factors boil down to owning your own prompts, context window, and control flow instead of adopting a framework's loop wholesale. Put plainly, the reliable end of the spectrum looks more like ordinary software than the "autonomous agent" rhetoric suggests. Two design principles travel well. The first is the **ratchet**, "every mistake becomes a rule," where each failure yields a permanent harness improvement (a hook, a memory-file line, a test) traceable to the incident that caused it. The second, **"success is silent, failures are verbose"**, says hooks should only speak when something breaks, which keeps the feedback channel clean. Work backwards from the behavior you want. If you can't name the behavior a harness component serves, delete it. And accept that harnesses are perishable. As models improve, scaffolding for old failure modes becomes dead weight. The complexity doesn't shrink, it relocates. ## The factory model and long-running agents Zoom out and the metaphor becomes industrial. Osmani's ["Factory Model"](https://addyosmani.com/blog/factory-model/) reframes the job as *"building the factory that builds your software,"* where you move "from writing code to orchestrating systems that write code." Human roles become **spec architect**, **systems thinker**, and **quality reviewer**. TDD moves from good practice to "close to mandatory," because agents optimize for passing tests, so the tests must encode what *should* happen, not what currently does. The sharpest warning is that vague thinking no longer just slows you down, *"it multiplies."* A muddy spec fed to thirty parallel agents produces thirty variously-wrong artifacts. Yegge's six-waves forecast ([Levels of AI Adoption](/agentic-ai-hub/levels-of-ai-adoption/)) is the maximalist rendering of the same trajectory, and refreshingly candid about input costs. Agent fleets "burn lots of LLM tokens, to the tune of $10-$12/hour at current rates," a power bill priced like junior-developer labor. Whether his 5x-per-wave arithmetic survives measurement is the question the closing note below raises. The frontier of this is **long-running / long-horizon agents**, work that spans hours or days across multiple context windows ([Osmani](https://addyosmani.com/blog/long-running-agents/)). Three hard problems recur. Finite context comes first, along with the "context rot" that degrades quality well before the hard limit. Then there is no persistent memory, for which Anthropic's image is "engineers working in shifts, where each new engineer arrives with no memory of what happened on the previous shift." And there is self-grading bias, where models say "yes I'm done" more often than they should. The stabilizing techniques (state on disk not in context, checkpoint-and-resume, and *separated* planner/worker/judge roles) recur throughout this part of the handbook because they are the same techniques that make *any* agent trustworthy at scale. ## A note of realism from the other side It is worth pairing the enthusiasm with Armin Ronacher's ["The Coming Loop"](https://lucumr.pocoo.org/2026/6/23/the-coming-loop/), which is broadly convinced the loop is coming and broadly worried about it. His critique of *what loops produce today* is specific and worth heeding. Harness-level loops that persist past the model's own "I am done" tend to generate code that is "too defensive, too complex, too local in its reasoning." Models "avoid strong invariants" and, in Karpathy's phrase, are "mortally terrified of exceptions," adding "fallbacks instead of making bad states impossible" rather than making invalid states unrepresentable. The result is code too local in its reasoning to inspect architecturally. His conclusion is not "don't" but a bind. Opting out may be impossible, since security researchers and competitors will run loops and defenders must too, which makes *retaining engineering judgment inside the loop* the real question rather than whether to enter it. Measurement has also landed one hard punch. In the METR RCT ([Levels of AI Adoption](/agentic-ai-hub/levels-of-ai-adoption/)), experienced developers were 19% *slower* with AI while believing, before and after, that they were faster. The caveats are acknowledged (early-2025 tooling, chat-style usage, experts on familiar code), but the meta-lesson is this section's own thesis in experimental form. Perceived speedup is not evidence. If you are going to own the outer loop, own the measurement too.