Skip to content

Artifacts

In ADK, Artifacts represent a crucial mechanism for managing named, versioned binary data associated either with a specific user interaction session or persistently with a user across multiple sessions. They allow your agents and tools to handle data beyond simple text strings, enabling richer interactions involving files, images, audio, and other binary formats.

What are Artifacts?

  • Definition: An Artifact is essentially a piece of binary data (like the content of a file) identified by a unique filename string within a specific scope (session or user). Each time you save an artifact with the same filename, a new version is created.

  • Representation: Artifacts are consistently represented using the standard Part object from the ADK TypeScript library. The core data is typically stored within the Part object, which itself contains:

    • data: The raw binary content as a Uint8Array.
    • mimeType: A string indicating the type of the data (e.g., 'image/png', 'application/pdf'). This is essential for correctly interpreting the data later.
    // Example of how an artifact might be represented as a Part
import { Part } from 'adk-typescript';

// Assume 'imageBytes' contains the binary data of a PNG image
const imageBytes = new Uint8Array([0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A]); // Placeholder for actual image bytes

const imageArtifact: Part = {
  inlineData: {
    mimeType: "image/png",
    data: imageBytes
  }
};

console.log(`Artifact MIME Type: ${imageArtifact.inlineData?.mimeType}`);
console.log(`Artifact Data (first 10 bytes): ${imageArtifact.inlineData?.data.slice(0, 10)}...`);

  • Persistence & Management: Artifacts are not stored directly within the agent or session state. Their storage and retrieval are managed by a dedicated Artifact Service (an implementation of BaseArtifactService, defined in the ADK TypeScript library). ADK provides implementations like InMemoryArtifactService (for testing/temporary storage) and cloud storage implementations for persistent storage. The chosen service handles versioning automatically when you save data.

Why Use Artifacts?

While session state is suitable for storing small pieces of configuration or conversational context (like strings, numbers, booleans, or small objects/arrays), Artifacts are designed for scenarios involving binary or large data:

  1. Handling Non-Textual Data: Easily store and retrieve images, audio clips, video snippets, PDFs, spreadsheets, or any other file format relevant to your agent's function.
  2. Persisting Large Data: Session state is generally not optimized for storing large amounts of data. Artifacts provide a dedicated mechanism for persisting larger blobs without cluttering the session state.
  3. User File Management: Provide capabilities for users to upload files (which can be saved as artifacts) and retrieve or download files generated by the agent (loaded from artifacts).
  4. Sharing Outputs: Enable tools or agents to generate binary outputs (like a PDF report or a generated image) that can be saved via saveArtifact and later accessed by other parts of the application or even in subsequent sessions (if using user namespacing).
  5. Caching Binary Data: Store the results of computationally expensive operations that produce binary data (e.g., rendering a complex chart image) as artifacts to avoid regenerating them on subsequent requests.

In essence, whenever your agent needs to work with file-like binary data that needs to be persisted, versioned, or shared, Artifacts managed by an ArtifactService are the appropriate mechanism within ADK.

Common Use Cases

Artifacts provide a flexible way to handle binary data within your ADK applications.

Here are some typical scenarios where they prove valuable:

  • Generated Reports/Files:

    • A tool or agent generates a report (e.g., a PDF analysis, a CSV data export, an image chart).
    • The tool uses toolContext.saveArtifact("monthly_report_oct_2024.pdf", reportPart) to store the generated file.
    • The user can later ask the agent to retrieve this report, which might involve another tool using toolContext.loadArtifact("monthly_report_oct_2024.pdf") or listing available reports using toolContext.listArtifacts().

  • Handling User Uploads:

    • A user uploads a file (e.g., an image for analysis, a document for summarization) through a front-end interface.
    • The application backend receives the file, creates a Part from its bytes and MIME type, and uses the runner.sessionService (or similar mechanism outside a direct agent run) or a dedicated tool/callback within a run via context.saveArtifact to store it, potentially using the user: namespace if it should persist across sessions (e.g., user:uploaded_image.jpg).
    • An agent can then be prompted to process this uploaded file, using context.loadArtifact("user:uploaded_image.jpg") to retrieve it.

  • Storing Intermediate Binary Results:

    • An agent performs a complex multi-step process where one step generates intermediate binary data (e.g., audio synthesis, simulation results).
    • This data is saved using context.saveArtifact with a temporary or descriptive name (e.g., "temp_audio_step1.wav").
    • A subsequent agent or tool in the flow (perhaps in a SequentialAgent or triggered later) can load this intermediate artifact using context.loadArtifact to continue the process.

  • Persistent User Data:

    • Storing user-specific configuration or data that isn't a simple key-value state.
    • An agent saves user preferences or a profile picture using context.saveArtifact("user:profile_settings.json", settingsPart) or context.saveArtifact("user:avatar.png", avatarPart).
    • These artifacts can be loaded in any future session for that user to personalize their experience.

  • Caching Generated Binary Content:

    • An agent frequently generates the same binary output based on certain inputs (e.g., a company logo image, a standard audio greeting).
    • Before generating, a beforeToolCallback or beforeAgentCallback checks if the artifact exists using context.loadArtifact.
    • If it exists, the cached artifact is used, skipping the generation step.
    • If not, the content is generated, and context.saveArtifact is called in an afterToolCallback or afterAgentCallback to cache it for next time.

