Working with Runloop's Axons: Introducing Remote Agent SDK

Overwhelmingly we hear the same set of frustrations from teams building real agents:

• Agents and infrastructure live in two separate, parallel worlds
• Sometimes agents need to start up, use some resources, then pause until they receive input. Currently the burden is on you to create scaffolding to do this.
• Agents feel powerful in isolation, but they're hard to trust and to scale beyond demos
• When agents get stuck or fail there's no way to recover
• Costs spiral when systems sit idle

Today, we are announcing the general availability of the Remote Agents SDK (accessible via the @runloop/remote-agents-sdk package). This SDK is the easiest way to put production agent infrastructure to work. The SDK is built on top of our new core infrastructure primitives, Axons, a persistent event stream, and Broker, the runtime bridge that unifies every agent session with the hardware that runs it. For teams moving beyond demos, this SDK provides the tools to manage long-lived, stateful agent sessions with confidence. Through the SDK, you get access to Axon's core capabilities, including:

• Full visibility into every infrastructure and agent action through one pane of glass
• Session management and replay out of the box

Agents have become very good at generation. The harder problem is operating them with confidence once they touch real systems, real users, and real workloads. Axon and Broker address that gap by making agent execution visible, replayable, and easier to control.

‍

The Problem: Two Control Planes That Never Meet

Today, every team ends up building the same fragile architecture:

• Agents operate in one layer (prompting, reasoning, file management, tool use)
• Infrastructure operates in another (containers, sessions, compute)  
• The glue between them is custom, inconsistent, and leads to a fragmented smattering of half-solutions.

The result:

• No single source of truth for what happened  
• Debugging requires stitching together logs, traces, and guesswork  
• Session state is fragile and often lost  
• Lifecycle management becomes bespoke infrastructure 
• Agents get stuck using ancient models until they become unsupported and the whole thing breaks down

Essentially, agents feel powerful in isolation but prove unreliable in production.

A unified stream for every agent and Devbox event

Axons change this model. Axons are highly scalable, low-latency event streams that unify Devbox events and agent actions in one place.

Instead of stitching together logs, transient callbacks, and ad-hoc state, you get one append-only stream for session activity. Events are ordered with monotonic sequence numbers, which makes it easier to reason about what happened and in what order.

That visibility is especially important for trust. Rather than treating agent behavior like a black box, teams can stream and inspect sandbox and agent events as they happen, then reconnect to the same session later and replay what occurred. If something goes wrong, you don't just get an error message; you know when it happened and everything that lead up to the error.

Persistent, recoverable sessions also reduce operational friction. If a workflow pauses, a service restarts, or a handoff is needed, the session doesn’t have to be rebuilt from scratch.

Here’s a minimal TypeScript example using the current Axon SDK pattern shown in the Runloop docs:

import { RunloopSDK } from '@runloop/api-client';
import { ACPAxonConnection, PROTOCOL_VERSION } from '@runloop/remote-agents-sdk/acp';

async function main() {
  const sdk = new RunloopSDK({
    bearerToken: process.env.RUNLOOP_API_KEY,
  });
  const axon = await sdk.axon.create({
    name: 'ga-announcement-demo',
  });
  const devbox = await sdk.devbox.create({
    name: 'ga-announcement-demo',
    blueprint_name: 'axon-agents',
    mounts: [
      {
        type: 'broker_mount',
        axon_id: axon.id,
        protocol: 'acp',
        agent_binary: 'opencode',
        launch_args: ['acp'],
      },
    ],
  });
  const conn = new ACPAxonConnection(axon, devbox, {
    onDisconnect: async () => {
      await devbox.shutdown();
    },
  });
  conn.onTimelineEvent((event) => {
    console.log(`Seq ${event.axonEvent.sequence}: [${event.kind}] ${event.axonEvent.event_type}`);
  });
  await conn.connect();
  await conn.initialize({
    protocolVersion: PROTOCOL_VERSION,
    clientInfo: {
      name: 'blog-demo',
      version: '0.1.0',
    },
  });
  const session = await conn.newSession({
    cwd: '/home/user',
    mcpServers: [],
  });
  await conn.prompt({
    sessionId: session.sessionId,
    prompt: [
      {
        type: 'text',
        text: 'Summarize the latest CI failure and suggest next steps.',
      },
    ],
  });
  await conn.disconnect();
}

