Proposal: support interactive clients for AX

[barneysspeedshop]

We are building Rope Notes, a local-first editor with an embedded coding agent. We would like Rope Notes to use AX as an optional remote execution backend.

Rope Notes would remain responsible for the user-facing session:

• Conversation history and branching
• Local files and unsaved editor buffers
• Permission policy and approval UI
• Reviewing and applying proposed changes
• Local recovery and session transfer

AX would be responsible for remote execution:

• Workspace preparation
• Sandboxed compute
• Task scheduling
• Suspend and resume
• Resource limits
• Remote process lifecycle

The intended flow is:

Rope Notes creates an AX Workspace and Task
        ↓
AX runs the agent in an isolated remote workspace
        ↓
Rope Notes watches the run and handles user interactions
        ↓
AX returns patches, files, logs, and other artifacts
        ↓
Rope Notes reviews and applies the changes locally

AX already provides much of the execution layer through Task, Workspace, WatchTask, SuspendTask, and ResumeTask.

We think three additional contracts would make AX usable by interactive clients such as Rope Notes.

1. Durable interactions

A task needs a standard way to request approval, review, or user input.

The interaction must survive task suspension, runner restarts, and client disconnection. Resolving it must be idempotent so that a retried request cannot approve an action twice.

2. Replayable task events

An interactive client needs more than current task snapshots. It needs an ordered event stream for output, tool activity, interactions, recovery, and completion.

A client should be able to reconnect with a cursor such as after_sequence and receive the events it missed.

3. Task artifacts

A remote task needs a standard way to return results that do not belong in task status. Examples include:

• Patches and change sets
• Generated files
• Logs and test reports
• Diagnostic output
• Model or tool traces

AX could expose typed artifact references while allowing external storage providers to hold the data.

Why these contracts belong together

Together, these contracts let a client supervise an AX task without sharing a live filesystem or keeping the client connected:

events tell the client what happened
interactions let the client respond
artifacts carry the resulting work

They would also help web consoles, IDE extensions, CI systems, and other agent clients. None of the contracts need to define an agent framework, conversation format, or tool-call schema.

Suggested sequence

We would propose and implement these as separate changes:

1. Durable task interactions and idempotent resolution
2. Replayable task events with sequence cursors
3. Artifact references and retrieval

Before preparing detailed schemas, we would like feedback on the architectural boundary:

• Does AX intend to support interactive external clients?
• Should these capabilities live in the AX control plane, the runner contract, or a companion service?
• Is there an existing design direction we should follow?
• Would the maintainers accept separate proposals and prototypes for these three contracts?

We can contribute implementation experience from a working local agent system and prepare focused prototypes after agreeing on ownership and scope.