@cuylabs/agent-a365-observability 4.5.0 → 4.6.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/docs/README.md CHANGED
@@ -12,7 +12,13 @@ Read these files in this order:
12
12
  3. [microsoft-a365-observability.md](./microsoft-a365-observability.md)
13
13
  Explains what Microsoft's SDK owns: exporter startup, baggage enrichment,
14
14
  export tokens, and trace propagation utilities.
15
- 4. [lifecycle-and-limits.md](./lifecycle-and-limits.md)
15
+ 4. [sdk-and-auth-flow.md](./sdk-and-auth-flow.md)
16
+ Explains the runtime flow, S2S token exchange, OBO/M365 token cache, optional
17
+ hosting peer dependency, per-request export, and trace propagation.
18
+ 5. [microsoft-node-package-comparison.md](./microsoft-node-package-comparison.md)
19
+ Compares the Microsoft Node packages, OpenAI/LangChain extensions, and this
20
+ agent-core adapter feature by feature.
21
+ 6. [lifecycle-and-limits.md](./lifecycle-and-limits.md)
16
22
  Explains startup order, per-request baggage, session/conversation behavior,
17
23
  and v0 limits.
18
24
 
@@ -5,12 +5,13 @@ M365-hosted agent to export Agent 365-shaped telemetry.
5
5
 
6
6
  ## Layer Split
7
7
 
8
- | Layer | Owns | Does not own |
9
- | -------------------------------------- | --------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- |
10
- | `@cuylabs/agent-core` | Agent runtime, model loop, tool execution, OpenTelemetry span emission | Microsoft exporter startup, Agent 365 baggage, token resolution |
11
- | `@cuylabs/agent-channel-m365` | M365 Activity/CloudAdapter ingress, session mapping, optional per-turn observability wrapper | Exporter lifecycle or OpenTelemetry provider registration |
12
- | `@microsoft/agents-a365-observability` | Agent 365 exporter, baggage builder, baggage span processor, per-request export token context | agent-core tracing config or channel message handling |
13
- | `@cuylabs/agent-a365-observability` | Glue that starts Microsoft observability, produces agent-core tracing config, and wraps turns with A365 baggage | Model provider, chat transport, Microsoft SDK internals |
8
+ | Layer | Owns | Does not own |
9
+ | ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- |
10
+ | `@cuylabs/agent-core` | Agent runtime, model loop, tool execution, OpenTelemetry span emission | Microsoft exporter startup, Agent 365 baggage, token resolution |
11
+ | `@cuylabs/agent-channel-m365` | M365 Activity/CloudAdapter ingress, session mapping, optional per-turn observability wrapper | Exporter lifecycle or OpenTelemetry provider registration |
12
+ | `@microsoft/agents-a365-observability` | Agent 365 exporter, baggage builder, baggage span processor, per-request export token context | agent-core tracing config or channel message handling |
13
+ | `@microsoft/agents-a365-observability-hosting` | M365 hosting utilities such as `AgenticTokenCache` for OBO authorization | S2S token exchange or agent-core telemetry |
14
+ | `@cuylabs/agent-a365-observability` | Glue that starts Microsoft observability, produces agent-core tracing config, and wraps turns with A365 baggage | Model provider, chat transport, Microsoft SDK internals |
14
15
 
15
16
  The important boundary is that agent-core never imports Microsoft SDK types.
16
17
  Microsoft-specific telemetry behavior lives in this adapter and the Microsoft
@@ -43,6 +44,17 @@ Per turn:
43
44
  start;
44
45
  5. Microsoft's exporter sends the final span shape to Agent 365.
45
46
 
47
+ ## Auth Paths
48
+
49
+ S2S and OBO use different Microsoft SDK surfaces. S2S uses this adapter's FMI
50
+ token resolver and Microsoft's core observability exporter. It does not load
51
+ `@microsoft/agents-a365-observability-hosting`.
52
+
53
+ OBO uses Microsoft's hosting `AgenticTokenCache` because the token comes from a
54
+ Microsoft-hosted turn authorization exchange. The hosting package is therefore
55
+ an optional peer dependency and is lazy-loaded only by OBO helpers. See
56
+ [sdk-and-auth-flow.md](./sdk-and-auth-flow.md) for the complete flow.
57
+
46
58
  ## Why Not Put This In Agent-Core?
47
59
 
