unreal-agent: Unreal Agent: the Go harness that makes AI tool calls behave like durable jobs

An async-first agent runtime that survives hangs, replays state, and forks sessions without losing the thread.

8 min read • View on GitHub • More from unreallabsai

A wide black-ink editorial scene showing a central mechanical scheduler feeding separate tool jobs in transparent boxes while a control room keeps receiving new inputs. The image explains Unreal Agent’s core idea: the agent can keep moving while long-running work stays in flight. — Unreal Agent treats tool execution like durable work, not a blocking call.

Key Takeaways

Unreal Agent’s main trick is not better prompting, but turning tool calls into durable operations that can keep running while the coordinator stays responsive.
Its session log is the product, because replay, resume, and fork make agent behavior inspectable instead of ephemeral.
The repository feels closer to a job runner or runtime kernel than a classic Python agent framework, which is why Go fits it so well.
The project’s niche is durable execution, not agent composition, and that changes what it is competing with.

The problem: agents that stall, poll, and forget

Most agent loops are built like a phone call. Ask the model to do something, wait, get an answer, repeat. That works until a tool takes a while, a subprocess hangs, or the session crashes halfway through. Then the agent turns into a token-burning waiter with a bad memory.

Unreal Agent is built to avoid that failure mode. It treats long-running tool work as something the system can track, resume, and inspect, instead of something the model has to babysit with heartbeats and status pings.

System	Tool execution model	Crash recovery	Session replay / fork	Complexity	Best use case
Unreal Agent	Async durable operations	Replay from session log	Built in	Moderate	Long-running agent sessions and tool-heavy workflows
Synchronous agent loop	Blocking function calls	Manual or brittle	Usually absent	Low	Simple demos and short tasks
Heavier orchestration framework	Graph or workflow steps	Often supported	Sometimes supported	High	Enterprise workflows with many stages
Coding agent harnesses	Usually turn-based waiting	Limited	Varies	Moderate	Interactive coding assistants

Unreal Agent’s core move: tool calls become durable operations

The repo’s key idea is simple to say and easy to underestimate. A tool call is not just a function that returns. It becomes an operation with state, and that state lives outside the model turn.

The durable loop is the project’s real differentiator. Tool work can keep running while the coordinator stays alive, and session history can be replayed or forked later.

A close-up black-ink illustration of an append-only ledger on a desk, where one session line splits into two paths like a forked river. The image explains replay, resume, and fork as visible branches in a persisted history. — The session log is not an implementation detail. It is how the agent stays debuggable and forkable.

That is why the harness feels different from a typical agent framework. The model can keep thinking while work is in flight, and the system keeps enough history to answer the questions production teams actually ask: What happened? What failed? Can I replay it? Can I branch from here?

The coordinator is a traffic cop, not a monolith

The coordinator in harness/coordinator/ is the part that makes the whole thing feel alive. It multiplexes inbox input, LLM responses, and operation updates through a single event loop, so the runtime stays responsive even when tool work is slow.

The interesting bit is not just concurrency for its own sake. It is that the loop keeps side effects contained while state transitions remain visible. That split is what lets Unreal Agent keep moving without turning into an unreadable tangle of callbacks.

for {
    select {
    case input := <-inbox.Ch:
        handleInput(input)
    case resp := <-llmResponses:
        handleModelResponse(resp)
    case update := <-operationUpdates:
        handleOperationUpdate(update)
    case <-ctx.Done():
        return ctx.Err()
    }
}

The session store is the real product

The session store is where Unreal Agent stops being a runner and starts looking like an execution log. The history is append-only JSONL, and each item records a meaningful step: input, turn, model response, fork, or tool status.

Capability	What it means	Why it matters
Append-only history	Every event is recorded in order	You can inspect the full chain of reasoning and action
ToolCallStatus	Tool work is persisted as state	Long-running jobs survive crashes and restarts
Resume	Replay the log after failure	The agent does not lose the thread
Fork	Branch from a prior point	You can debug alternate paths without starting over

That design matters more than it first appears. Once the session is a log, debugging becomes replay, and experimentation becomes branching. The harness stops behaving like a black box and starts behaving like a versioned system.

Unreal Agent manages tool calls in a completely asynchronous way, relieving the underlying model of the need to manage waits, polls, and heartbeats for tools.

Unreal Labs, Project Author/Maintainer · Unreal Labs - Unreal Agent Announcement

Why the pure context builder matters

A subtle strength in the repo is the clean boundary around context assembly. The context builder is pure logic, which means prompt generation can be tested without side effects, process state, or live network calls.

That separation sounds ordinary. In practice, it is what keeps a runtime maintainable. The code that decides what the model sees is not tangled up with the code that runs tools or persists history.

Why Go is the right bet here

This is one of those projects where Go looks less like a preference and more like an operating constraint. The harness needs concurrency, process control, low-level OS interaction, and long-lived services that stay predictable under load.

Go’s concurrency model fits a coordinator that must juggle inputs, model turns, and operations at once.
The runtime benefits from low-level process and file handling without pulling in a heavy framework stack.
A smaller dependency surface makes the harness easier to trust when it is responsible for durable execution.
The code reads like infrastructure, not like a notebook turned into a product.

Python still dominates agent frameworks because it is fast to prototype in. Unreal Agent is aiming at a different layer of the stack: the place where responsiveness, durability, and reproducibility matter more than API convenience.

What to compare it with

Unreal Agent sits in a narrow but useful slot. It is not trying to be a full workflow platform, and it is not just a wrapper around model calls. It is a durable execution harness for agentic work.

System	Strength	Weakness	Why Unreal Agent stands apart
LangChain or CrewAI style loops	Fast to assemble	Often synchronous and chatty	Unreal Agent is built around durable tool execution, not prompt choreography
Enterprise graph orchestration	Powerful workflow control	Heavier abstraction and more ceremony	Unreal Agent stays close to the runtime layer
Proprietary coding agent harnesses	Tight product integration	Opaque internals	Unreal Agent exposes the execution log and forkable state
Simple agent scripts	Easy to understand	Break under long-running work	Unreal Agent is designed for hangs, crashes, and replay

That comparison makes the niche obvious. If you want composition, there are richer frameworks. If you want a durable job system for agent turns, Unreal Agent is aiming directly at that problem.

Origin and maintainers

Unreal Agent comes from Unreal Labs, and the repo’s shape suggests a team that cares about infrastructure discipline. The directory layout is deliberate, the test surface is broad, and the runtime pieces are separated from the pure logic pieces with care.

The project also reads like something built by people who have seen enough production systems fail in annoying ways to know where the real pain lives. That is the sort of background that matters here, because this is not a demo framework. It is an attempt at an agent runtime that can be reasoned about after something goes wrong.