Nac

Introducing NAC, an Open-Source Harness for Long-Running Agent Work | Arcee AI | Building Open Intelligence

Introducing NAC, an Open-Source Harness for Long-Running Agent Work

Introducing NAC, an Open-Source Harness for Long-Running Agent Work

T + 3 The Arcee AI Team, Brett Larsen, Lucas Atkins, Varun Singh

15 min read • Aug 13, 2026

Product An open-source runtime built for complex engineering work. Nac coordinates parallel agent workers and persistent state across long tasks.

When implementing a feature, an agent can spend tens of thousands of tokens reading code, editing, debugging, editing further, until finally returning with a solution. By that time, it’s lost track of the finer details of what the user may have discussed in the early stages of the conversation. In extreme cases, this can even lead to the agent carrying out its task in a way that the user never initially intended, with important user-message context diluted as the session continues. Most agent systems do not distinguish between different stages of work. The investigation, its tool output, its false starts, the evolving plan, and the state of the larger task all accumulate in one transcript. And this accumulation can even actively harmful: model performance itself degrades over long tasks, a failure mode now known as context rot. [1] On long-horizon tasks, where the work runs through many sequential steps, the agent’s context becomes a constraint, and when context fills up, compaction operations can throw away important detail. We think this couples two things that should be separate: the temporary context needed to perform an action; and the persistent state needed to continue a workstream.

Nac is an open-source agent harness we built for ourselves around that separation and is available under Apache-2.0 at https://github.com/arcee-ai/nac . This blog explains the implementation, the ideas it draws from, and why agent harnesses are becoming a new kind of inference runtime. Nac in action Nac sessions can extend over many hours, sometimes even days - which isn't conducive to real-time video. Below is a timelapse from part of a nac session, working on generating and recording the the UI motion graphics for our launch video.

Your browser does not support the video tag.

And here's the finished video:

Your browser does not support the video tag.

What is nac? Nac is an open-source agent harness that we built for ourselves for longer, more ambitious tasks. We use it internally for many different tasks: running experiments, supervising training runs, working on infrastructure, and rapidly prototyping new ideas. Many of these tasks are deeply intertwined — you may want to prototype an idea, evaluate it, integrate it into a different system, scale it up, use that feedback to refine the idea, and keep iterating from there. Nac is built around a version of thread-and-episode architecture from Random Labs' Slate report [2] : a central orchestrator plans and decomposes work, and threads that are dispatched to complete a single work item. The threads return episodes, as structured summaries of the work they’ve accomplished, useful files, results, etc. Importantly, the orchestrator’s only action is launching threads; it cannot execute commands or edit files on its own. Nac makes this architecture concrete through a set of specific implementation choices. Let’s walk through it, starting with the first thread the orchestrator creates. As part of the dispatch, the orchestrator specifies a concrete task and assigns it to a new thread . The orchestrator is prompted to keep the task bounded, but its scope is not enforced by the runtime. The dispatch then starts a worker , which is a fresh process and model context with the worker system prompt, the requested action, its tools, and any applicable project or skill instructions. There is no separate summarization pass: the worker system prompt instead specifies that the model’s final response should be a concise handoff for future work called an episode . The worker makes model calls and uses tools until the model returns a response with no tool calls, which is treated as the episode. At this point, the worker’s execution context is discarded and never used as model context by the system again . Its changes to the environment remain, but the episode is the persistent representation of the work. It is stored in the thread, which is simply a named, ordered collection of episodes.

A fresh worker receives the requested action, the target thread’s retained history, and selected source episodes. When it finishes, only its new episode and changes to the environment remain. The next time the orchestrator assigns that thread a new task, nac creates a new worker with a fresh context. That worker receives the system prompt, the requested action, and all the episodes already stored in the thread. Furthermore, the orchestrator can supply episodes from other threads as context, an idea Slate describes as part of thread weaving . Nac implements this by resolving each named source thread to its most recent retained episode. Those source episodes are used as context for that action but do not become part of the target thread; only the episode produced by the new worker is added when the worker finishes. Nac then proceeds through a series of alternating steps between orchestrator planning and thread execution. While planning, the orchestrator can query thread names and retained episodes at any time. When it chooses to dispatch work, it ends its turn by outputting a batch of thread calls, each with the following specification: name — The target thread. NAC creates it if it is new or reuses its retained episode history if it already exists. action — The free-form instruction for the worker, intended to describe one bounded action. threads (optional) — Source threads whose latest retained episodes should be supplied to the worker. A same-batch source creates a dependency edge. skills (optional) — Skills to preload into the worker’s context. timeout (optional) — A time limit for the worker’s execution.

Implicitly, this defines a graph over the thread calls in the current batch. A source thread dispatched in that batch must execute its assigned work before the specified target thread; a previously completed source only supplies context. Nac rejects duplicate targets and validates that the graph is acyclic before execution begins. If it is not, nac rejects the batch and returns...