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

# Agentic Framework

> Updates and improvements to Corti Agentic Framework

Detailed documentation about the Agentic Framework is available [here](/agentic/overview).

<Update label="2026-07-21" tags={["API", "Feedback"]}>
  #### Feedback API

  Collect ratings, labels, and reasons on task results. Build thumbs-up/down UIs, case-review workflows, and automated evaluation pipelines directly on agent tasks.

  * `POST /v2/agentic/contexts/{contextId}/tasks/{taskId}/feedback` — submit a binary rating, up to five labels (`correct`, `helpful`, `incorrect`, `missingInformation`, etc.), and an optional reason
  * `GET /v2/agentic/contexts/{contextId}/tasks/{taskId}/feedback` — list the caller's feedback for a task, newest first
  * `DELETE /v2/agentic/contexts/{contextId}/tasks/{taskId}/feedback` — remove all feedback the caller submitted (idempotent)

  Target a specific message with `target.messageId`. Track provenance with metadata fields for collection method, client reference, and a pseudonymous actor ID.

  Read the guide: [Submit feedback on tasks](/agentic/guides/submit-feedback).
</Update>

<Update label="2026-07-21" tags={["API", "Tracing"]}>
  #### OpenInference trace export

  Export execution traces for any context in the [OpenInference](https://github.com/Arize-ai/openinference) format. See which connectors were called, how many tokens were consumed, what inputs were sent, and how long each step took.

  * `GET /v2/agentic/contexts/{contextId}/trace` — returns traces and their spans, newest first, with pagination via `pageSize` and `pageToken`

  Feed traces into any OpenInference-compatible observability platform to debug agent behavior, audit clinical workflows, and optimize connector usage.

  Read the guide: [Export OpenInference traces](/agentic/guides/export-traces).
</Update>

<Update label="2026-07-20" tags={["Connectors", "API"]}>
  #### Schema connectors GA

  Define a custom tool with a JSON Schema. No server, no MCP, no remote agent — just a schema on the agent.

  The LLM uses the schema's `name` and `description` to decide when to call it. Set `transition: "complete"` to stop the agent loop after the tool fires — perfect for structured-output agents that must return a coded diagnosis, a confidence score, or a filled-in form.

  ```json theme={null}
  {
    "type": "schema",
    "name": "submit_code",
    "description": "Submit the final ICD-10 code with a confidence score.",
    "transition": "complete",
    "schema": {
      "type": "object",
      "properties": {
        "code": { "type": "string" },
        "confidence": { "type": "number", "minimum": 0, "maximum": 1 }
      },
      "required": ["code"]
    }
  }
  ```

  See [Connectors](/agentic/connectors#schema-connectors).
</Update>

<Update label="2026-07-17" tags={["A2A", "Reliability"]}>
  #### A2A runtime reliability

  Three server-side improvements, no client changes required:

  * **Stuck tasks auto-killed** — tasks that go silent are terminated automatically, freeing resources and unblocking workflows
  * **Burst traffic handled** — a configurable concurrency cap per agent prevents resource exhaustion during traffic spikes
  * **Automatic memory cleanup** — completed and failed executions are cleaned up automatically
</Update>

<Update label="2026-07-15" tags={["MCP", "Connectors", "Reliability"]}>
  #### MCP connector freshness

  * **Idle connection cleanup** — MCP connectors not used recently drop from the connection pool automatically, keeping resource usage low for agents with many MCP connectors
  * **Automatic config updates** — when a registry connector's config schema changes, all agents referencing it re-resolve with the new defaults. Per-agent overrides are preserved.
</Update>

<Update label="2026-07-13" tags={["Agent", "Context"]}>
  #### Artifacts in multi-turn history

  Agents carry their own previous results into the next turn. A coding suggestion, extracted data structure, or calculated score from an earlier turn is included in the conversation history automatically — the client doesn't re-send it.

  Agent-produced data is tagged distinctly from user-supplied data, so the agent always knows what it produced versus what it was given. No client changes required.
</Update>

<Update label="2026-07-10" tags={["API"]}>
  #### X-Request-ID on all responses

  Every response includes an `X-Request-ID` header that ties your client-side request to server-side logs and traces. Set on all v2 endpoints. Use it when reporting issues to Corti support.
</Update>

<Update label="2026-07-08" tags={["Connectors", "API"]}>
  #### Five connector types

  The unified connector model now spans five types — every way to extend an agent, from pre-built clinical tools to custom JSON Schema tools:

  | Type       | What it gives your agent                                                                                                                          |
  | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
  | `registry` | Pre-built connectors from the Corti registry — coding, drug lookup, PubMed, clinical trials, web search, medical calculator, interviewing, memory |
  | `mcp`      | Any MCP server you operate — provide a URL and optional auth                                                                                      |
  | `agent`    | Another Corti agent in your tenant — multi-agent composition                                                                                      |
  | `a2a`      | Any remote A2A agent discovered by endpoint URL                                                                                                   |
  | `schema`   | A custom tool defined by a JSON Schema — no server needed                                                                                         |

  See [Connectors](/agentic/connectors).
</Update>

<Update label="2026-07-07" tags={["API", "v2", "Release"]}>
  #### Agentic Framework v2.0.0

  The v2 API is generally available. New endpoint families, unified connectors, A2A v1.0, and first-class resources for contexts, connectors, usage, feedback, and traces. All endpoints live under `/v2/agentic/`.

  The v1 API remains available and deprecated. See the [v1-to-v2 migration guide](/agentic/guides/migrate-v1-to-v2).

  ##### Connectors

  v1 had three concepts: Experts, MCP servers, and sub-agents. v2 unifies them into one [connectors](/agentic/connectors) model and adds two new types:

  | Type             | What it does                                                                                                                                      |
  | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
  | `registry`       | Pre-built connectors from the Corti registry (coding, drug lookup, PubMed, clinical trials, web search, medical calculator, interviewing, memory) |
  | `mcp`            | A remote MCP server you operate yourself                                                                                                          |
  | `agent`          | Another Corti agent in the same tenant — multi-agent composition                                                                                  |
  | `a2a` *(new)*    | A remote A2A agent discovered by endpoint URL                                                                                                     |
  | `schema` *(new)* | A custom tool defined by a JSON Schema                                                                                                            |

  Manage connectors via the `connectors` array on agent create/patch, or via dedicated sub-resource endpoints for individual attach/update/remove.

  ##### A2A v1.0

  The [A2A protocol](/agentic/a2a-protocol) is upgraded to v1.0. Two protocol bindings at the same base URL — pick whichever fits your stack:

  * **HTTP+JSON** — REST endpoints, simplest for most use cases
  * **JSON-RPC** — a single endpoint for clients that prefer JSON-RPC envelopes

  | Operation           | HTTP+JSON                            | JSON-RPC method        |
  | ------------------- | ------------------------------------ | ---------------------- |
  | Send a message      | `POST /a2a/message:send`             | `SendMessage`          |
  | Stream a message    | `POST /a2a/message:stream`           | `SendStreamingMessage` |
  | List tasks          | `GET /a2a/tasks`                     | `ListTasks`            |
  | Get a task          | `GET /a2a/tasks/{taskId}`            | `GetTask`              |
  | Cancel a task       | `POST /a2a/tasks/{taskId}:cancel`    | `CancelTask`           |
  | Subscribe to a task | `POST /a2a/tasks/{taskId}:subscribe` | `SubscribeToTask`      |

  Connect any third-party A2A agent. The runtime reads the remote agent's card and negotiates the wire dialect — native v1.0, or the legacy 0.x dialect for agents that haven't upgraded. No adapters needed.

  ##### Endpoint map

  Everything under `/v2/agentic/`:

  **Agents**

  | Method | Path                                            |
  | ------ | ----------------------------------------------- |
  | POST   | `/agents`                                       |
  | GET    | `/agents`                                       |
  | GET    | `/agents/{agentId}`                             |
  | PATCH  | `/agents/{agentId}`                             |
  | DELETE | `/agents/{agentId}`                             |
  | GET    | `/agents/{agentId}/.well-known/agent-card.json` |
  | GET    | `/agents/{agentId}/usage`                       |

  **Connectors**

  | Method | Path                                         |
  | ------ | -------------------------------------------- |
  | GET    | `/agents/{agentId}/connectors`               |
  | POST   | `/agents/{agentId}/connectors`               |
  | GET    | `/agents/{agentId}/connectors/{connectorId}` |
  | PATCH  | `/agents/{agentId}/connectors/{connectorId}` |
  | DELETE | `/agents/{agentId}/connectors/{connectorId}` |

  **Messaging & tasks**

  | Method | Path                                             |
  | ------ | ------------------------------------------------ |
  | POST   | `/agents/{agentId}/a2a/message:send`             |
  | POST   | `/agents/{agentId}/a2a/message:stream`           |
  | GET    | `/agents/{agentId}/a2a/tasks`                    |
  | GET    | `/agents/{agentId}/a2a/tasks/{taskId}`           |
  | POST   | `/agents/{agentId}/a2a/tasks/{taskId}:cancel`    |
  | POST   | `/agents/{agentId}/a2a/tasks/{taskId}:subscribe` |
  | POST   | `/agents/{agentId}/a2a`                          |

  **Contexts**

  | Method | Path                                                          |
  | ------ | ------------------------------------------------------------- |
  | GET    | `/contexts`                                                   |
  | GET    | `/contexts/{contextId}`                                       |
  | DELETE | `/contexts/{contextId}`                                       |
  | GET    | `/contexts/{contextId}/tasks`                                 |
  | GET    | `/contexts/{contextId}/tasks/{taskId}`                        |
  | GET    | `/contexts/{contextId}/tasks/{taskId}/artifacts/{artifactId}` |
  | GET    | `/contexts/{contextId}/trace`                                 |

  **Feedback**

  | Method | Path                                            |
  | ------ | ----------------------------------------------- |
  | POST   | `/contexts/{contextId}/tasks/{taskId}/feedback` |
  | GET    | `/contexts/{contextId}/tasks/{taskId}/feedback` |
  | DELETE | `/contexts/{contextId}/tasks/{taskId}/feedback` |

  **Registry**

  | Method | Path                                 |
  | ------ | ------------------------------------ |
  | GET    | `/registry/connectors`               |
  | GET    | `/registry/connectors/{connectorId}` |

  ##### Agent metadata

  | Field        | What it controls                           |
  | ------------ | ------------------------------------------ |
  | `visibility` | `private`, `unlisted`, `public`            |
  | `lifecycle`  | `ephemeral`, `persistent`                  |
  | `model`      | Which model the agent uses                 |
  | `labels`     | Free-form key-value metadata for filtering |

  ##### Prefixed IDs

  All resource IDs use type-prefixed UUIDv7 — tell what a resource is from the ID alone:

  | Prefix  | Resource  |
  | ------- | --------- |
  | `agt.`  | Agent     |
  | `con.`  | Connector |
  | `ctx.`  | Context   |
  | `task.` | Task      |
  | `msg.`  | Message   |
  | `art.`  | Artifact  |
  | `fb.`   | Feedback  |

  ##### Streaming

  Two SSE endpoints for real-time updates:

  * `message:stream` — send a message and watch the response unfold
  * `tasks:subscribe` — subscribe to updates for an existing task

  See [Stream agent responses](/agentic/guides/stream-responses).

  ##### Credit pre-flight check

  Tasks are checked for sufficient credits before any tokens are consumed. Insufficient balance = rejected task, zero spend. Per-task usage (`$usage`, `credits`) is in the task metadata. Agent-level metrics at `GET /agents/{agentId}/usage`. See the [usage guide](/agentic/guides/view-usage).

  ##### JSON Merge Patch

  `PATCH` uses JSON Merge Patch (RFC 7386). Omit a field to leave it unchanged; send `null` to clear it. `Content-Type: application/merge-patch+json`.

  ##### Errors

  A2A `google.rpc.Status` format with structured details for programmatic handling.

  ##### v1 to v2 changes

  | v1                                               | v2                                                                |
  | ------------------------------------------------ | ----------------------------------------------------------------- |
  | `experts` array                                  | `connectors` with `type: "registry"`                              |
  | `?ephemeral=true`                                | `lifecycle: "ephemeral"` in body                                  |
  | `agentType` (expert, orchestrator, interviewing) | Removed — specialization comes from connectors and system prompts |
  | `kind: "text"` / `kind: "data"` on parts         | Removed — use `text`, `file`, `data` properties                   |
  | `role: "user"`                                   | `role: "ROLE_USER"`                                               |
  | `submitted`, `working`                           | `TASK_STATE_SUBMITTED`, `TASK_STATE_WORKING`                      |
  | Inline expert creation                           | Removed — use `registry` connectors                               |

  Full details: [v1-to-v2 migration guide](/agentic/guides/migrate-v1-to-v2).
</Update>

<Update label="2026-07-07" tags={["Agent", "Output quality"]}>
  #### Part provenance

  Every data part in a conversation carries an origin tag the agent can see:

  * `user_text_NN` / `user_data_NN` — what you sent
  * `tool_data_NN` — what a connector returned
  * `agent_data_NN` — what the agent produced in a previous turn

  This stops the agent from echoing your input as its own answer and keeps multi-turn conversations accurate. No client changes required.
</Update>

<Update label="2026-07-07" tags={["Agent", "Tools", "Output quality"]}>
  #### Built-in data inspection tools

  Two tools the agent uses automatically when the conversation contains data or text parts. No configuration needed.

  ##### `query_data_parts` — jq over structured data

  Run [jq](https://jqlang.github.io/jq/manual/) programs over data parts. Navigate, filter, search, and join across parts — the agent pulls exactly the fields it needs without loading the whole payload into the prompt.

  * **Navigate**: first five lab results — `.user_data_01.results[0:5]`
  * **Filter**: flagged results — `.user_data_01.results[] | select(.flag == "H")`
  * **Search**: where "metformin" appears in the structure
  * **Join**: match patients to labs across two parts — `.user_data_01.patients[] as $p | .user_data_03.labs[] | select(.mrn == $p.mrn)`

  | Parameter | Type        | Description                                                      |
  | --------- | ----------- | ---------------------------------------------------------------- |
  | `ids`     | `list[str]` | Data part GIDs to load (e.g. `["user_data_01", "user_data_03"]`) |
  | `program` | `str`       | jq program; start with the part id (e.g. `.user_data_01`)        |

  Offered automatically when the conversation has at least one data part.

  ##### `read_part` — read and search text

  Read a window of text or search for terms in long content — encounter transcripts, referral letters, clinical notes.

  * **Windowed read**: read 5,000 characters from any offset, with markers showing what's hidden before and after
  * **Search**: find every occurrence of a term or regex pattern, with 200 characters of context per match

  | Parameter | Type   | Description                                                                                              |
  | --------- | ------ | -------------------------------------------------------------------------------------------------------- |
  | `id`      | `str`  | Part to read — text part (`user_text_02`) or data part (`user_data_01`)                                  |
  | `field`   | `str`  | Dot path to a string field inside a data part (e.g. `notes`, `results.0.text`). Required for data parts. |
  | `offset`  | `int`  | Start position in characters                                                                             |
  | `length`  | `int`  | Characters to return (default 5,000)                                                                     |
  | `query`   | `str`  | Search instead of read — returns matches with context                                                    |
  | `regex`   | `bool` | Treat `query` as regex                                                                                   |

  Offered automatically when the conversation has at least one text or data part.

  ##### Why this matters

  Agents work with real clinical data sizes. Scan a 50-page transcript for every mention of chest pain. Cross-reference a full lab panel against a medication list. Produce a summary without hallucinating details that didn't fit. The tools reference parts by GID, so the agent always knows whether it's inspecting your data, a connector's output, or its own prior turn.
</Update>

<Update label="2026-06-23" tags={["A2A", "Context"]}>
  #### Shared agents across contexts

  Use the same agent across multiple conversations, sessions, and patients. No more creating duplicate agents for each context. No client changes required.
</Update>

<Update label="2026-06-10" tags={["MCP", "Connectors"]}>
  #### MCP 2025-11-25 spec compliance

  MCP connectors follow the Model Context Protocol 2025-11-25 specification, including the latest tool-registration and `list_changed` refresh semantics. MCP servers you operate — open-source or in-house — work with the framework.
</Update>

<Update label="2026-06-10" tags={["Usage", "API"]}>
  #### Credit pre-flight and usage metering

  Tasks are checked for sufficient credits before processing. Insufficient balance = rejected task, no tokens consumed. Per-task usage in task metadata:

  * `$usage` — input and output tokens
  * `credits` — credit balance and spend

  Agent-level metrics at `GET /v2/agentic/agents/{agentId}/usage` with daily buckets. See the [usage guide](/agentic/guides/view-usage).
</Update>