Engineering Discipline for Agentic Systems

When engineers start building an AI feature, many reach for structure right away. They choose a framework, define an agent loop, create wrapper classes for every model call, and plan a set of abstractions for features that do not exist yet. This instinct comes from good habits in conventional software. In AI work, it often backfires. The first version becomes hard to read, hard to run, and hard to test before anyone has seen it do its basic job.

This article examines a belief that many builders hold: that the first version of an AI feature should already look like a finished system. The source argues the correct starting point is much smaller. The rest of this article explains what that smaller starting point looks like, why it is deliberate, and how the system grows from it.

Before reading the correction, consider a simple situation. Suppose a feature runs several model calls in sequence, and the final reply is wrong. One version of the system is a single readable file with six steps written one after another. Another version is spread across a framework, a loop, and several helper classes.

The source is candid that this code is not elegant. The file is ugly. It is also legible, and the source gives three reasons this matters. First, the customer can read it, so the people who care about the outcome can check what the system does. Second, the developer can run it directly, without setting up machinery first. Third, an evaluation set can run against it, so the first version can be measured from the start.

The example below is a generic stand-in that runs without any external service. The function call_model represents one model call. In a real first slice it would be replaced by an actual API call. The rest of the file is the literal sequence: two model calls, a parsing step, a formatting step, and a return.

Read the diagram below as a single path. Each arrow carries one value from one step to the next, and nothing has to be looked up elsewhere to follow the flow. This is the property that makes the literal version easy to debug: the path a value takes is the same as the order of the lines in the file.

Now trace the values one at a time. The variable user_text is the only input to the first model call, so it is the origin of everything downstream. The first call produces plan, which is raw text carrying a draft prefix. The line summary = parse_output(plan) strips that prefix, so summary is the value that the second prompt is built from. The second call produces review, and checked = parse_output(review) gives the value that format_reply wraps into the final reply.

The literal slice runs its steps in a fixed order that is written into the code. An agent loop works differently. The source describes an agent loop as one of the structures that engineers often add too early. The diagram below contrasts the two control patterns. In the first, control moves straight down the file once. In the second, control returns to an earlier point until a stop condition is met.

The loop is not wrong in itself. The point of the literal slice is that the developer can see the full order of steps before adding a mechanism that decides the order at runtime. A loop hides the sequence behind a condition. When the reply is wrong, you first have to find out which iteration produced the bad value, and only then which step inside it did.

Frameworks and abstractions are useful. The source's position is that they belong in a later phase, and that the right phase is rarely the first slice. Once the literal sequence runs and the evaluation set can measure it, structure can be added where the code has shown a real need for it.

The diagram is an illustration of the layers the source names, not a fixed architecture. Each layer is something a team may add once the literal version shows the need. The source's reasoning is about timing: abstractions chosen before the working slice exists are chosen without evidence.

A developer who has not yet seen which steps repeat, which prompts change, or where failures cluster may create a layer that fits the imagined system instead of the real one. Growing from a working literal slice lets the structure be shaped by what the system actually does. In the example above, you would wait until the same pattern of call, parse, and call appears in several features before you extract it into a helper.

The difference between a production-ready agentic system and a demo that breaks on the first customer test is largely a matter of engineering discipline. The source's central claim is that good agents are mostly just software. The same disciplines apply as to any other software: the behavior should be visible, the steps should be testable, and failures should be traceable to specific places in the code. The literal first slice is a practical way to hold to those disciplines from the beginning.