In the part 1 of this series, we saw that giving a model tools does not magically make it an agent.

Something has to execute those tools, feed their results back into the model, maintain state, and decide what happens next.

That something is our harness.

But a harness can get very complicated very quickly.

So instead of starting with a giant architecture containing dozens of components, let's strip it down to the smallest generic harness we can possibly build.

The Agentic Loop

Let us begin with the simplest agent, we have a model, a set of tools and an environment

The model's job is to decide what to do, The tool's job is to perform that action. The environment is where the action takes place.

But there is nothing orchestrating these components, like we saw in the last blog, the model can call a tool, but the model cannot execute the tool.

The harness recieves this tool call, maps it to the correct tool, executes it, captures the result and passes that result back to the model. The model now has new information and can decide what to do next. This process continues until the model decides to stop or the task is complete.

That is our basic agentic loop.

Model -> Action -> Environment -> Model

At first this loop seems very simple, but it is the foundation of all agentic harnesses.

But lets zoom in and see more, after the model recieves the result, that is passed back to the model but how do we actually decide what information to pass back to the model ?

The entire conversation, the entire result ? every tool ? current state ? previous attempts ?

So what should a model actually know about the environment and its state ?

To answer this question, we move on to Context Engineering, which is the next level.

Context Engineering

Now we defined a simple agentic loop.

Imagine the same agent has made 10 tool calls, it has read files, run commands and made several decisions.

Do we just keep giving the model all the information about the environment, which is everything so far?