Core Concepts

Understanding artifacts involves grasping a few key components: the service that manages them, the data structure used to hold them, and how they are identified and versioned.

Artifact Service (BaseArtifactService)

  • Role: The central component responsible for the actual storage and retrieval logic for artifacts. It defines how and where artifacts are persisted.

  • Interface: Defined by the interface BaseArtifactService in the ADK TypeScript library. Any concrete implementation must provide methods for:

    • saveArtifact(...) -> number: Stores the artifact data and returns its assigned version number.
    • loadArtifact(...) -> Part | undefined: Retrieves a specific version (or the latest) of an artifact.
    • listArtifactKeys(...) -> string[]: Lists the unique filenames of artifacts within a given scope.
    • deleteArtifact(...) -> Promise<void>: Removes an artifact (and potentially all its versions, depending on implementation).
    • listVersions(...) -> number[]: Lists all available version numbers for a specific artifact filename.

  • Configuration: You provide an instance of an artifact service (e.g., InMemoryArtifactService) when initializing the Runner. The Runner then makes this service available to agents and tools via the InvocationContext.

import { 
  Runner, 
  InMemoryArtifactService, 
  Agent, 
  InMemorySessionService 
} from 'adk-typescript';

// Example: Configuring the Runner with an Artifact Service
const myAgent = new Agent({
  name: "artifact_user_agent", 
  model: "gemini-2.0-flash"
});
const artifactService = new InMemoryArtifactService(); // Choose an implementation
const sessionService = new InMemorySessionService();

const runner = new Runner({
  agent: myAgent,
  appName: "my_artifact_app",
  sessionService: sessionService,
  artifactService: artifactService // Provide the service instance here
});
// Now, contexts within runs managed by this runner can use artifact methods

Artifact Data (Part)

  • Standard Representation: Artifact content is universally represented using the Part object, the same structure used for parts of LLM messages.

  • Key Attribute (inlineData): For artifacts, the most relevant attribute is inlineData, which contains:

    • data (Uint8Array): The raw binary content of the artifact.
    • mimeType (string): A standard MIME type string (e.g., 'application/pdf', 'image/png', 'audio/mpeg') describing the nature of the binary data. This is crucial for correct interpretation when loading the artifact.

  • Creation: You typically create a Part for an artifact by constructing it with the appropriate inlineData property.

import { Part } from 'adk-typescript';

// Example: Creating an artifact Part from raw bytes
const pdfBytes = new Uint8Array([0x25, 0x50, 0x44, 0x46]); // Your raw PDF data (example start bytes)
const pdfMimeType = "application/pdf";

// Creating the Part object
const pdfArtifact: Part = {
  inlineData: {
    data: pdfBytes,
    mimeType: pdfMimeType
  }
};

console.log(`Created artifact with MIME type: ${pdfArtifact.inlineData?.mimeType}`);

Filename (string)

  • Identifier: A simple string used to name and retrieve an artifact within its specific namespace (see below).
  • Uniqueness: Filenames must be unique within their scope (either the session or the user namespace).
  • Best Practice: Use descriptive names, potentially including file extensions (e.g., "monthly_report.pdf", "user_avatar.jpg"), although the extension itself doesn't dictate behavior – the mimeType does.

