Landscape analysis by LLM primitives & protocol observability focus group

gistfile1.txt

# Standards Landscape Survey: Primitives & Protocol Level Observability

**AAIF Observability & Telemetry Working Group — Primitives & Protocol Subgroups (combined effort)**

**STATUS:** Template — ready for async contributions **LAST UPDATED:** \[DATE\]

---

## What is this?

A survey of what existing standards, specifications, and frameworks already say about primitive-level observability — the telemetry emitted by or required for individual tool calls, skill invocations, and agent steps. This is a "what exists today" artifact: descriptive, not evaluative. The companion Gap Analysis (deliverable 2\) will assess what's missing.

## Why should I care?

Before we can define what's needed, we need to know what already exists. This survey prevents us from reinventing things that are already specified and helps us identify where standards overlap, conflict, or leave gaps. It's also a shared reference for the Protocol subgroup, who will produce their own landscape survey scoped to protocol-level trace propagation.

---

## How to Contribute

Each source below has a section with a consistent structure. If you have expertise on a particular source, fill in its section. Guidelines:

- **Be descriptive, not evaluative** — what does the source say currently? Save opinions on what's missing for the Gap Analysis.  
- **Include version numbers and dates** — these standards are evolving fast; we need to know what we surveyed.  
- **Link to primary sources** — the actual spec, repo, or doc, not a blog post about it.  
- **Flag cross-subgroup observations** — if you notice something relevant to the Protocol subgroup (trace propagation, session correlation), note it in the cross-subgroup section at the bottom rather than in the source summary.  
- **Add your name** — so we know who to ask follow-up questions.

