Open Agentic Schema Framework (OASF)

The Open Agentic Schema Framework (OASF) is a standardized schema system designed for defining and managing AI agent capabilities, interactions, and metadata. It uses attribute-based taxonomies to provide a structured way to describe agent attributes, capabilities, and relationships, enabling interoperability and consistent discovery across distributed AI agent systems.

OASF is inspired by the Open Cybersecurity Schema Framework (OCSF) in both its data modeling philosophy and implementation.

The AGNTCY Observability Data Schema is an extension of the OpenTelemetry (OTel) framework, specifically following the LLM Semantic Conventions for Generative AI systems. It is designed to provide standardized observability for Multi-Agent Systems (MAS), enabling monitoring, analysis, and evaluation of agentic performance.

Key features include:

• Standardization: Provides a consistent structure for Observability SDKs to implement across different agentic frameworks.
• MAS-Specific Metrics: Includes specialized concepts such as agent collaboration success rate, MAS response time, and task delegation accuracy.
• Core Observability Pillars: The schema is structured around three key components: Metrics, Traces, and Events.

The OASF Extensions Registry is used to manage and track Extension names and ids (UIDs) to prevent naming collisions within the framework. When creating new extensions, you must ensure their identifiers do not conflict with existing entries in this registry.

Currently registered UIDs include:

• 999: Reserved for dev (Development schema extensions).
• 998: Reserved for example (Reference extension located at schema/extensions/example).

OASF is built around several key abstractions:

• Record Object: The primary data structure used to represent collections of information and metadata relevant to agentic AI applications.
• Skills: Annotations applied to records to enable effective announcement and discovery of specific agent capabilities.
• Domains: Annotations applied to records to categorize them within specific functional areas.
• Modules: A flexible mechanism used to extend records with additional information in a modular and composable way.

These concepts allow for a standardized yet extensible way to describe agentic content.

The AGNTCY Observability Data Schema organizes observability data into three primary categories to support Multi-Agent System (MAS) monitoring:

1. Metrics: Quantitative measurements of system performance and behavior (e.g., collaboration success rates, response times).
2. Traces: Spans and paths representing the flow of requests and interactions through the agentic system.
3. Events: Discrete occurrences or state changes within the system.

A module should override its data field with a reference to its own specific payload object.

Requirement: The dictionary entry for that payload object must be self-typed. This means the type in the dictionary must match the object's own name (e.g., if the object is observability_data, the dictionary entry must be observability_data). If this entry is missing, the reference will not resolve, data will silently fall back to string_t, and the schema will fail to compile.

An OASF extension must mirror the core schema directory layout. A directory is recognized as an extension if it contains an extension.json file.

Directory Layout

Extension entities use a namespaced key format: <extension_name>/<entity_name>.

Crucial Rule: When one extension entity references another, you must include the extension name prefix. Unqualified references (e.g., using extends: "example_verticals" instead of extends: "example/example_verticals") will fail to resolve to a category and will default to category 0.

Example Name Construction: The full name is the category path followed by <extension_name>_<class_name>. For an extension named example with a class cold_chain_logistics inside the example_verticals category, the name is: example/example_verticals/example_cold_chain_logistics.

The OASF Schema Server is an HTTP server built with Elixir and Phoenix that allows you to browse and use the OASF schema. To run it locally, you must first install the required Elixir build tools, fetch dependencies, and compile the source code.

Prerequisites

Ensure Elixir is installed on your system.

# Install build tools
mix local.hex --force && mix local.rebar --force

# Navigate to server directory and install dependencies
cd server
mix do deps.get, deps.compile

# Compile source
mix compile

The Directory MCP Server allows LLMs (in IDEs like Cursor) to assist in creating valid OASF records. It provides tools and prompts for:

• Schema Discovery: Querying schema versions and navigating the domains/skills taxonomy.
• Record Generation: Automatically generating complete OASF records from your codebase.
• Validation: Checking records against the schema and iteratively fixing errors.
• Format Conversion: Importing from MCP/A2A formats and exporting to other formats with automatic enrichment.

Setup Steps:

1. Install the Directory MCP Server (refer to its specific README).
2. Configure your IDE (e.g., add to ~/.cursor/mcp.json).
3. Use natural language prompts like "Create an OASF record for this project" or "Validate this OASF record and fix any errors".