Skip to main content

​
September 2026

1

Sep — Traces for every agent, and inline with the reply

Messaging API · Management API · SDK 3.4.0The trace endpoints now answer for agents on the current runtime, not only runtime v1 agents:
  • One Trace, two shapes — every trace carries runtime ("v1" or "v2"). A runtime v2 trace is the runtime’s own turn trace, published as typed sections: what it understood and learned, the sources it read, the passages and citations the reply provably used (passages_used, citations_used), the policies it decided, the checks it passed, and a plain-language narrative.
  • Inline with the reply — set include_trace: true on a send, stream, or rerun and the reply carries message.trace_info; no second request.
  • Reading one runtime v2 interaction — pass the thread as well: GET /interactions/{interactionId}/trace?thread_id=… (interactionTrace(id, { thread_id }) in the SDK). Runtime v1 interactions are read by their id alone, as before.
  • Unchanged for runtime v1 agents — the same fields as before, plus runtime: "v1".
  • In the SDK (3.4.0) — Trace is now a discriminated union of RuntimeV1Trace / RuntimeV2Trace (narrow on runtime), with typed section types (RuntimeTraceFact, RuntimeTracePassage, …); include_trace on sendMessage / streamMessage / rerun; Message.trace_info; interactionTrace(id, { thread_id }) and threads.getInteractionTrace(id, { thread_id }). No other method changed.
  • Scoped to your agent — a thread of another agent answers 404 not_found on both trace endpoints.
See Traces — including how to show sources to end users — or try it with your own keys in the Apollo Agent Tester.
2

Sep — Apollo CLI: the official command line for Apollo agents

CLI stable · @aui.io/apolloThe Apollo CLI is the operator console for Apollo agents — a scriptable CLI (apollo <command>) and a full-screen terminal TUI (bare apollo) in one npm install:
  • Local-first authoring — agents check out as typed YAML programs (bundle/src/) with JSON Schemas, coding-agent skill packs, and the runtime’s AGENTS.md; validate, diff, pull, and push complete the loop.
  • Runtime testing — apollo chat talks to the live runtime, including unpushed local edits via --local ., with the full decision trace via --trace; apollo thread inspects conversations.
  • Server-side authoring — apollo advise answers grounded questions over your checkout, apollo build runs gated build turns, and apollo evaluate runs the live evaluation suite (simulated callers plus a judge).
  • Versions, knowledge, and secrets — full version lifecycle (version publish is also rollback), knowledge hubs (apollo kb), vault secrets (apollo vault), and a per-agent mock database (apollo mockdb).
  • Built for coding agents — every command is non-interactive with a stable --json envelope and predictable exit codes.
Get started: Installation.

​
August 2026

1

Aug — runtime v2 support across the API and SDK

API · SDKAgents can now run on runtime v2 — the current, streaming-first generation (its threads have UUID ids). Agents created before August 1 2026 stay on runtime v1. Sending is unchanged and routes automatically; the differences surface in a few places:
  • Thread reads (transcripts, get/rename/list) take a runtime_version selector — pass the runtime version the agent runs on (e.g. 0.8.0). See Threads and runtime versions.
  • SSE streams can end with a new suggestions event carrying ready-made follow-up prompts (followup_suggestions, with the thread_id and interaction_id they belong to).
  • Cards carry new optional metadata: title, capability (which agent capability produced the card), and instance (the record it’s about).
  • Streaming is over SSE — one HTTP call per turn, resumable with Last-Event-ID. WebSocket sessions stay with runtime v1; see Runtime v1 agents for the frame-by-frame mapping.
  • Sends accept an optional runtime_version build pin (advanced; normally omit).
2

Aug — SDK 3.3.5: list filters, fixed and flattened

SDK breakingManagement list methods now take their filter fields directly on the request — drop the filters: { … } wrapper (listThreads({ project_id }), listAgents(projectId, { name }), listVersions(agentId, { status })). The TypeScript compiler points at every call site.This also fixes a bug where list filters were silently not applied on the wire in 3.3.4 and earlier — from 3.3.5 they filter reliably. Requests from older SDK versions keep behaving exactly as they did.
3

