Agents, harnesses, loops, graphs: the four layers of an autonomous AI agent

You hear about agents, then harnesses, then loops, then graphs, often in the same sentence, and you end up thinking they are four ways of saying the same thing. They aren't. They are four layers stacked on top of each other, and each one solves a problem the layer below can't.

I've been building taraxe.com with these four layers since October 2026. This guide goes through them one at a time: what each one adds, real tools for each, where you stay in control, and what breaks when you skip a step.

The sequence in one picture

In one sentence each:

Agent

a language model that, to get a task done, decides by itself which tools to call and in what order.

Harness

the program that runs the agent: it gives it tools, context, permissions and memory, and catches its errors.

Loop

whatever restarts the agent without a human writing to it: a clock, an event, a condition.

Graph

the list of tasks and their dependencies, with the state of each, which the loop reads on every run to know what to do.

1. The agent: a model that acts

A model on its own answers a message. An agent is a model that has been given tools and decides by itself to use them: read a file, run a command, search the web, mail a letter with Cachet, ask a question with Aval.

There's already a small loop inside, and it's what sets it apart from a chatbot:

while the model asks for a tool:
    run the tool
    hand it the result
give the final answer

The model asks for a tool, the tool runs, the result goes back to the model, it asks for another, and so on until it thinks it's done. To fix a bug, it may read ten files, run the tests three times and change two lines, without being told each step.

What an agent can't do on its own:

• Remember. When the conversation ends, everything it knew is gone.
• Start again. Once it has answered, it stops and waits for the next message.
• Act beyond its tools. It can only do what the tools you give it allow.

The next three layers fill those gaps.

2. The harness: what runs the agent

A harness is everything around the model: the program that runs the small loop above, plugs in the tools, and decides what the agent is allowed to do.

A good harness takes care of:

• tools: files, terminal, browser, and the MCP servers you plug in;
• context: what the agent reads before it starts (in Claude Code, the CLAUDE.md file), and what gets summarized when the conversation grows too long;
• permissions: what is allowed, what needs confirmation, what is forbidden;
• memory: files the agent reads again from one session to the next;
• errors: a tool that crashes, a network that drops, a command that never ends.

Claude Code is a harness. Cursor, Codex CLI and the ChatGPT app are too, each in its own way. If you're building your own, the Claude Agent SDK gives you the same machinery as Claude Code, as a library.

One thing you notice quickly: with the same model, two harnesses give very different results. The available tools, the starting context and the guardrails do a large part of the work.

Permissions are set in advance. In Claude Code, they live in .claude/settings.json. For instance, allow the tests, forbid force-pushing or deploying to production:

{
  "permissions": {
    "allow": ["Bash(npm test)", "Bash(git checkout -b:*)"],
    "deny": ["Bash(git push --force:*)", "Bash(wrangler deploy:*)"]
  }
}

The human at this layer

When the agent wants to do something that isn't allowed in advance, the harness asks you. In a terminal, that's a prompt you answer at the keyboard. It works as long as you're in front of the screen, and only then.

3. The loop: what restarts it

So far, nothing happens unless you write. The loop replaces your message with a trigger, and the agent starts again by itself.

There are three kinds of triggers:

• a clock: every hour, every morning at 8;
• an event: a merged PR, an incoming email, a webhook, a payment;
• a condition: a parcel delivered, a price dropping below a threshold, a page that changes. That's what Réveil does, the taraxe tool that wakes an agent up when something happens.

And several ways to wire them, depending on where the agent runs:

• In Claude Code, /loop reruns a prompt at an interval, inside the open session. Handy to watch a deploy for an hour, but the loop stops with the session.
• A scheduled task outlives sessions. Claude Code in the cloud can start a session from a scheduled routine. On your own machine, a cron job running Claude Code in non-interactive mode does the same:

# Every hour, at minute 4
4 * * * * cd ~/my-project && claude -p "$(cat loop-instructions.md)"

• In n8n, a Schedule Trigger or Webhook node starts the workflow, and an AI Agent node does the work.
• On Cloudflare, a Cron Trigger wakes a Worker; Cloudflare Workflows adds steps that survive failures, pauses lasting days, and waiting for an outside event.

What the loop changes

Going from an agent you start to an agent that starts itself changes three things, and they matter more than which tool you pick.