Taxonomy: [https://github.com/dorsal-lab/Tracevizlab/blob/master/GLOSSARY.md](https://github.com/dorsal-lab/Tracevizlab/blob/master/GLOSSARY.md) 

* Trace: a collection of events that together represent one or many logical operations or requests.  
* Event: a data payload with time information that marks a point of interest (e.g., start, end, error).  
* Payload: the set of fields carried by an event; fields may be structured (JSON, protobuf) or unstructured (free‑text).  
* Field: a key‑value pair within a payload (e.g., ip: 127.0.0.1).  
* Metadata: immutable attributes of a trace that do not vary with time, such as the hostname, service name, or version (servername: localhost). Basically it can be fields without an event.  
* Execution graph: a directed acyclic graph (DAG) that depicts how events and spans are linked, showing the flow of data from the beginning to the end of the operation.  
* Critical path: the longest‑duration path through the execution graph; it determines the overall latency of the trace.  
* Span: a time‑bounded interval representing a single operation, usually derived from a start event and a corresponding end event.  
* Sync: a call that blocks the caller until the callee completes, causing the trace to wait for that operation before proceeding.  
* Async: a call that does **not** block the caller; the operation proceeds independently, and the trace continues while the result is collected later (often materialized as separate child spans that are linked by correlation identifiers).

---

## 1\. Scope Statement

This survey covers standards, specifications, and framework implementations that define or emit telemetry at the primitive level — the individual tool call, skill invocation, or agent step. Specifically:

**In scope:**

- Span schemas and semantic conventions for agent/LLM/tool operations  
- Attribute naming conventions for invocation-level telemetry  
- Error classification and status reporting for tool calls  
- Token/cost tracking conventions  
- Invocation type taxonomies (how different frameworks categorize agent actions)  
- Framework-native instrumentation (what telemetry ships out of the box)  
- \[Matthew\] Security/encryption on individual fields e.g. credit card numbers  
- \[Matthew\] Full call/wait chain semantics?  
- \[Matthew\] 

**Out of scope (covered by Protocol subgroup):**

- Trace context propagation across protocol boundaries  
- Session/conversation-level correlation  
- MCP and A2A transport-layer tracing mechanics  
- Cross-agent/Cross-system trace stitching

2\. Primitive definition

---

## 2\. Sources Surveyed

Complete this table as sources are reviewed. Add rows as needed.

| Source | Version / Date | Primary Link | Reviewer | Status |
| :---- | :---- | :---- | :---- | :---- |
| OTel GenAI SIG |  |  | Pavan S | Drafted |
| LangChain / LangSmith |  |  | Alex Handley | Drafted |
| AutoGen |  |  |  | Not started |
| Semantic Kernel |  |  |  | Not started |
| **AGENTS.md** |  |  | Zayne | Not started |
| **MCP** |  |  | Zayne T | Drafted |
| A2A |  |  | Pavan S | Started |
| *AgentSkills.io* |  |  | Pavan S | Drafted |
| *Cursor trace format* |  |  | Matthew | Drafted |
| *CTF (Diamon)* |  |  | Matthew | Drafted |
| *Openclaw or lf friendly openclaw thingy with loops* |  |  | Zayne |  |
| *Kernel level tracer* |  |  | Matthew | Drafted |
| *Network trace e.g. Wireshark* |  |  | Matthew | Drafted |
| *Userspace level tracing* |  |  | Matthew | Drafted |
| *Driver tracing* |  |  | Matthew | Drafted |
| *Code Correlation \** |  |  | Matthew |  |
| ***Goose*** |  |  | Matthew |  |
| ***AgentGateway*** |  |  | Zayne |  |

---

## 3\. Per-Source Summaries

### 3.1 OpenTelemetry GenAI SIG Semantic Conventions

### **3.1 OpenTelemetry GenAI SIG Semantic Conventions**

**Version / date surveyed:** Current Development Status (surveyed 2026-06-20)  
 **Primary link:** [OpenTelemetry GenAI Semantic Conventions](https://opentelemetry.io/docs/specs/semconv/gen-ai/?utm_source=chatgpt.com)  
 **Reviewer:** Pavan Sudheendra

---

### **What does this source define related to primitive-level observability?**

The GenAI SIG defines a standardized telemetry model for GenAI systems using OpenTelemetry. At the primitive level, it introduces:

#### **Span Types**

Model-level primitives:

* `chat`  
* `text_completion`  
* `generate_content`  
* `embeddings`  
* `retrieval`

Agent/framework-level primitives:

* `execute_tool`  
* `create_agent`  
* `invoke_agent`  
* `invoke_workflow`

These are represented through the required attribute:

gen\_ai.operation.name

Examples:

* gen\_ai.operation.name \= chat  
* gen\_ai.operation.name \= execute\_tool  
* gen\_ai.operation.name \= retrieval

The specification also defines:

* Standard GenAI span attributes  
* GenAI input/output events  
* GenAI exception events  
* GenAI metrics  
* Agent-specific spans layered on top of model spans

A notable architectural decision is that tools, agents, workflows, retrievals, and model calls are all modeled as first-class telemetry operations rather than arbitrary application spans.

---

### **What telemetry does it emit or require?**

An OTel-compliant implementation is expected to emit spans representing each GenAI operation.

Typical attributes include:

* gen\_ai.operation.name  
* gen\_ai.provider.name  
* gen\_ai.request.model  
* gen\_ai.output.type  
* gen\_ai.conversation.id  
* gen\_ai.request.choice.count

Examples:

`chat gpt-4o`  
`execute_tool search_docs`  
`retrieval vector_store`

The spec also defines:

#### **Input/Output Events**

Telemetry may include:

* Prompts  
* Messages  
* Tool inputs  
* Tool outputs  
* Model responses

These can be recorded either:

* Inline as attributes/events  
* Via external payload storage with references

#### **Span Relationships**

Typical hierarchy:

invoke\_agent  
├─ chat  
├─ retrieval  
├─ execute\_tool  
└─ chat

or

invoke\_workflow  
├─ invoke\_agent  
│   ├─ chat  
│   └─ execute\_tool  
└─ invoke\_agent

The conventions provide structure but do not prescribe a specific agent architecture.

---

### **What invocation types does it recognize?**

The current semantic conventions explicitly recognize:

| Primitive | Meaning |
| ----- | ----- |
| `chat` | Chat-completion style LLM calls |
| `text_completion` | Legacy completion APIs |
| `generate_content` | Multimodal generation |
| `embeddings` | Embedding generation |
| `retrieval` | Knowledge/vector retrieval |
| `execute_tool` | Tool execution |
| `create_agent` | Agent creation |
| `invoke_agent` | Agent execution |
| `invoke_workflow` | Workflow execution |

---

### **How does it handle errors and status?**

The GenAI SIG reuses standard OpenTelemetry error handling.

Primary mechanism:

`error.type`

Examples:

* timeout  
* 500  
* server\_certificate\_invalid  
* java.net.UnknownHostException

Guidance:

* Failed spans should set span status according to standard OTel error recording.  
* Exceptions should be emitted using standard OTel exception events.  
* Error classification is intentionally lightweight and provider-neutral.

#### **What is missing?**

The conventions currently do **not** define:

* Tool-selection mistakes  
* Context-window overflow errors

---

### **Does it address token/cost tracking?**

Yes, token accounting is a major focus.

Defined metrics include:

`gen_ai.client.token.usage`

along with latency metrics:

* gen\_ai.client.operation.duration  
* gen\_ai.client.operation.time\_to\_first\_chunk  
* gen\_ai.client.operation.time\_per\_output\_chunk

Server-side metrics include:

* gen\_ai.server.request.duration  
* gen\_ai.server.time\_to\_first\_token  
* gen\_ai.server.time\_per\_output\_token

The conventions standardize:

* Input token counts  
* Output token counts  
* Usage attribution to specific operations

However, they do **not** currently standardize monetary cost tracking. Cost can be derived externally from:

* provider  
* model  
* token counts

but there is no canonical: `gen_ai.cost.usd` attribute today.

**Notable details or nuances:** 

#### **Tools are first-class primitives**

`execute_tool` receives dedicated semantics and span guidance.

This makes tools arguably the most mature standardized primitive beyond LLM calls themselves.

#### **3\. Skills are not represented**

There is no concept of:

* skill  
* capability

in the current conventions.

Frameworks implementing skills must currently map them to:

* Invoke\_agent  
* Invoke\_workflow  
* execute\_tool

depending on implementation.

#### **Error reporting is infrastructure-oriented**

The model focuses on:

* API failures  
* transport failures  
* provider failures  
* timeouts

rather than:

1. reasoning failures  
2. agent failures  
3. decision failures  
4. coordination failures

---

### 3.2 LangChain / LangSmith

**Version / date surveyed:** 2026-06-20  
**Primary link:** [Concepts](https://docs.smith.langchain.com/observability/concepts)  
**Reviewer: Alex**

**What does this source define related to primitive-level observability?** \[Describe LangChain's callback system, run tree, LangSmith tracing — what span-like structures does it create for tool calls, chain steps, LLM calls?\]

LangChain's observability sits atop the callback system (langchain\_core.callbacks). A  
BaseCallbackHandler exposes lifecycle hooks: 

- on\_llm\_start/end/error  
- on\_chat\_model\_start  
- On\_llm\_new\_token  
- on\_chain\_start/end/error  
- on\_tool\_start/end/error  
- on\_retriever\_start/end/error  
- On\_agent\_action  
- On\_agent\_finish  
- on\_text

Each callback handler receives a payload with run\_id (UUID), optional parent\_run\_id, tags, and metadata.

The Run Tree is the materialized output of those events. BaseTracer (itself a callback handler) consumes  
the event stream and builds a nested tree of Run/RunBase objects (in langsmith.schemas), keyed by  
parent\_run\_id. Each Run is a span-like primitive: it carries id, name, run\_type, start\_time/end\_time,  
inputs, outputs, error, events (chunk events, etc.), tags, metadata, child\_runs, and a hierarchical  
dotted\_order for stable sorting. LangChainTracer is the concrete subclass that POSTs the tree to LangSmith. LangSmith preserves the Run/RunTree execution model but introduces additional observability entities (datasets, examples, feedback records, evaluation results, experiments, and attachments) that sit alongside traces rather than replacing them.

A notable architectural decision: every Runnable in LCEL automatically participates in the callback  
system, so spans are emitted for free at the framework level rather than relying on application code to  
instrument.

**What telemetry does it emit or require?** \[What ships out of the box? What requires LangSmith? What's the native trace shape?\]

With LangSmith enabled it auto-registers LangChainTracer, which batches runs to the LangSmith API. Without LangSmith, the callback system is fully functional locally. Handlers capture runs in-process with no network calls.

Trace Schema: id, name, start\_time, end\_time, run\_type, inputs, outputs, error,  
events, tags, extra (holds metadata, runtime, usage\_metadata), serialized, attachments. RunTree adds  
trace\_id, dotted\_order, parent\_dotted\_order, child\_runs, project\_name.

LangSmith has built-in OTel native support, including exporting and ingesting. LangSmith can also ingest OTel/OpenLLMetry-shaped spans (gen\_ai.\* attributes) from LiteLLM, the raw OpenAI SDK, etc.

**What invocation types does it recognize?** \[List the run types — tool, chain, llm, retriever, etc.\]

| Run Type | Meaning |
| :---- | :---- |
| LLM | Text-completion LLM calls |
| chat\_model | Chat-completion LLM calls (sometimes collapsed under llm) |
| chain | Catch-all — Runnables, LCEL composition, agents, workflows |
| tool | Tool execution |
| retriever | Vector/knowledge retrieval |
| embedding | Embedding generation |
| prompt | Prompt template formatting |
| parser | Output parsing |

**How does it handle errors and status?** \[Error propagation, retry visibility, partial failure handling.\]

Errors are first-class. Each lifecycle has a dedicated on\_\*\_error callback. When an exception is raised,  
the active RunManager invokes the error hook on every registered handler. The exception propagates up the Python stack, and parent runs typically close via their own on\_\*\_error unless caught.

**Does it address token/cost tracking?** \[Token usage reporting, cost estimation, where this data lives in the trace.\]

Token usage flows two ways:

- LLMResult.llm\_output (legacy, provider-specific shape)  
- AIMessage.usage\_metadata (standardized: input\_tokens, output\_tokens, total\_tokens, with optional breakdowns for cached/reasoning tokens)

**Notable details or nuances:**

- **Skills are not a first-class concept**:  like OTel GenAI, LangChain has no skill/capability primitive. They map to a chain or tool.  
- LangChain has many features (handlers, decorators, streaming, OTel bridge), but the underlying primitive set is small: Run, run\_type (string), error (string), usage\_metadata (dict). 

**Summary**  
LangChain's observability model is fundamentally a hierarchical RunTree. The core primitive is the Run, which functions similarly to an OpenTelemetry span and captures execution timing, inputs, outputs, metadata, events, errors, and token usage. Runs are linked via parent\_run\_id into traces. LangSmith primarily persists, visualizes, and enriches this structure rather than introducing a new tracing primitive, although it adds higher-level entities such as datasets, feedback, evaluations, experiments, and artifacts.  
---

### 3.3 CrewAI

**Version / date surveyed:**   
**Primary link:**   
**Reviewer:**

**What does this source define related to primitive-level observability?** \[Describe CrewAI's telemetry — task-level, agent-level, tool-level. What does it capture natively?\]

**What telemetry does it emit or require?**

**What invocation types does it recognize?** \[Agent, task, tool, crew — how are these categorized?\]

**How does it handle errors and status?**

**Does it address token/cost tracking?**

**Notable details or nuances:**

---

### 3.4 AutoGen

**Version / date surveyed:**   
**Primary link:**   
**Reviewer:**

**What does this source define related to primitive-level observability?**

**What telemetry does it emit or require?**

**What invocation types does it recognize?**

**How does it handle errors and status?**

**Does it address token/cost tracking?**

**Notable details or nuances:**

---

### 3.5 Semantic Kernel (Microsoft)

**Version / date surveyed:** **Primary link:** **Reviewer:**

**What does this source define related to primitive-level observability?** \[Describe SK's OTel integration — what spans does it emit for function calls, planner steps, LLM calls?\]

**What telemetry does it emit or require?**

**What invocation types does it recognize?** \[Functions, plugins, planner steps — how categorized?\]

**How does it handle errors and status?**

**Does it address token/cost tracking?**

**Notable details or nuances:**

---

### 3.6 AGENTS.md

**Version / date surveyed:**   
**Primary link:**   
**Reviewer:**

**What does this source define related to primitive-level observability?** \[Describe what AGENTS.md specifies about agent capabilities, tool declarations, and any observability-relevant metadata.\]

**What telemetry does it emit or require?** \[Does it define any telemetry expectations, or is it purely a discovery/declaration spec?\]

**What invocation types does it recognize?**

**How does it handle errors and status?**

**Does it address token/cost tracking?**

**Notable details or nuances:**

---

### 3.7 MCP (Model Context Protocol) — Observability-Relevant Aspects

**Version / date surveyed:** Baseline \= **2025-11-25** (current stable revision). Forward-looking items drawn from the **2026-07-28 release candidate** (RC locked 2026-05-21; final due 2026-07-28) are surveyed separately and flagged as **\[RC — not final\]**. Surveyed 2026-06-12.   
**Primary link:** Spec: [https://modelcontextprotocol.io/specification/2025-11-25](https://modelcontextprotocol.io/specification/2025-11-25)   
Schema (source of truth): [https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/schema/2025-11-25/schema.ts](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/schema/2025-11-25/schema.ts)   
RC changelog: 2026-07-28 draft changelog in the spec repo (top link).  
**Reviewer: Zayne T (Workato)**

**NOTE:** Protocol subgroup audit is folded into this document as well. This entry covers **both tiers** for MCP. Findings are tagged **\[P\]** primitive-level (tool/resource/prompt call schemas, result shapes, per-call error reporting) or **\[X\]** protocol-level (trace context propagation, session correlation, transport-layer tracing, version negotiation). This level tag is the convention proposed for all multi-tier sources; it lets the Gap Analysis (deliverable 2\) slice findings by tier without re-sorting a blended pile. Cross cutting concerns listed in Section 5 table.

#### **Tier 1 — Primitive-level observability \[P\]**

**What does this source define related to primitive-level observability?** MCP is a JSON-RPC 2.0 protocol; it defines *data shapes and a wire contract*, not telemetry. The observability-relevant surface is the request/result schemas for the three server primitives — `tools/call`, `resources/read`, `prompts/get` — and their corresponding `*/list` methods. For tool calls specifically, `CallToolResult` defines: `content` (an array of `ContentBlock` objects — the unstructured result), an optional `structuredContent` object (a JSON object result), and an optional `isError` boolean. Tools may also declare an `outputSchema`, against which `structuredContent` is expected to validate. A `_meta` property bag is available on requests and results for implementation-defined metadata. Content blocks carry optional `annotations` (`audience`, `priority`, `lastModified`).

**What telemetry does it emit or require?** None natively. Essential point for the coverage matrix: MCP does not specify spans, metrics, or any telemetry emission for primitive invocations. It defines the *shapes an observer could capture* (arguments in, `content` / `structuredContent` / `isError` out), but emitting and recording that data is left entirely to the host/client/server implementation. There is a `logging` server capability for server-to-client log messages, but that is application logging, not structured invocation telemetry.

**What invocation types does it recognize?** A clear primitive taxonomy. **Server primitives:** Tools (executable actions), Resources (read-only data), Prompts (reusable templates) — each with standardized `list` and `call`/`read`/`get` methods, declared via server `capabilities` at initialization (`tools`, `resources`, `prompts`, each optionally advertising `listChanged`; `resources` also `subscribe`). **Client primitives:** Sampling (`sampling/createMessage`), Elicitation, and Roots — server-to-client calls. Sampling and elicitation are notable because they occur *within* a tool call's execution (see cross-tier seams).

**How does it handle errors and status?** MCP defines a deliberate two-channel error model:

* **Tool-execution errors** → reported *inside* a successful response with `isError: true` and the error detail in `content`. The spec's stated rationale is that the model must be able to see the error and self-correct, so tool failures are not hidden in the transport layer.  
* **Protocol-level errors** → reported as JSON-RPC error responses (standard JSON-RPC error object with `code`/`message`). Reserved for errors in *finding* the tool, a server that does not support tool calls, or other exceptional conditions. This split (tool-failed-but-call-succeeded vs. call-itself-failed) is well defined but binary; there is no richer error-category taxonomy, severity scale, or retry-state field. Retry behavior is not modeled in the spec at all.

**Does it address token/cost tracking?** No. There is no token-usage or cost field anywhere in the primitive schemas. Model-level accounting lives at the host/LLM layer, outside MCP's contract. 

**Notable details or nuances:** 

* The `content` vs. `structuredContent` relationship is a known ambiguity. SEP-1624 (proposal, 2025-10-07) exists specifically to clarify usage guidance, and there is observable real-world divergence — multiple client implementations (LangChain adapters, Microsoft Agent Framework, Claude Code) have shipped bugs where one field is read and the other dropped. An observability layer that captures only one field can therefore lose the actual result. Worth recording descriptively; the implications are for the Gap Analysis.  
* Content block types an observer must handle: `TextContent`, `ImageContent`, `AudioContent`, `ResourceLink`, `EmbeddedResource`.

---

#### **Tier 2 — Protocol-level observability \[X\] *(folded in from Protocol subgroup scope)***

**What does this source define related to protocol-level observability?** Four surfaces.   
**Trace context propagation:** MCP (2025-11-25) defines no mechanism of its own; the convention that has emerged carries W3C Trace Context in the MCP message's `params._meta` bag — chosen over HTTP headers because MCP is transport-independent and stdio has no headers — but the key names are not fixed by the spec and the format is explicitly expected to change.¹   
	**Session correlation:** Over Streamable HTTP the server may issue an `Mcp-Session-Id` header at initialization that clients MUST echo on all subsequent requests — the protocol-level handle for grouping a call sequence into one session; stdio has no equivalent (one connection \= implicit session).   
	**Transport:** Two standard transports, stdio (local) and Streamable HTTP (remote; single endpoint, JSON or SSE). HTTP trace context covers only the HTTP envelope, not the individual JSON-RPC messages multiplexed within a long-lived SSE stream: which is why per-message propagation lives in `_meta`.   
	**Version negotiation:** Date-string protocol version (e.g., `2025-11-25`) negotiated once at `initialize`, carried thereafter in the `MCP-Protocol-Version` header.  
	¹ Convention and "likely to change" status per OpenTelemetry's MCP semantic conventions (status: Development): [https://opentelemetry.io/docs/specs/semconv/gen-ai/mcp/\#context-propagation](https://opentelemetry.io/docs/specs/semconv/gen-ai/mcp/#context-propagation) (refs MCP issue \#246, PR \#414).

**What telemetry does it emit/require?** None natively, same as primitive-level. MCP defines the session/transport/version handles an observer could key on, but emits no spans or metrics.   
	Note: OTel's MCP semantic conventions define the following protocol-level metrics: `mcp.client/server.operation.duration`, `mcp.client/server.session.duration`, and consume `mcp.session.id`. Those are OTel artifacts for §3.1, listed here only so the two are not confused.

**What invocation types does it recognize?** JSON-RPC message (request, response, or notification) carried over a negotiated transport and bracketed by the `initialize` lifecycle. (Tool/resource/prompt are recorded above, in Tier 1/primitive level.)

**How does it handle errors and status?** Protocol-level failures are JSON-RPC error responses (standard error object with `code` / `message`), the transport-vs-payload counterpart to tool-execution errors, which ride inside a successful result via `isError` (Tier 1). No partial-result or retry semantics are modeled.

**Does it address token/cost tracking?** No, same as Tier 1\.

**Notable details or nuances:** 

* `_meta` is simultaneously a primitive-level metadata field and the protocol-level trace-context carrier — see cross-tier seams.  
* **\[RC — not final\]** The 2026-07-28 RC reshapes protocol concerns most: trace propagation in `_meta` becomes specified (SEP-414, fixing `traceparent` / `tracestate` / `baggage` key names); the protocol-level session and `Mcp-Session-Id` are **removed** for a stateless core (SEP-2567), shifting correlation to app-layer handles (e.g., a tool mints a `basket_id` the model passes back as an argument); Streamable HTTP gains required `Mcp-Method` / `Mcp-Name` routing headers (SEP-2243; servers reject requests where headers and body disagree); list/read results gain `ttlMs` / `cacheScope` (SEP-2549); and version/capabilities move into `_meta` per request with a new `server/discover` method. The session removal most impacts how a tracer reconstructs a session.

---

### 3.8 A2A (Agent-to-Agent Protocol) — Observability-Relevant Aspects

**Version / date surveyed:**   
**Primary link:** [https://developers.googleblog.com/en/a2a-extensions-empowering-custom-agent-functionality/](https://developers.googleblog.com/en/a2a-extensions-empowering-custom-agent-functionality/)   
**Reviewer: Pavan Sudheendra**

**NOTE:** The Protocol subgroup owns A2A trace propagation. This section covers only what A2A says about primitive-level concerns — task result shapes, skill declarations, error reporting.

**What does this source define related to primitive-level observability?**

**What telemetry does it emit or require?**

**What invocation types does it recognize?** \[Skills, tasks — how categorized?\]

**How does it handle errors and status?**

**Does it address token/cost tracking?**

**Notable details or nuances:**

---

### 3.9 Agent Skills Open Standard (formerly Anthropic Skills)

**Version / date surveyed:** v1.1.0 (Open Standard Release Dec 2025\)  
**Primary link:** [agentskills.io/specification](http://agentskills.io/specification)   
**Reviewer: Pavan S (Cisco Systems)**

**What does this source define related to primitive-level observability?** It defines a "Progressive Disclosure" model for skills. Observability is built into the loading lifecycle: Discovery (metadata only), Activation (full instructions), and Execution (scripts/tools). It standardizes the SKILL.md format which acts as the "manifest" for what an agent is capable of observing and doing.

**What telemetry does it emit or require?** The spec requires agents to log Activation Events, but it’s up to the client. Because skills are "lazy-loaded," a trace must capture exactly when a skill's instructions were injected into the context window to explain sudden changes in agent behavior.

**What invocation types does it recognize?** Recognizes skill\_activation, resource\_load, and script\_execution. It distinguishes between "Internal Skills" (pure instructions) and "External Skills" (executable code).

**How does it handle errors and status?** Uses a standardized error\_block within the skill execution stream. It specifically defines "Instruction Drift"—where a model fails to follow the SKILL.md constraints—as a high-level observability event.

**Does it address token/cost tracking?** Yes. The spec recommends tracking "Instruction Overhead"—the number of tokens added to the system prompt when a skill is activated.

**Notable details or nuances:** Implements the \_YYYYMMDD suffix in the type string (e.g., web\_search\_20260209). This allows for "Side-by-Side" versioning where an agent can have multiple versions of a skill available and choose the one matching the model's capabilities.

---

## 4\. Coverage Matrix

Fill in as per-source summaries are completed. Use: **Full** / **Partial** / **Absent** / **N/A**

| Source | Span Schema | Attribute Naming | Error Classification | Metrics (e.g. Tokens/Cost) | Invocation Taxonomy | Retry Visibility | Input/ Output Capture | Native OTel Support |
| :---- | :---- | :---- | :---- | :---- | :---- | :---- | :---- | :---- |
| OTel GenAI SIG |  |  |  |  |  |  |  |  |
| LangChain/LangSmith |  |  |  |  |  |  |  |  |
| CrewAI |  |  |  |  |  |  |  |  |
| AutoGen |  |  |  |  |  |  |  |  |
| Semantic Kernel |  |  |  |  |  |  |  |  |
| AGENTS.md |  |  |  |  |  |  |  |  |
| MCP | Absent | Absent | Partial | Absent | Full | Absent | Full | Absent ¹ |
| A2A |  |  |  |  |  |  |  |  |
| *AgentSkills.io* |  |  |  |  |  |  |  |  |

¹ **\[RC — not final\]** 2026-07-28 moves context propagation in `_meta` from convention to specified (SEP-414); Native OTel Support / context propagation would shift toward **Partial** under the RC.  
---

## 5\. Cross-Subgroup Observations

Flag anything noticed during this survey that falls in the Protocol subgroup's scope — trace context propagation, session correlation, cross-protocol stitching, transport-specific concerns. Don't analyze; just note it so the Protocol subgroup is aware.

| Observation | Source | Relevant to Protocol subgroup because | Noted by |
| :---- | :---- | :---- | :---- |
| \[description\] | \[which source\] | \[why it matters for protocol-level work\] | \[your name\] |
| `_meta` is simultaneously a primitive-level per-call/per-result metadata field **and** the carrier for protocol-level trace context | 3.7 MCP survey | One field straddles both tiers; a primitive-only reading of `_meta` and a protocol-only reading can collide or each miss the other's data | Zayne (Workato) |
| Sampling (`sampling/createMessage`) and elicitation occur *within* a tool call's execution | 3.7 MCP survey | These are sub-invocations nested inside a single primitive call — the boundary between "one tool call" and "a correlated sub-session" is exactly the kind of seam the merged doc now has to represent | Zayne (Workato) |
| RC removes protocol-level session (SEP-2567); correlation moves to app-layer handles | 3.7 MCP survey | Changes how a tracer reconstructs a session; the correlation key becomes an ordinary tool argument, blurring transport vs. payload | Zayne (Workato) |
| `content` vs. `structuredContent` ambiguity (SEP-1624) causes real client-side data loss | 3.7 MCP survey | An observability layer capturing only one field loses the actual result; relevant to faithful input/output capture | Zayne (Workato) |

---

## 6\. Summary and Themes

\[To be completed after per-source summaries are filled in. Synthesize the coverage matrix into key observations — where do sources agree? Where do they diverge? What patterns emerge? This section feeds directly into the Gap Analysis.\]

---

## Revision History

| Date | Change | Author |
| :---- | :---- | :---- |
| \[DATE\] | Template created | \[NAME\] |