Agents API could be one backend behind our replaceable fleet adapter. It supplies the Codex session/tool loop; our controller keeps bus routing and run records. Separate the harness driver from the compute provider, so AX need not be tied to one agent.
Agents API in the existing fleet architecture
Yesterday's controller boundary keeps human work in discussions and optional GitHub Issues. The controller records technical delivery, runs, cancellation, and reply routing. This remains the proposed boundary.
| Component | Proposed mapping |
|---|---|
| Communication bus | Keep its replaceable driver and thread identities. |
| Controller | Translate authorized events to agent input and agent events to replies. |
| Agent harness | Native CLI/ACP launcher for existing agents; a separate Agents API driver for managed Codex sessions. |
| Compute provider | AX or another environment provider, independently selected where supported. |
| Reusable knowledge | Keep repository evidence and agent memory distinct, as in the state model. |
OpenAI hosts the harness; self-hosted execution runs its executor. Proposed refinement: distinguish the harness driver from the environment provider within the existing adapter. This does not require another resident service.
Running the executor in an AX Task is an integration to test, not a verified connector. See the earlier launcher design.