Versioning (number)

  • Automatic Versioning: The artifact service automatically handles versioning. When you call saveArtifact, the service determines the next available version number (typically starting from 0 and incrementing) for that specific filename and scope.
  • Returned by saveArtifact: The saveArtifact method returns the integer version number that was assigned to the newly saved artifact.
  • Retrieval:
  • loadArtifact(..., version=undefined) (default): Retrieves the latest available version of the artifact.
  • loadArtifact(..., version=N): Retrieves the specific version N.
  • Listing Versions: The listVersions method (on the service, not context) can be used to find all existing version numbers for an artifact.

Namespacing (Session vs. User)

  • Concept: Artifacts can be scoped either to a specific session or more broadly to a user across all their sessions within the application. This scoping is determined by the filename format and handled internally by the ArtifactService.

  • Default (Session Scope): If you use a plain filename like "report.pdf", the artifact is associated with the specific appName, userId, and sessionId. It's only accessible within that exact session context.

  • Internal Path (Example): appName/userId/sessionId/report.pdf/<version> (as managed by the artifact service implementation)

  • User Scope ("user:" prefix): If you prefix the filename with "user:", like "user:profile.png", the artifact is associated only with the appName and userId. It can be accessed or updated from any session belonging to that user within the app.

  • Internal Path (Example): appName/userId/user/user:profile.png/<version> (The user: prefix is often kept in the final path segment for clarity, as seen in the service implementations).

  • Use Case: Ideal for data that belongs to the user themselves, independent of a specific conversation, such as profile pictures, user preferences files, or long-term reports.
// Example illustrating namespace difference (conceptual)

// Session-specific artifact filename
const sessionReportFilename = "summary.txt";

// User-specific artifact filename
const userConfigFilename = "user:settings.json";

// When saving 'summary.txt', it's tied to the current session ID.
// When saving 'user:settings.json', it's tied only to the user ID.

These core concepts work together to provide a flexible system for managing binary data within the ADK framework.

Interacting with Artifacts (via Context Objects)

The primary way you interact with artifacts within your agent's logic (specifically within callbacks or tools) is through methods provided by the CallbackContext and ToolContext objects. These methods abstract away the underlying storage details managed by the ArtifactService.

Prerequisite: Configuring the ArtifactService

Before you can use any artifact methods via the context objects, you must provide an instance of a BaseArtifactService implementation (like InMemoryArtifactService) when initializing your Runner.

import { 
  Runner, 
  InMemoryArtifactService, 
  Agent, 
  InMemorySessionService 
} from 'adk-typescript';

// Your agent definition
const agent = new Agent({
  name: "my_agent", 
  model: "gemini-2.0-flash"
});

// Instantiate the desired artifact service
const artifactService = new InMemoryArtifactService();

// Provide it to the Runner
const runner = new Runner({
  agent: agent,
  appName: "artifact_app",
  sessionService: new InMemorySessionService(),
  artifactService: artifactService // Service must be provided here
});

