> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aui.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Changelog

> Latest updates, new features, and API changes.

## September 2026

<Steps>
  <Step title="Sep — Traces for every agent, and inline with the reply">
    **Messaging API** · **Management API** · **SDK** `3.4.0`

    The trace endpoints now answer for agents on the current runtime, not only
    [runtime v1 agents](/sdk/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](/api/messaging/traces) — including how to
    [show sources to end users](/api/messaging/traces#show-sources-to-end-users)
    — or try it with your own keys in the
    [Apollo Agent Tester](https://external-apis-tester.aui.io).
  </Step>

  <Step title="Sep — Apollo CLI: the official command line for Apollo agents">
    **CLI** `stable` · `@aui.io/apollo`

    The 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](/cli/installation).
  </Step>
</Steps>

## August 2026

<Steps>
  <Step title="Aug — runtime v2 support across the API and SDK">
    **API** · **SDK**

    Agents 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](/sdk/overview#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](/sdk/runtime-v1-agents) for the frame-by-frame
      mapping.
    * Sends accept an optional `runtime_version` build pin (advanced; normally
      omit).
  </Step>

  <Step title="Aug — SDK 3.3.5: list filters, fixed and flattened">
    **SDK** `breaking`

    Management 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.
  </Step>

  <Step title="Aug — API: choose the sender number on channel threads">
    **API** · **SDK**

    `POST /messaging/v1/channels/{channel}/threads` now accepts an optional
    `sender_id` — the MongoDB ObjectId of a sender you connected in the
    [Playground](https://apollo.aui.io). 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](/api/messaging/channels) and the
    [SDK messaging client](/sdk/messaging#channels-whatsapp-and-sms).
  </Step>
</Steps>

## July 2026

<Steps>
  <Step title="Jul — API: structured card data (json_data)">
    **API** `breaking`

    Agent 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](/api/messaging/send-messages#cards).
  </Step>

  <Step title="Jul — API: agent version on thread lists">
    **API**

    `GET /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](/api/management/threads).
  </Step>

  <Step title="Jul — API: new base URL">
    **API** `breaking`

    The 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.
  </Step>

  <Step title="Jul — API: agent_id removed from messaging request bodies">
    **API** `breaking`

    Your 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](/api/messaging/send-messages).
  </Step>

  <Step title="Jul — API: channel thread initiation (WhatsApp / SMS)">
    **API** `breaking`

    The `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](/api/messaging/channels).
  </Step>

  <Step title="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](/sdk/migration).
  </Step>

  <Step title="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.
  </Step>
</Steps>

## March 2026

<Steps>
  <Step title="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
  </Step>
</Steps>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.