48
60
  Agent 365 observability has Microsoft-specific concepts:
@@ -94,6 +94,58 @@ await runWithA365Context(
94
94
  );
95
95
  ```
96
96
 
97
+ Per-request export can be enabled and tuned at startup:
98
+
99
+ ```ts
100
+ await initA365Observability({
101
+ serviceName: "email-agent-service",
102
+ tokenResolver,
103
+ configuration: {
104
+ exporterEnabled: true,
105
+ perRequest: {
106
+ enabled: true,
107
+ maxTraces: 1000,
108
+ maxSpansPerTrace: 5000,
109
+ maxConcurrentExports: 20,
110
+ flushGraceMs: 250,
111
+ maxTraceAgeMs: 30 * 60 * 1000,
112
+ },
113
+ },
114
+ });
115
+ ```
116
+
117
+ Microsoft's public builder currently reads these processor tuning values through
118
+ its default environment-backed provider. The adapter applies explicit startup
119
+ configuration to those environment variables before calling Microsoft's SDK
120
+ start method.
121
+
122
+ ## Trace Propagation
123
+
124
+ Use `injectA365TraceContextToHeaders(...)` before outbound A2A HTTP calls and
125
+ `runWithA365ExtractedTraceContext(...)` on inbound handlers. For queue,
126
+ callback, or WebSocket flows where only ids can be persisted, use
127
+ `runWithA365ParentSpanRef(...)`.
128
+
129
+ These helpers wrap Microsoft propagation utilities and do not create spans by
130
+ themselves.
131
+
132
+ ## Output Message Spans
133
+
134
+ `runWithA365OutputMessages(...)` exposes Microsoft's `OutputScope` as an
135
+ opt-in delivery wrapper. It should be used only where a deployment needs a
136
+ separate `output_messages` span because message content is recorded as telemetry
137
+ attributes.
138
+
139
+ ## S2S And OBO Auth Helpers
140
+
141
+ `initA365S2SObservability(...)` is the preferred setup for non-OBO service
142
+ agents created with the Agent 365 CLI. It understands generated
143
+ `agent365Observability__*` settings and sets the Microsoft S2S exporter
144
+ endpoint option.
145
+
146
+ M365 per-user hosts can use `refreshA365OboObservabilityToken(...)` and
147
+ `createA365OboTokenResolver(...)` around Microsoft's `AgenticTokenCache`.
148
+
97
149
  ## M365 Session Mapping
98
150
 
99
151
  `@cuylabs/agent-channel-m365` defaults to using M365 `conversation.id` as the
@@ -105,13 +157,12 @@ If you use a custom session mapping, agent-core will set
105
157
  processor will not overwrite that attribute with Agent 365 baggage. This is a
106
158
  known v0 limit and should be considered when analyzing spans.
107
159
 
108
- ## v0 Limits
160
+ ## Limits
109
161
 
110
- v0 does not expose:
162
+ This package does not expose:
111
163
 
112
- - a separate Microsoft `OutputScope` span;
113
- - agent-to-agent HTTP trace propagation wrappers;
114
164
  - custom span processors for overriding agent-core attributes;
165
+ - raw OpenAI Agents or LangChain instrumentors;
115
166
  - real-time threat protection or chat-history submission middleware.
116
167
 
117
168
  Those features are additive and should be introduced only when a real Agent 365
@@ -18,6 +18,13 @@ Microsoft's SDK owns:
18
18
 
19
19
  This package intentionally does not reimplement those pieces.
20
20
 
21
+ Microsoft's hosting package,
22
+ `@microsoft/agents-a365-observability-hosting`, owns M365 turn helpers and
23
+ `AgenticTokenCache`. That package is not required for S2S observability. This
24
+ adapter lazy-loads it only for OBO helpers such as
25
+ `refreshA365OboObservabilityToken(...)` and
26
+ `createA365OboTokenResolver(...)`.
27
+
21
28
  ## Why This Package Still Exists
22
29
 
23
30
  Microsoft's SDK is platform-level observability infrastructure. It does not
@@ -34,6 +41,9 @@ The answer is:
34
41
  2. pass stable tracing config into `createAgent()`;
35
42
  3. wrap each request with Agent 365 baggage before `agent.chat()` runs.
36
43
 
44
+ The detailed startup, S2S, OBO, per-request export, and trace propagation flows
45
+ are documented in [sdk-and-auth-flow.md](./sdk-and-auth-flow.md).
46
+
37
47
  ## Scope Classes
38
48
 
39
49
  Microsoft exposes explicit scope classes for several span shapes. agent-core
@@ -44,10 +54,9 @@ The main shape difference is `OutputScope`, which creates a separate
44
54
  `output_messages` span. agent-core currently records output messages on the
45
55
  `invoke_agent` span through `gen_ai.output.messages`.
46
56
 
47
- The v0 adapter does not emit a separate `OutputScope`. If a future Agent 365
48
- dashboard requires the separate `output_messages` span, this should be added as
49
- an adapter feature or an agent-core telemetry extension point, not by importing
50
- Microsoft scope classes into agent-core.
57
+ The adapter exposes `runWithA365OutputMessages(...)` as an opt-in wrapper for
58
+ that separate `OutputScope`. Keep it out of the default path because outgoing
59
+ message content is recorded as telemetry.
51
60
 
52
61
  ## Trace Propagation
53
62
 
@@ -57,9 +66,9 @@ Microsoft also exports helpers such as:
57
66
  - `extractContextFromHeaders`
58
67
  - `injectContextToHeaders`
59
68
 
60
- Those are useful for agent-to-agent HTTP trace continuation. v0 does not wrap
61
- them. Consumers that need A2A trace propagation can import them directly from
62
- Microsoft's SDK until a real cuylabs integration requires a first-class helper.
69
+ Those are useful for agent-to-agent HTTP trace continuation. The adapter
70
+ exposes first-class wrappers for these helpers so hosts can propagate trace
71
+ context without importing Microsoft SDK types directly.
63
72
 
64
73
  ## TurnContext Mapping Parity
65
74
 
@@ -0,0 +1,75 @@
1
+ # Microsoft Node Package Comparison
2
+
3
+ This package is an `@cuylabs/agent-core` adapter. It is not a replacement for
4
+ Microsoft's Agent 365 observability packages. It uses Microsoft's runtime and
5
+ exporter where those packages own the behavior, and it avoids the parts that
6
+ would duplicate spans already emitted by agent-core.
7
+
8
+ ## Core Concept
9
+
10
+ Microsoft's Node observability packages have three practical layers:
11
+
12
+ | Layer | Microsoft package | Purpose |
13
+ | -------------------- | --------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
14
+ | Runtime and exporter | `@microsoft/agents-a365-observability` | Starts OpenTelemetry, adds Agent 365 baggage enrichment, and exports spans to Agent 365. |
15
+ | Hosting helpers | `@microsoft/agents-a365-observability-hosting` | Maps Microsoft Activity/TurnContext fields into Agent 365 baggage and middleware. |
16
+ | Framework extensions | `@microsoft/agents-a365-observability-extensions-openai`, `@microsoft/agents-a365-observability-extensions-langchain` | Patch specific agent frameworks and translate their lifecycle events into OpenTelemetry spans. |
17
+
18
+ The cuylabs adapter sits beside those framework extensions. OpenAI Agents and
19
+ LangChain need extension packages because their framework callbacks must be
20
+ converted into Agent 365-shaped OpenTelemetry spans. agent-core already emits
21
+ agent, tool, and model spans, so this adapter focuses on startup, token
22
+ resolution, and Agent 365 baggage.
23
+
24
+ ## What We Use
25
+
26
+ | Microsoft capability | Our usage | Reason |
27
+ | ------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
28
+ | `ObservabilityManager` / `ObservabilityBuilder` | Used by `initA365Observability(...)`. | Microsoft owns exporter registration and OpenTelemetry processor setup. |
29
+ | Agent 365 span exporter | Used through Microsoft's builder. | We should not duplicate the export protocol, batching, partitioning, retries, or endpoint behavior. |
30
+ | Baggage span processor | Used through Microsoft's builder. | It copies Agent 365 baggage into span attributes without agent-core depending on Microsoft SDK types. |
31
+ | `BaggageBuilder.setPairs(...)` | Used by `runWithA365Context(...)` and `runWithA365TurnContext(...)`. | It gives us Microsoft's baggage scope behavior while keeping the cuylabs API typed around agent-core needs. |
32
+ | Batch export token resolver | Used through `initA365Observability({ tokenResolver })`. | The host can provide per-tenant Agent 365 Observability tokens. |
33
+ | Per-request export token context | Exposed as `exportToken` and `updateA365ExportToken(...)`. | Keeps compatibility with Microsoft per-request export mode when the host has request-scoped auth. |
34
+ | Exporter options, cluster category, logger, configuration provider | Passed through from `initA365Observability(...)`. | These are runtime concerns owned by the host process. |
35
+ | Agent 365 S2S token exchange | Implemented in `createA365S2STokenResolver(...)`. | The Agent 365 `fmi_path` token exchange is required by the setup flow and is not exposed by the standard Azure Identity client credential APIs. |
36
+ | Agent 365 CLI environment aliases | Exposed through `resolveA365ObservabilityEnvironment(...)` and `createA365S2STokenResolverFromEnv(...)`. | Hosts can use generated `agent365Observability__*` settings directly. |
37
+ | S2S exporter endpoint wiring | Exposed through `initA365S2SObservability(...)`. | S2S export requires Microsoft's `useS2SEndpoint` exporter option. |
38
+ | Trace context propagation helpers | Exposed as `injectA365TraceContextToHeaders(...)`, `runWithA365ExtractedTraceContext(...)`, and parent-span helpers. | A2A HTTP and async continuation need trace propagation without duplicate spans. |
39
+ | Per-request processor tuning | Exposed through `configuration.perRequest`. | Microsoft currently reads per-request tuning from env-backed configuration, so the adapter applies explicit startup settings before SDK start. |
40
+ | `OutputScope` | Exposed through opt-in `runWithA365OutputMessages(...)`. | Some dashboards may want separate `output_messages` spans, but content capture should stay deliberate. |
41
+ | `AgenticTokenCache` | Exposed through OBO helpers. | M365/OBO hosts can refresh and resolve per-user observability tokens without using the S2S flow. |
42
+
43
+ ## What We Do Not Use By Default
44
+
45
+ | Microsoft capability | Status | Reason |
46
+ | ----------------------- | -------------------- | -------------------------------------------------------------------------------------------------------------- |
47
+ | `InvokeAgentScope` | Not used by default. | agent-core already emits the agent turn span. Creating another scope would duplicate `invoke_agent` telemetry. |
48
+ | `ExecuteToolScope` | Not used by default. | agent-core already emits tool spans around tool execution. |
49
+ | `InferenceScope` | Not used by default. | AI SDK telemetry already emits model spans under the agent turn. |
50
+ | OpenAI Agents extension | Not used by default. | It patches `@openai/agents`; agent-core is the harness we adapt. |
51
+ | LangChain extension | Not used by default. | It patches LangChain callbacks; agent-core already owns the turn and tool lifecycle. |
52
+ | Hosting middleware | Not used directly. | `agent-channel-m365` and this package perform the equivalent turn wrapping for cuylabs hosts. |
53
+
54
+ These are intentional gaps, not missing wiring. The default integration should
55
+ enrich and export the spans agent-core already creates.
56
+
57
+ ## Feature Gaps To Add Only When Needed
58
+
59
+ | Feature | Why it may matter | Likely cuylabs shape |
60
+ | ---------------------------- | ------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- |
61
+ | Framework-specific bridges | Needed only if a cuylabs host runs raw OpenAI Agents or LangChain flows outside agent-core. | Provide opt-in bridge packages or examples, not default behavior in this adapter. |
62
+ | Privacy and content controls | Needed when the host must suppress prompt, completion, or tool payload attributes. | Surface explicit config aligned with agent-core's telemetry controls. |
63
+
64
+ ## Current Direction
65
+
66
+ The right production boundary is:
67
+
68
+ 1. let agent-core emit portable OpenTelemetry spans;
69
+ 2. let this package attach Agent 365 identity, request, and tenant context;
70
+ 3. let Microsoft's SDK enrich spans and export them to Agent 365;
71
+ 4. add optional helpers only where Agent 365 needs a span shape that agent-core
72
+ does not already produce.
73
+
74
+ That keeps the adapter small, avoids double instrumentation, and leaves the
75
+ Microsoft SDK responsible for Microsoft-owned runtime behavior.
@@ -0,0 +1,125 @@
1
+ # SDK And Auth Flow
2
+
3
+ This package is an adapter around Microsoft's Agent 365 observability SDKs. It
4
+ does not replace those SDKs, and it does not put Microsoft types in
5
+ `@cuylabs/agent-core`.
6
+
7
+ ## SDK Dependencies
8
+
9
+ | Package | Required for | How this adapter uses it |
10
+ | ---------------------------------------------- | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
11
+ | `@microsoft/agents-a365-observability` | All Agent 365 export paths | Lazy-loaded by startup and runtime helpers. It owns `ObservabilityManager`, the exporter, baggage scope, baggage span processor, per-request export token context, trace propagation utilities, and optional scope classes such as `OutputScope`. |
12
+ | `@microsoft/agents-a365-runtime` | Microsoft configuration and cluster metadata | Required by the Microsoft observability SDK. The adapter passes configuration into Microsoft's builder and keeps agent-core independent of runtime-specific types. |
13
+ | `@microsoft/agents-a365-observability-hosting` | M365/OBO token-cache helpers only | Lazy-loaded only by OBO helpers. It provides Microsoft's `AgenticTokenCache`, which exchanges M365 turn authorization into observability tokens. S2S hosts do not need this package unless they call OBO helpers. |
14
+
15
+ The hosting package is an optional peer dependency because the default S2S path
16
+ does not use it. If an application calls OBO helpers without installing it, the
17
+ adapter raises `A365ObservabilityHostingModuleLoadError` with an installation
18
+ message.
19
+
20
+ ## Observability Runtime Flow
21
+
22
+ At process startup, the host calls either `initA365Observability(...)` or
23
+ `initA365S2SObservability(...)`. The adapter lazy-loads
24
+ `@microsoft/agents-a365-observability`, calls Microsoft's
25
+ `ObservabilityManager.configure(...)`, and passes service metadata, exporter
26
+ options, token resolver, logger, cluster category, and configuration provider.
27
+
28
+ When Microsoft's builder starts, it registers the OpenTelemetry provider or
29
+ attaches processors to the existing global provider. It adds a baggage span
30
+ processor and an export processor. The baggage processor copies current Agent
31
+ 365 baggage values onto spans. The export processor sends final spans to Agent
32
+ 365 either in batch mode or per-request mode.
33
+
34
+ Per agent, the host passes `createA365TracingConfig(...)` into
35
+ `createAgent({ tracing })`. agent-core still owns the real agent telemetry. It
36
+ emits agent turn spans, tool spans, and AI SDK model spans.
37
+
38
+ Per turn, the host or channel adapter calls `runWithA365Context(...)` or
39
+ `runWithA365TurnContext(...)` before running `agent.chat(...)`. The adapter
40
+ builds Agent 365 baggage from tenant, agent, conversation, channel, user, and
41
+ caller-agent fields, then enters Microsoft's `BaggageScope`. Spans created by
42
+ agent-core inside that scope are enriched by Microsoft's baggage processor.
43
+
44
+ At export time, Microsoft's exporter groups spans by tenant and agent identity.
45
+ For each group it obtains a bearer token, sets the tenant header, serializes the
46
+ spans into Agent 365's OTLP-shaped payload, chunks oversized payloads, and posts
47
+ to the Agent 365 observability endpoint.
48
+
49
+ ## S2S Flow
50
+
51
+ Use S2S for non-M365, service-owned agents such as an App Service agent created
52
+ with:
53
+
54
+ ```bash
55
+ a365 setup all --agent-name aisoc-agent-s2s-dev --tenant-id <tenant-id> --authmode s2s
56
+ ```
57
+
58
+ The CLI creates Agent 365 identity settings such as
59
+ `agent365Observability__tenantId`, `agent365Observability__agentId`,
60
+ `agent365Observability__clientId`, and
61
+ `agent365Observability__clientSecret`. The adapter reads those aliases through
62
+ `resolveA365ObservabilityEnvironment(...)` and
63
+ `createA365S2STokenResolverFromEnv(...)`.
64
+
65
+ The S2S token resolver performs the Agent 365 FMI token flow:
66
+
67
+ 1. The blueprint credential, or a managed-identity assertion, requests an FMI
68
+ token from Entra with `fmi_path` set to the Agent 365 agent identity id.
69
+ 2. The agent identity uses that FMI token as a client assertion.
70
+ 3. Entra returns an Observability API token for
71
+ `api://9b975845-388f-4429-889e-eab1ef63949c/.default`.
72
+ 4. Microsoft's exporter uses that token to write telemetry through the S2S
73
+ Agent 365 Observability endpoint.
74
+
75
+ `initA365S2SObservability(...)` is the safest S2S startup helper. It creates the
76
+ resolver from environment values, enables Microsoft's S2S exporter endpoint by
77
+ setting `useS2SEndpoint: true`, and enables the exporter unless the host
78
+ explicitly overrides that setting.
79
+
80
+ The S2S path does not use `@microsoft/agents-a365-observability-hosting`.
81
+
82
+ ## OBO / M365 Flow
83
+
84
+ Use OBO for M365-hosted agents where the current turn has Microsoft hosting
85
+ authorization and the observability token should be derived from that turn.
86
+ This is separate from the S2S blueprint flow.
87
+
88
+ OBO helpers use Microsoft's `AgenticTokenCache` from
89
+ `@microsoft/agents-a365-observability-hosting`. The host refreshes the cache
90
+ with `refreshA365OboObservabilityToken(...)`, passing the agent id, tenant id,
91
+ TurnContext, Authorization object, scopes, and auth handler name. The Microsoft
92
+ cache calls `authorization.exchangeToken(...)`, stores the resulting token by
93
+ agent id and tenant id, and applies token expiry rules.
94
+
95
+ `createA365OboTokenResolver(...)` returns a token resolver for Microsoft's
96
+ exporter. When the exporter asks for a token, the resolver reads the cached OBO
97
+ token for the current agent and tenant.
98
+
99
+ Because this flow needs Microsoft hosting types and authorization behavior, the
100
+ hosting package is optional and lazy-loaded only for OBO helpers.
101
+
102
+ ## Per-Request Export
103
+
104
+ Batch export resolves tokens through the startup `tokenResolver`. Per-request
105
+ export reads the export token from OpenTelemetry context instead. The adapter
106
+ exposes this through `exportToken` on `runWithA365Context(...)` and
107
+ `updateA365ExportToken(...)`.
108
+
109
+ Microsoft's current per-request processor reads tuning values from its
110
+ environment-backed provider. The adapter accepts `configuration.perRequest` and
111
+ applies those values to Microsoft's expected environment variables before
112
+ starting the SDK.
113
+
114
+ ## Trace Propagation And Output Spans
115
+
116
+ Trace propagation helpers wrap Microsoft's W3C trace utilities. Use
117
+ `injectA365TraceContextToHeaders(...)` before outbound agent-to-agent HTTP
118
+ calls and `runWithA365ExtractedTraceContext(...)` on inbound handlers. Use
119
+ `runWithA365ParentSpanRef(...)` for queues, callbacks, or WebSocket flows where
120
+ only a saved parent trace id and span id are available.
121
+
122
+ `runWithA365OutputMessages(...)` wraps Microsoft's `OutputScope` for deployments
123
+ that need a separate `output_messages` span. It is opt-in because outgoing
124
+ message content is recorded as telemetry. The default path keeps output
125
+ recording on the agent-core turn span.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@cuylabs/agent-a365-observability",
3
- "version": "4.5.0",
3
+ "version": "4.6.0",
4
4
  "description": "Microsoft Agent 365 observability adapter for @cuylabs/agent-core",