Aug — API: choose the sender number on channel threads

API · SDKPOST /messaging/v1/channels/{channel}/threads now accepts an optional sender_id — the MongoDB ObjectId of a sender you connected in the Playground. Pass it to start the conversation from that connected number. Omit it to keep using the platform default sender.phone_number remains the recipient. When a specific sender is used, the response includes from so you can confirm which connected number sent the opener.See Channels and the SDK messaging client.

​
July 2026

1

Jul — API: structured card data (json_data)

API breakingAgent reply cards now carry the entity in two self-contained representations: rendered_jsx (unchanged — a ready-to-render JSX string for React UIs) and the new json_data — the same card as structured JSON, so you can build your own card UI in any framework (Vue, Angular, mobile).json_data.entity is a flat key–value map of the card’s fields, and json_data.sub_entities holds nested groups such as product variants.The card’s previous name, category, and parameters fields were removed — everything you need to render is in json_data.See Cards.
2

Jul — API: agent version on thread lists

APIGET /management/v1/threads items now include version_tag — the agent version the conversation ran on. Use it to tell which release of your agent handled each thread when filtering or auditing conversations.See Management → Threads.
3

Jul — API: new base URL

API breakingThe API base URL changed from https://api-v3.aui.io/apollo-api-v2 to https://api-v3.aui.io/apollo-api. All paths under it are unchanged (e.g. POST /messaging/v1/messages, POST /management/v1/auth/token).The old base URL keeps working for a few more days to give you time to migrate, and will then be removed — switch to the new one now.
4

Jul — API: agent_id removed from messaging request bodies

API breakingYour agent is now identified by your access token: when you exchange a publishable key at POST /management/v1/auth/token, the resulting token already carries the agent. Sending agent_id in the body of POST /messaging/v1/messages, POST /messaging/v1/messages/stream, or POST /messaging/v1/threads/{threadId}/rerun is no longer accepted and returns a validation error (422).Migration: remove agent_id from your messaging request bodies — responses keep the same shape. See Send messages.
5

Jul — API: channel thread initiation (WhatsApp / SMS)

API breakingThe POST /messaging/v1/channels/{channel}/threads request body changed:
  • agent_id was removed — the agent now comes from your access token.
  • user_ref_id was renamed to user_id.
  • template_id and content_variables (WhatsApp template overrides) were removed — the agent’s configured template is always used; agent_display_name remains available.
See Channels.
6

Jul — SDK v3: new clients for the Apollo API

SDK breaking · v3.2@aui.io/aui-client v3 is a full rewrite against the Apollo API. The single ApolloClient is replaced by two clients, one per credential:
  • ApolloMessagingClient — publishable key, browser-safe. Token exchange and refresh are handled internally; the agent comes from the key, not request bodies. Messaging, channels, and WebSocket sessions.
  • ApolloManagementClient — organization API key, server-side only. Projects, agents, versions, threads, and usage.
Tasks are now threads: createTask is gone (threads auto-create on the first sendMessage), task_id became thread_id, and the client defaults to the production API with no environment configuration. See the SDK upgrade guide.
7

Jul — API: threads, agent variables, welcome message & follow-up suggestions

API new
  • Update a thread — PATCH /management/v1/threads/{threadId} renames a thread (title); the full updated thread is returned.
  • Agent variables — POST /messaging/v1/messages and POST /messaging/v1/messages/stream accept an optional agent_variables object (static and dynamic) with per-message values for the agent’s configured context variables.
  • Welcome message — GET /messaging/v1/welcome-message returns your agent’s configured greeting, for opening a conversation UI before the first message.
  • Follow-up suggestions — POST /messaging/v1/followup-suggestions generates suggested next prompts from a context you provide.

​
March 2026

1

Mar 9 — Agent Builder API Alpha

Agent Builder API alpha · Closed to the public
  • Alpha release of the Agent Builder API — available to select partners only
  • Identity, organizations, accounts, and networks (agents) endpoints
  • Agent settings read/write: tools, parameters, entities, integrations, rules
  • Knowledge base management with file upload and website scraping
  • API Workflow integration generator