If no artifactService is configured in the InvocationContext (which happens if it's not passed to the Runner), calling saveArtifact, loadArtifact, or listArtifacts on the context objects will raise an error.

Accessing Methods

The artifact interaction methods are available directly on instances of CallbackContext (passed to agent and model callbacks) and ToolContext (passed to tool callbacks). Remember that ToolContext inherits from CallbackContext.

Saving Artifacts

  • Method:
context.saveArtifact(filename: string, artifact: Part): number

  • Available Contexts: CallbackContext, ToolContext.

  • Action:

    1. Takes a filename string (which may include the "user:" prefix for user-scoping) and a Part object containing the artifact data (usually in artifact.inlineData).
    2. Passes this information to the underlying artifactService.saveArtifact.
    3. The service stores the data, assigns the next available version number for that filename and scope.
    4. Crucially, the context automatically records this action by adding an entry to the current event's artifact delta tracking. This delta maps the filename to the newly assigned version.

  • Returns: The integer version number assigned to the saved artifact.

  • Code Example (within a hypothetical tool or callback):

import { Part, CallbackContext } from 'adk-typescript'; // Or ToolContext

async function saveGeneratedReport(context: CallbackContext, reportBytes: Uint8Array): Promise<void> {
  /**
   * Saves generated PDF report bytes as an artifact.
   */
  const reportArtifact: Part = {
    inlineData: {
      data: reportBytes,
      mimeType: "application/pdf"
    }
  };
  const filename = "generated_report.pdf";

  try {
    const version = context.saveArtifact(filename, reportArtifact);
    console.log(`Successfully saved artifact '${filename}' as version ${version}.`);
    // The event generated after this callback will contain artifact delta information
  } catch (e) {
    if (e instanceof Error) {
      console.log(`Error saving artifact: ${e.message}. Is ArtifactService configured?`);
    } else {
      // Handle potential storage errors
      console.log(`An unexpected error occurred during artifact save: ${e}`);
    }
  }
}

// --- Example Usage Concept ---
// const reportData = new Uint8Array([...]); // Assume this holds the PDF bytes
// await saveGeneratedReport(callbackContext, reportData);

Loading Artifacts

  • Method:
context.loadArtifact(filename: string, version?: number): Part | undefined

  • Available Contexts: CallbackContext, ToolContext.

  • Action:

    1. Takes a filename string (potentially including "user:").
    2. Optionally takes a number version. If version is undefined (the default), it requests the latest version from the service. If a specific number is provided, it requests that exact version.
    3. Calls the underlying artifactService.loadArtifact.
    4. The service attempts to retrieve the specified artifact.

  • Returns: A Part object containing the artifact data if found, or undefined if the artifact (or the specified version) does not exist.

  • Code Example (within a hypothetical tool or callback):

import { Part, CallbackContext } from 'adk-typescript'; // Or ToolContext

async function processLatestReport(context: CallbackContext): Promise<void> {
  /**
   * Loads the latest report artifact and processes its data.
   */
  const filename = "generated_report.pdf";
  try {
    // Load the latest version
    const reportArtifact = context.loadArtifact(filename);

    if (reportArtifact && reportArtifact.inlineData) {
      console.log(`Successfully loaded latest artifact '${filename}'.`);
      console.log(`MIME Type: ${reportArtifact.inlineData.mimeType}`);
      // Process the reportArtifact.inlineData.data (Uint8Array)
      const pdfBytes = reportArtifact.inlineData.data;
      console.log(`Report size: ${pdfBytes.length} bytes.`);
      // ... further processing ...
    } else {
      console.log(`Artifact '${filename}' not found.`);
    }

    // Example: Load a specific version (if version 0 exists)
    // const specificVersionArtifact = context.loadArtifact(filename, 0);
    // if (specificVersionArtifact) {
    //   console.log(`Loaded version 0 of '${filename}'.`);
    // }

  } catch (e) {
    if (e instanceof Error) {
      console.log(`Error loading artifact: ${e.message}. Is ArtifactService configured?`);
    } else {
      // Handle potential storage errors
      console.log(`An unexpected error occurred during artifact load: ${e}`);
    }
  }
}

// --- Example Usage Concept ---
// await processLatestReport(callbackContext);

Listing Artifact Filenames (Tool Context Only)

  • Method:
toolContext.listArtifacts(): string[]

  • Available Context: ToolContext only. This method is not available on the base CallbackContext.

  • Action: Calls the underlying artifactService.listArtifactKeys to get a list of all unique artifact filenames accessible within the current scope (including both session-specific files and user-scoped files prefixed with "user:").

  • Returns: A sorted string[] of filenames.

  • Code Example (within a tool function):

import { ToolContext } from 'adk-typescript';

function listUserFiles(toolContext: ToolContext): string {
  /**
   * Tool to list available artifacts for the user.
   */
  try {
    const availableFiles = toolContext.listArtifacts();
    if (!availableFiles.length) {
      return "You have no saved artifacts.";
    } else {
      // Format the list for the user/LLM
      const fileListStr = availableFiles.map(fname => `- ${fname}`).join('\n');
      return `Here are your available artifacts:\n${fileListStr}`;
    }
  } catch (e) {
    if (e instanceof Error) {
      console.log(`Error listing artifacts: ${e.message}. Is ArtifactService configured?`);
      return "Error: Could not list artifacts.";
    } else {
      console.log(`An unexpected error occurred during artifact list: ${e}`);
      return "Error: An unexpected error occurred while listing artifacts.";
    }
  }
}

// This function would typically be wrapped in a FunctionTool
// import { FunctionTool } from 'adk-typescript';
// const listFilesTool = new FunctionTool({ func: listUserFiles });

These context methods provide a convenient and consistent way to manage binary data persistence within ADK, regardless of the chosen backend storage implementation (InMemoryArtifactService or other cloud storage services).

Available Implementations

ADK provides concrete implementations of the BaseArtifactService interface, offering different storage backends suitable for various development stages and deployment needs. These implementations handle the details of storing, versioning, and retrieving artifact data based on the appName, userId, sessionId, and filename (including the user: namespace prefix).

InMemoryArtifactService

  • Source: Imported from adk-typescript.
  • Storage Mechanism: Uses a JavaScript Map held in the application's memory to store artifacts. The Map keys represent the artifact path (incorporating app, user, session/user-scope, and filename), and the values are arrays of Part, where each element in the array corresponds to a version (index 0 is version 0, index 1 is version 1, etc.).
  • Key Features:
    • Simplicity: Requires no external setup or dependencies beyond the core ADK library.
    • Speed: Operations are typically very fast as they involve in-memory Map lookups and array manipulations.
    • Ephemeral: All stored artifacts are lost when the Node.js process running the application terminates. Data does not persist between application restarts.
  • Use Cases:
    • Ideal for local development and testing where persistence is not required.
    • Suitable for short-lived demonstrations or scenarios where artifact data is purely temporary within a single run of the application.
  • Instantiation:
import { InMemoryArtifactService, Runner } from 'adk-typescript';

// Simply instantiate the class
const inMemoryService = new InMemoryArtifactService();

// Then pass it to the Runner
// const runner = new Runner({
//   ...
//   artifactService: inMemoryService
// });

Choosing the appropriate ArtifactService implementation depends on your application's requirements for data persistence, scalability, and operational environment.

Best Practices

To use artifacts effectively and maintainably:

  • Choose the Right Service: Use InMemoryArtifactService for rapid prototyping, testing, and scenarios where persistence isn't needed. Use cloud storage implementations (or implement your own BaseArtifactService for other backends) for production environments requiring data persistence and scalability.
  • Meaningful Filenames: Use clear, descriptive filenames. Including relevant extensions (.pdf, .png, .wav) helps humans understand the content, even though the mimeType dictates programmatic handling. Establish conventions for temporary vs. persistent artifact names.
  • Specify Correct MIME Types: Always provide an accurate mimeType when creating the Part for saveArtifact. This is critical for applications or tools that later loadArtifact to interpret the binary data correctly. Use standard IANA MIME types where possible.
  • Understand Versioning: Remember that loadArtifact() without a specific version argument retrieves the latest version. If your logic depends on a specific historical version of an artifact, be sure to provide the integer version number when loading.
  • Use Namespacing (user:) Deliberately: Only use the "user:" prefix for filenames when the data truly belongs to the user and should be accessible across all their sessions. For data specific to a single conversation or session, use regular filenames without the prefix.
  • Error Handling:
    • Always check if an artifactService is actually configured before calling context methods (saveArtifact, loadArtifact, listArtifacts) – they will raise an error if the service is not configured. Use proper try/catch blocks.
    • Check the return value of loadArtifact, as it will be undefined if the artifact or version doesn't exist. Don't assume it always returns a Part.
    • Be prepared to handle exceptions from the underlying storage service, especially with cloud storage services (permission issues, bucket not existing, network errors).
  • Size Considerations: Artifacts are suitable for typical file sizes, but be mindful of potential costs and performance impacts with extremely large files, especially with cloud storage. InMemoryArtifactService can consume significant memory if storing many large artifacts. Evaluate if very large data might be better handled through direct cloud storage links or other specialized storage solutions rather than passing entire binary arrays in-memory.
  • Cleanup Strategy: For persistent storage like cloud storage services, artifacts remain until explicitly deleted. If artifacts represent temporary data or have a limited lifespan, implement a strategy for cleanup. This might involve:
    • Using storage lifecycle policies on the bucket or container.
    • Building specific tools or administrative functions that utilize the artifactService.deleteArtifact method (note: delete is not exposed via context objects for safety).
    • Carefully managing filenames to allow pattern-based deletion if needed.