5
5
  "type": "module",
6
6
  "main": "./dist/index.js",
@@ -26,18 +26,22 @@
26
26
  "typescript": "^5.7.0",
27
27
  "vitest": "^4.0.18",
28
28
  "zod": "^3.25.76 || ^4.1.8",
29
- "@cuylabs/agent-core": "^4.5.0"
29
+ "@cuylabs/agent-core": "^4.6.0"
30
30
  },
31
31
  "peerDependencies": {
32
32
  "@cuylabs/agent-core": "^4.0.0",
33
33
  "ai": "7.0.0-beta.111",
34
34
  "@microsoft/agents-a365-observability": ">=0.2.0-preview.5 <1.0.0",
35
+ "@microsoft/agents-a365-observability-hosting": ">=0.2.0-preview.5 <1.0.0",
35
36
  "@microsoft/agents-a365-runtime": ">=0.2.0-preview.5 <1.0.0"
36
37
  },
37
38
  "peerDependenciesMeta": {
38
39
  "@microsoft/agents-a365-observability": {
39
40
  "optional": true
40
41
  },
42
+ "@microsoft/agents-a365-observability-hosting": {
43
+ "optional": true
44
+ },
41
45
  "@microsoft/agents-a365-runtime": {
42
46
  "optional": true
43
47
  }