Skip to main content
This page adds Corti-specific detail on top of the core A2A concepts. We have tried to adhere as closely as possible to the intended A2A protocol specification — for the canonical definition of these concepts, see the A2A documentation on Core Concepts and Components in A2A. The Corti Agentic Framework uses a set of core concepts that define how Corti agents, tools, and external systems interact. Understanding these building blocks is essential for developing on the Corti platform and for integrating your own systems using the A2A Protocol.

​
Core Actors

At Corti, these actors typically map to concrete products and integrations:
  • User: A clinician, contact-center agent, knowledge worker, or an automated service in your environment. The user initiates a request (for example, “summarize this consultation” or “triage this patient”) that requires assistance from one or more Corti-powered agents.
  • A2A Client (Client Agent): The application that calls Corti. This is your application/server. The client initiates communication using the A2A Protocol and orchestrates how results are used in your product.
  • A2A Server (Remote Agent): A Corti agent or agentic system that exposes an HTTP endpoint implementing the A2A Protocol. It receives requests from clients, processes tasks, and returns results or status updates.

​
Fundamental Communication Elements

The following elements are fundamental to A2A communication and how Corti uses them:
A JSON metadata document describing an agent’s identity, capabilities, endpoint, skills, and authentication requirements.Key Purpose: Enables Corti and your applications to discover agents and understand how to call them securely and effectively.
A stateful unit of work initiated by an agent, with a unique ID and defined lifecycle.Key Purpose: Powers long‑running operations in Corti (for example, document generation or multi‑step workflows) and enables tracking and collaboration.
A single turn of communication between a client and an agent, containing content and a role (“user” or “agent”).Key Purpose: Carries instructions, clinical context, user questions, and agent responses between your application, Corti Assistant, and remote agents.
The fundamental content container (for example, TextPart, FilePart, DataPart) used within Messages and Artifacts.Key Purpose: Lets Corti exchange text, audio transcripts, structured JSON, and files in a consistent way across agents and tools.
A tangible output generated by an agent during a task (for example, a document, image, or structured data).Key Purpose: Represents concrete Corti results such as SOAP notes, call summaries, recommendations, or other structured outputs.
A server-generated identifier (contextId) that logically groups multiple related Task objects, providing context across a series of interactions.Key Purpose: Enables you to associate multiple tasks and agents with a single patient encounter, call, or workflow, ensuring continuity and proper scoping of shared knowledge throughout an interaction.

​
Agent Cards in Corti

The Agent Card is a JSON document that serves as a digital business card for initial discovery and interaction setup. It provides essential metadata about an agent. Clients parse this information to determine if an agent is suitable for a given task, how to structure requests, and how to communicate securely. Key information includes identity, service endpoint (URL), A2A capabilities, authentication requirements, and a list of skills. Within Corti, Agent Cards are how you:
  • Discover first‑party Corti agents and their capabilities.
  • Register and describe your own remote agents so Corti workflows can call them.
  • Declare authentication and compliance requirements up front, before any PHI or sensitive data is exchanged.

​
Messages and Parts in Corti

A message represents a single turn of communication between a client and an agent. It includes a role (“user” or “agent”) and a unique messageId. It contains one or more Part objects, which are granular containers for the actual content. This design allows A2A to be modality independent and lets Corti mix clinical text, transcripts, and structured data safely in a single exchange. The primary part kinds are:
  • TextPart: Contains plain textual content, such as instructions, questions, or generated notes.
  • DataPart: Carries structured JSON data. This is useful for clinical facts, workflow parameters, EHR identifiers, or any machine‑readable information you exchange with Corti.
  • FilePart: Represents a file (for example, a PDF discharge letter or an audio recording). It can be transmitted either inline (Base64 encoded) or through a URI. It includes metadata like “name” and “mimeType”. This is not yet fully supported.

​
Artifacts in Corti

An artifact represents a tangible output or a concrete result generated by a remote agent during task processing. Unlike general messages, artifacts are the actual deliverables. An artifact has a unique artifactId, a human-readable name, and consists of one or more part objects. Artifacts are closely tied to the task lifecycle and can be streamed incrementally to the client. In Corti, artifacts typically correspond to business outputs such as:
  • Clinical notes (for example, SOAP notes, discharge summaries).
  • Extracted clinical facts or coding suggestions.
  • Generated documents, checklists, or other workflow‑specific artifacts.

​
Agent response: Task or Message

The agent response can be a new Task (when the agent needs to perform a long-running operation) or a Message (when the agent can respond immediately). On the Corti platform this means:
  • For quick operations (for example, a short completion or a classification), your agent often responds with a Message.
  • For longer workflows (for example, generating a full clinical document, coordinating multiple tools, or waiting on downstream systems), your agent responds with a Task that you can monitor and later retrieve artifacts from.