main().catch((error) => {
  console.error(error);
  process.exit(1);
});

‍

This example focuses on the core model:

• Create an Axon
• Attach it to a Devbox via a broker_mount
• Use ACPAxonConnection to send turns to the agent
• Listen for agent responses using onTimelineEvent

For the latest event types, Broker behavior, and session patterns, consult the current Runloop Axons and Broker documentation.

Built for efficient, flexible agent operations

Axon and Broker are designed for real operational constraints, not just happy-path conversations.

One important capability is idle and wake policy support. Devboxes can suspend when they’re not in use and wake when work resumes, which helps teams run long-lived workflows without paying for continuously active infrastructure. In practice, that means cost tracks activity more closely.

Behind the scenes, Runloop's Axon Broker is what makes this operationally useful. It reads incoming events from the Axon stream and forwards them to agents running in Devboxes one turn at a time, then appends agent output back to the same stream. This removes a large amount of custom lifecycle code that teams would otherwise need to develop and maintain.

This model is flexible by design. Each session is anchored in the event stream rather than tightly bound to a single runtime choice, so teams can change the agent or model used over time without rebuilding the session architecture around each change.

The SDK provides comprehensive support for running agents powered by various models, including Claude Code and compatibility with other major model providers, including OpenAI, Gemini & Qwen via the ACP protocol.

At a high level, the workflow looks like this:

import { RunloopSDK } from "@runloop/api-client";
import {
  ACPAxonConnection,
  PROTOCOL_VERSION,
} from "@runloop/remote-agents-sdk/acp";

/**
 * Demonstrates suspend/resume and session persistence with Axon.
 *
 * The devbox will automatically suspend after 60s of idle time and wake
 * when a new event arrives. The session persists across suspend/wake cycles,
 * and afterSequence lets clients reconnect without replaying old events.
 */

async function main() {
  const sdk = new RunloopSDK({ bearerToken: process.env.RUNLOOP_API_KEY });

  // Create Axon and devbox with suspend-on-idle lifecycle policy
  const axon = await sdk.axon.create({ name: "stateful-agent-session" });
  const devbox = await sdk.devbox.create({
    name: "stateful-agent-session",
    blueprint_name: "axon-agents",
    mounts: [
      {
        type: "broker_mount",
        axon_id: axon.id,
        protocol: "acp",
        agent_binary: "opencode",
        launch_args: ["acp"],
      },
    ],
    launch_parameters: {
      lifecycle: {
        after_idle: {
          idle_time_seconds: 60,
          on_idle: "suspend",
        },
        resume_triggers: {
          axon_event: true,
        },
      },
    },
  });

  // Track the last sequence number for efficient reconnection
  let lastSequence: number | undefined;

  const conn = new ACPAxonConnection(axon, devbox);
  conn.onAxonEvent((event) => {
    lastSequence = event.sequence;
  });

  await conn.connect();
  await conn.initialize({
    protocolVersion: PROTOCOL_VERSION,
    clientInfo: { name: "blog-demo", version: "0.1.0" },
  });

  const session = await conn.newSession({ cwd: "/home/user", mcpServers: [] });
  console.log(`Session created: ${session.sessionId}`);

  await conn.prompt({
    sessionId: session.sessionId,
    prompt: [
      { type: "text", text: "Review the deployment plan for service A." },
    ],
  });

  console.log(`Last sequence: ${lastSequence}`);
  console.log(`Session ID: ${session.sessionId}`);

  // At this point, persist lastSequence and session.sessionId to your database.
  // The devbox will suspend after 60s of inactivity.
  // Later—minutes, hours, or days from now—resume like this:

  await conn.disconnect();

  // --- Resume from a new process or after time has passed ---

  await resumeSession(sdk, axon.id, devbox.id, session.sessionId, lastSequence);
}

