CoreWeave explains how ARIA, its W&B research agent, was built to outlast the chat

Starting from context, ending with artifacts

CoreWeave says the original idea was to place a capable, tool-using agent inside W&B, where Runs, metrics, artifacts and production traces already live. The team expected context to be the main advantage, since a researcher should not have to copy half a project into a prompt before an agent can help.

The post describes a typical case: a training run has become slower, and the researcher already has a filtered workspace, several suspicious Runs selected and a metric that changed after a configuration update. A general assistant would need all of that pasted in. According to CoreWeave, ARIA starts from the W&B context around the question. It can inspect experiment data and production traces, follow evidence across Runs, and create a workspace or report that keeps the finding next to the supporting data.

That persistence changed the team's view of what a good answer is. A paragraph that disappears with the conversation is hard to review and of little use to a teammate who was not there. A report can be shared, and a workspace can keep updating as new Runs arrive. The author writes that the artifacts "became part of the answer" rather than a nicer way to present it, so another researcher can disagree with a conclusion and continue from the same evidence.

Authority stays with the researcher

Working inside W&B also forced the team to define what the agent may do on its own. CoreWeave separates three kinds of step: reading selected Runs is part of an investigation, creating a report changes a shared project, and launching an experiment spends real compute.

ARIA can handle the tedious work around those decisions, including preparing a follow-up experiment. But in the post's words, "the model sounding confident cannot be the thing that grants it more permission." Researchers still approve consequential actions, and the loop from observing a result to starting the next experiment closes only when a researcher approves.

Durable Turns and a split architecture

The first agent loop was simple: receive a request, choose a tool, inspect the result and continue until there is an answer. A harness assembled the prompt and project context, exposed the allowed tools, kept the history and enforced limits. Real investigations made this untidy. A question such as why runs got slower can depend on the page being viewed, its filters, a specific metric and an artifact from an earlier experiment. CoreWeave turned that page state into structured context, while keeping the limitation explicit: a filtered page is a useful starting point, not proof that the agent has seen the whole project.

Jobs also grew longer. ARIA might inspect hundreds of Runs, generate a visualization, wait for remote work, recover from a failed tool call or keep going after the researcher closes the browser. The production service therefore stores each user request and the agent work that follows as a durable Turn. According to CoreWeave, a Turn includes:

• the prompt and reconstructable history
• the configured agent and environment
• the state needed to continue

Turns form a tree, so a researcher can return to an earlier point and take the work in another direction. A worker claims a Turn and records progress, and the active work runs in an isolated sandbox whose files and state can be snapshotted and restored. As the post puts it, "Closing the browser removes the viewer, not the work."

Responsibilities were split deliberately. The ARIA service owns authorization, persistence, dispatch and progress. The agent decides what to do next, the environment exposes state and tools, and the sandbox isolates execution. A shared driver coordinates one Turn across these pieces. CoreWeave says this gave failures a clearer address: a wrong tool choice points to agent behavior, lost worker state points to recovery, and a sandbox that fails before the task begins is not counted as an incorrect answer.

Turning production failures into evaluations

The team's first approach to failures was to read the trace and write a cleaner evaluation task. CoreWeave says that often removed the reason the failure happened, because page context, earlier turns or environment state were lost. The result was a test of a simplified story rather than of what users experienced.

The durable Turn offered a better starting point, since it already holds the request, history, configuration and a reference to restorable state. The same driver used by the production worker can run a controlled task offline, which keeps the evaluated candidate close to the version that could ship rather than a benchmark-only variant.

Two other W&B pieces support this. Weave, the company's observability and evaluation system for agents and LLM applications, records agent operations as Calls and connects them into traces. That lets the team follow an evaluation result down to the model and tool calls behind it. W&B Agent Factory, or WBAF, provides the ARIA-specific research environment: it imports a production-aligned ARIA configuration and runs the tasks, environments and scorers needed to test a proposed change. The ARIA service remains the production source of truth, and a change that looks good still goes through normal production review. WBAF does not ship a second ARIA.

What it means for users

For W&B users, the post points to an agent whose output is meant to be inspected, shared and continued by colleagues, with approval required before shared projects change or compute is spent. Long investigations are designed to survive a closed browser tab.

CoreWeave also names a limit. It can preserve conversation and sandbox state, but the surrounding W&B project keeps changing: new Runs arrive, artifacts move and services return different data. A replayed Turn therefore cannot fully freeze the world around it.