What Is ARIA, and How Did We Build It?

What Is ARIA, and How Did We Build It?

Announcement

Webinar

Podcast

GTC 2026

Three-time Platinum. Still the only one. CoreWeave earns SemiAnalysis’ highest ClusterMAX™ rating for the third consecutive time. Read more ‍

Infrastructure

CoreWeave Forge

Solutions

Resources

Log in

| Sign up Contact us

Contact us

Clear

ARIA's chat panel beside a pinned workspace section of activation charts it created and verified, comparing training runs.

Originally published on the Weights & Biases by CoreWeave blog on September 25, 2026. When we released ARIA in public preview on June 29, 2026, the obvious thing to show was the agent chat experience: ask a question about your experiments, watch it inspect the evidence, and get an answer. Chat is where ARIA lives, but it is not the part that really shows off what ARIA does. We began with a fairly normal idea: put a capable, tool-using agent inside W&B, where the Runs, metrics, artifacts, and production traces already live. We thought the main advantage would be context. A researcher should not have to copy half a project into a prompt before an agent can help. Context did matter. But once ARIA started doing useful research, the harder questions changed. Could the work survive after the chat closed? Could another person inspect the evidence? Could a long investigation recover from failure? Could the agent take an action without quietly taking authority from the researcher? And when ARIA got something wrong, could we turn that failure into a better version of the product? The product grew around those questions. What we built is still an agent inside W&B, but it is better understood as a research process that begins in a conversation. We started with context Imagine opening a W&B project because a training run has become slower. You already have a filtered workspace, a few suspicious Runs selected, and a metric that changed after the last configuration update. You ask what happened. A general assistant sees the sentence. Before it can help, you need to describe the project, paste in the relevant metrics, explain the filters, and decide which artifacts fit in the prompt. You are halfway through the investigation before the investigation starts. 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 beside the data that supports it. If the next useful step is another experiment, ARIA can prepare that work and ask the researcher to approve the launch.

Figure 1. ARIA created and verified a pinned workspace section while the researcher could inspect the resulting charts beside the conversation. Image from the official ARIA launch report . The persistent output changed our idea of a good answer. A polished paragraph that disappears with the conversation is difficult to review and almost useless to a teammate who was not there. A report can be shared. A workspace can keep updating as new Runs arrive. Another researcher can open either one, disagree with the conclusion, and continue from the same evidence instead of reconstructing the work from screenshots. I had initially thought of those artifacts as a nicer way to present the answer. In practice, they became part of the answer. The conversation is where the researcher asks for help; the durable artifact is where the research becomes useful to the rest of the team. Working inside W&B also forced us to be clearer about authority. Reading selected Runs is part of an investigation. Creating a report changes a shared project. Launching an experiment spends real compute. ARIA can do the tedious work around those decisions, but the model sounding confident cannot be the thing that grants it more permission. Researchers still approve consequential actions.

Figure 2. ARIA shortens the work between observing a result and starting the next experiment. The loop closes only when a researcher approves the action. Adapted from CoreWeave's AI Loop . The research outgrew the chat The first version of the agent loop was easy to picture. ARIA received a request, chose a tool, inspected the result, and continued until it had an answer. A harness assembled the prompt and project context, exposed the allowed tools, kept the conversation history, and enforced limits. Real investigations made that loop much less tidy. A question such as “why did these runs get slower?” may depend on the page the researcher was viewing, the filters applied to it, a particular metric, and an artifact produced by an earlier experiment. We turned that page state into structured context so ARIA could tell where it came from and what the researcher had selected. We also kept the limitation explicit: a filtered page is a useful starting point, not proof that the agent has seen the whole project. Then the jobs became longer. ARIA might inspect hundreds of Runs, generate a visualization, wait for remote work, recover from a failed tool call, or continue after the researcher closes the browser. Once an investigation could outlive the browser session, we needed somewhere durable to store the work and a worker that could resume it. The production ARIA service stores one user request and the agent work that follows as a durable Turn . A Turn includes the prompt, reconstructable history, the configured agent and environment, and the state needed to continue. Turns form a tree, which lets a researcher return to an earlier point and take the work in another direction. A worker claims a Turn and records its progress. The active work runs in an isolated sandbox whose files and state can be snapshotted and restored. None of this is the glamorous part of an agent demo. It is the part that determines whether the demo can become a product. Conversation history helped ARIA pick up the thread, but the service still had to persist the work and recover it when something failed. The browser could show progress, but it could not be responsible for scheduling the job or keeping it alive after the tab closed. As those responsibilities accumulated, we split them deliberately. The ARIA service owns authorization, persistence, dispatch, and progress. The agent decides what to do next. The environment exposes state and tools. The sandbox isolates execution. A shared driver coordinates one Turn across those pieces.

Figure 3. The same investigation gains structured page context, a durable Turn, resumable execution,...