Part 2

Who owns the agent loop

The two projects split on one question: does the platform supply the agent loop, or does your container? This page sets out each answer and what follows from it.

After this page you can:

Define an agent loop and say who writes it in ax and in kagent.
Describe what ax-task-runner does before your command starts.
Explain how a kagent Agent becomes a revision and a Session.

The question that splits them

An agent loop is the code that calls a model, reads the reply, calls tools, and decides what to do next. Both projects run that loop inside a Substrate Actor. The difference is who writes it.

Figure: in ax your container image runs the loop; in kagent the Harness runtime runs a loop the platform compiled from your AgentTemplate.

Left, ax: a Task (image, command, limits) starts ax-task-runner as PID 1, which prepares the Workspace and then starts your own agent process, which runs any loop you like; the output is whatever your command does. Right, kagent: an AgentTemplate (model, prompt, tools) and a Harness (Go or Python ADK, Codex, Claude, or your own image) are paired by an Agent and compiled into an immutable revision whose runtime runs the loop; the output is an A2A task plus durable history in a Session.

ax: you bring the loop

ax deliberately does not model what an agent is. Its concepts guide says an agent "plans, delegates, retries, and fans work out. AX does not try to model that shape."³ Instead ax offers one primitive, the Task, that is "cheap to create, isolate, suspend, and throw away", and lets an agent create as many as its work needs.³

Inside the sandbox, ax-task-runner runs as PID 1, prepares each Workspace, and then starts your spec.command as a supervised child process.⁵ Whatever loop that command contains is the agent. ax's own roadmap lists "Allow Customization", which decouples the built-in coding agent harness, so this layer is still being shaped.⁶

kagent: the platform brings the loop

In kagent the agent is the first-class object. An AgentTemplate describes what the agent does (model configuration, prompt, MCP tool bindings, skills, plugins), and a Harness describes how a class of agents runs (exactly one runtime variant out of kagent, Codex, Claude, or bring-your-own, plus the workload image and Substrate policy).²⁵ An Agent pairs one template with one Harness.²³²⁵

The controller compiles each Agent into an immutable revision, applies it as a Substrate ActorTemplate, and waits for the golden snapshot before marking the revision as the latest successful one.²⁵ Each conversation is a Session: PostgreSQL-backed control-plane state that pins one prepared revision and names one Substrate Actor, and is not a Kubernetes resource.¹⁰

What follows from the split

Consequences of loop ownership
Concern	ax	kagent
What you ship	ax: a container image and command that contain the agent.³	kagent: YAML that describes the agent; the Harness image is the runtime.²⁵
Output of a run	ax: whatever the command does to the workspace, repositories, and APIs it reaches.⁵	kagent: A2A tasks and conversation history stored in PostgreSQL.⁸
Changing behaviour	ax: build a new image or create a new Task.³	kagent: edit the template or Harness; only Sessions created afterwards see the change.²⁵