• Nobody is at the screen. The harness's permission prompts have no one left to answer them. Everything allowed must be set in advance, and everything else must go through a channel that reaches you somewhere else.
• The agent starts from scratch every run. It doesn't remember the previous run. It needs a place to read where things stand: that's the next layer's job.
• Most runs find nothing to do. An hourly loop means twenty-four runs a day. The ones with nothing to do must do nothing, and above all not message you.

4. The graph: what tells it what to do

A loop without a graph restarts the agent with the same prompt, and the agent has to guess each time what's already been done. It redoes things, forgets others, or starts three at once.

The graph fixes that. It's a list of tasks, the nodes, linked by their dependencies: the pricing page waits for invoices, which wait for the tests. Each node has a state (to do, in progress, blocked, done). On every wake-up, the loop reads the graph, takes a node whose dependencies are all done, does it, and writes the new state:

wake up
  └─ read the state         (the graph)
  └─ pick an unblocked node
  └─ do it                  (the agent, in its harness)
  └─ write the new state
  └─ go back to sleep       (the loop)

The graph lives outside the agent, in a file or a table. That's what lets an agent with no memory keep going for weeks: it forgets everything between runs, but the graph forgets nothing.

Two kinds of graphs

The word covers two things that often get mixed up.

• A graph of steps describes how to do a task: step A, then B or C depending on the result, then D. The steps are known in advance. It's an n8n workflow, a Cloudflare Workflow, or a LangGraph graph. The agent is often one step among others.
• A graph of tasks describes what to do: a roadmap, with tasks open enough for an agent to carry each one end to end. The agent walks through it, and can even add a node when it finds missing work.

For a job that repeats identically, filing an invoice, checking a form, a graph of steps is safer. To move a project forward, a graph of tasks leaves more room for the agent's judgment. The file format, the states and the instructions to give are covered in Running an AI agent in a loop over a task graph.

Where you stay in control, layer by layer

People talk about "human-in-the-loop" as one thing. In practice, you step in at every layer, and not in the same way.

The loop layer is the one people forget. As soon as the agent runs without you, the permission prompt in the terminal is useless: it needs a way to reach you somewhere else. That's why I made Aval. Plugged in over MCP, it gives the agent an ask_human tool: the question reaches you on Telegram, or by email, with one button per answer. The agent writes the question into the graph, marks the node as blocked and ends its run. On the next runs, it checks the answer without waiting for it.

For Claude Code, it takes one command: claude mcp add --transport http aval https://www.taraxe.com/aval/mcp, then /mcp to sign in with your email.

A real example: how taraxe.com moves forward

Here are the four layers as they run on this site today.

The rules fit in a few lines: never more than two nodes in progress at once, one branch and one PR per node, a run with no change sends me nothing, a question unanswered for two days means moving on to an independent node. And the agent never merges: merging is me, once I've reviewed.

One thing I hadn't planned for: when I answer a question on my phone, nothing wakes the agent right away. With an hourly loop, my answer could sit for almost an hour before being read. Now, after each question, the agent schedules a few close checks, a few minutes later and then half an hour later, before going back to the hourly pace.

Where to start

The temptation is to jump straight to the top layer. Better to climb one step at a time, and only go up when the current layer gets in the way.

1. An agent in a harness, by hand. Start Claude Code or Cursor, give it a task, watch. That's where you learn what it does well, and what you shouldn't let it do.
2. Written permissions and instructions. When you always say yes to the same prompt, allow it. When you keep repeating the same remark, write it in CLAUDE.md.
3. A loop, when you catch yourself rerunning the same prompt every day. Start with a short, safe job: review open PRs, check a deploy.
4. A graph, when the loop starts redoing or forgetting things. A file with a few nodes is enough.
5. A channel to you, as soon as the agent runs while you're not watching.

Pitfalls, layer by layer

• Agent: too many tools. Every tool you plug in is one more description to read and one more possible action. Give it the ones the task needs.
• Harness: permissions that are too broad. Allowing everything so you're never bothered means accepting that a mistake ships to production. Explicitly forbid what can't be undone.
• Loop: runs that talk to say nothing. One "nothing new" an hour, and you stop reading within two days, including the day it matters.
• Loop: waiting for an answer inside the run. A run stuck on a question keeps everything else from moving. Ask, write it down, check on the next run.
• Graph: two writers. Two loops editing the same file end up overwriting each other. Only one agent writes the state.
• Graph: nodes that are too big. A PR you can't face reviewing stays open, and everything that depends on it waits.
• Everywhere: an expired question taken as a yes. No answer means do nothing.

Frequently asked questions