async function resumeSession(
  sdk: RunloopSDK,
  axonId: string,
  devboxId: string,
  sessionId: string,
  afterSequence?: number,
) {
  // Retrieve the existing Axon and devbox by ID
  const axon = await sdk.axon.retrieve(axonId);
  const devbox = await sdk.devbox.retrieve(devboxId);

  // Connect with afterSequence to skip already-processed events.
  // If the devbox is suspended, this prompt will trigger a wake.
  const conn = new ACPAxonConnection(axon, devbox, { afterSequence });

  let lastSequence = afterSequence;
  conn.onAxonEvent((event) => {
    lastSequence = event.sequence;
  });

  await conn.connect();

  // Load the existing session instead of creating a new one
  await conn.loadSession({ sessionId });

  await conn.prompt({
    sessionId,
    prompt: [
      {
        type: "text",
        text: "Now re-check the plan with a stricter risk review.",
      },
    ],
  });

  console.log(`Resumed session complete. New last sequence: ${lastSequence}`);

  await conn.disconnect();
  await devbox.shutdown();
}

main().catch((error) => {
  console.error(error);
  process.exit(1);
});

This example intentionally stays high level. The key point is that the session persists even as execution pauses and resumes, and the orchestration layer can evolve without discarding the event history.

That combination supports:

• Long-running workflows
• Stateful execution across turns
• Cost-aware suspend-and-resume behavior
• Easier iteration on agent and model choices

Secure for real-world deployments

Production agent systems need more than good outputs. They need execution environments that can be controlled.

Axon and Broker support custom network policies and secure agent credential protection via Agent Gateway. This gives teams more control over what an agent environment can access. Sensitive credentials never even land on the box. Instead, the agent sees a token while work runs inside a Devbox.

All of this matters for enterprise deployment. In most real systems, trust depends on being able to answer three questions clearly:

• What did the agent do?
• What could it reach while doing it?
• How were credentials and sensitive resources protected?

Runloop’s approach is to combine isolation, observability, and policy controls instead of forcing teams to choose between them or develop something bespoke in-house. Teams can inspect the event lifecycle, constrain network access, and protect credentials in the same architecture. See the feature-examples in the SDK for a detailed guide on implementation with these advanced features.

For this announcement, the main takeaway is architectural: secure execution and full visibility should work together. They are both required for trusted agent operations. See the feature-examples in the Axon client for a detailed guide on implementation with these advanced features.

Where to go next

General availability means Axon and Broker are ready to serve as the foundation for observable, replayable, and production-ready agent systems on Runloop.

For current customers, this is the right time to standardize on an event-driven session model for agents and Devboxes. For teams evaluating agent infrastructure, the release is worth looking at if the main blockers are trust, debugging, lifecycle management, or operational cost.

Technical details, API surfaces, and implementation patterns will continue to evolve. Check out the latest Runloop documentation and SDK references to see the latest details:

• Axons documentation: https://docs.runloop.ai/
• Remote Agents SDK (@runloop/remote-agents-sdk) documentation: https://docs.runloop.ai/docs/remote-agents-sdk
• Runloop TypeScript SDK: https://github.com/runloopai/api-client-ts
• Runloop Python SDK: https://github.com/runloopai/api-client-python
• Runloop CLI: https://github.com/runloopai/rl-cli

Conclusion

Axon and Broker bring a missing layer to production agent systems: a secure, ordered, persistent stream of what happened, plus the runtime bridge that turns that stream into recoverable execution.

That makes agents easier to observe, easier to recover, and easier to trust. Explore the docs, try the SDKs - including the primary agent orchestration package, @runloop/remote-agents-sdk and reach out to Runloop to start building trusted agent workflows on top of Axon and Broker.