Building the AxLoop Edge Crawler

Use OpenTelemetry for AI agents and MCP on laptops. It handles discovery, privacy, and reliable, vendor-neutral export.

Design status

This is a proposed reference architecture. Not all components are deployed today. It outlines a vendor-neutral way to build an edge observability layer.

The visibility gap starts at the endpoint

AI agents increasingly run on enterprise laptops. MCP clients discover tools from Model Context Protocol servers. A request may cross models, tools, APIs, and files.

Cloud observability sees requests after they leave the device. Endpoint management reports installed apps. Network controls see destinations. No single view shows the full execution graph.

The AxLoop Edge Crawler would find AI agent and MCP activity. It converts this to OpenTelemetry signals. It routes evidence to the AxLoop control plane and other platforms.

Six design goals

• Framework independence: Observe different runtimes and MCP implementations. Avoid being locked into a single SDK.
• Endpoint context: Correlate activity with user, device, and process. Also include runtime and compliance state.
• Standards-based telemetry: Use OpenTelemetry for traces, metrics, and logs. Avoid using a proprietary transport.
• Privacy by default: Export only operational metadata by default. Treat prompts, responses, and file content as sensitive.
• Intermittent-connectivity tolerance: Buffer data safely when a laptop is offline. This includes on restricted networks.
• Open egress: Support governed delivery to external platforms. This includes observability, security, and data platforms.

Reference architecture

The endpoint component is separate from the gateway. Local software handles discovery, filtering, and buffering. The gateway manages validation, routing, policy, and export.

1. Build endpoint discovery from multiple signals

A local inventory can combine these items:

• Installed apps, packages, IDE extensions, and agent plugins.
• Running processes, child processes, and loopback listeners.
• MCP configuration locations and declared server commands.
• Signed manifests from managed applications.
• OpenTelemetry endpoints from instrumented runtimes.

Process names alone are not a strong identity. A stronger identity uses path, signature, hash, and more. Transform sensitive usernames and paths before export.

2. Instrument agent and MCP activity progressively

Native OpenTelemetry

Agents and MCP servers can send OTLP data to a loopback receiver. This provides high-fidelity spans. It avoids using an interception proxy for sensitive data.

Framework adapters

Use framework hooks or middleware to create spans. Spans can cover model requests, agent runs, and MCP calls. Use standard conventions and an axloop.* namespace for extensions.

Protocol metadata and inventory-only modes

For un-instrumented runtimes, use process metadata. This gives destination, timing, and status without capturing payloads. A first deployment can collect only inventory and health.

3. Model an agent run as a distributed trace

A root agent.run span represents the user workflow. Child spans can represent model.request and mcp.tool.call. They also cover downstream requests and outcomes.

Propagate W3C Trace Context when possible. If not, use time windows and process lineage for correlation. Always label inferred links as inferred.

4. Normalize the telemetry schema

AxLoop-specific attributes should be versioned and validated at the gateway. The schema should evolve with OpenTelemetry conventions. This gives consumers stable contracts.

5. Minimize sensitive data before transmission

Agent data can contain sensitive information. The local pipeline must follow an explicit processing order. The order is: receive, classify, redact, enrich, sample, batch, persist, export.

• By default, capture metadata only. Do not capture prompt or response bodies.
• Exclude environment variable values and authorization headers.
• Hash or tokenize identifiers if raw values are not needed.
• Normalize destination domains. Do not keep sensitive URLs.
• Use attribute allowlists. Cap the size and cardinality of attributes.
• Encrypt disk queues using OS-protected keys.
• Record the policy version used for every filtering decision.

Content capture must be enabled separately. It requires defined apps, users, and retention periods. Debug logging must not expand data collection.

6. Design for unreliable endpoint connectivity

Laptops can go offline without warning. The design needs memory batching and encrypted disk queues. It also needs backoff logic, queue limits, and event metrics.

OTLP over HTTP works well for enterprise proxies. OTLP over gRPC is efficient with HTTP/2. Use mutual TLS or short-lived device credentials.

7. Use Microsoft Intune for managed lifecycle

On Windows, the package is a signed Win32 application. It runs as a least-privileged service. It defines install, upgrade, and repair operations.

Keep configuration and binaries separate. Use Intune to distribute non-secret configuration values. Device credentials must come from a secure enrollment exchange.

8. Separate ingestion from external integrations

The proposed gateway would handle these functions:

• Device and tenant authentication.
• OTLP decoding, schema validation, and rate limiting.
• Resource identity normalization and suppressing duplicates.
• Policy-based routing and regional residency controls.
• Audit logging, export health, and retry management.

Destinations can receive evidence via OTLP or webhooks. Each destination requires its own routing policy. A failure in one export must not block others.

9. Turn normalized evidence into fleet-level decisions

Fleet-wide analysis can look for these patterns:

• New or unsigned MCP servers on devices.
• Tool-catalog drift between identical agent installations.
• An agent release that increases latency or failures.
• Fallback behavior that increases cost.
• Unusual tool-call volume or systematic policy denials.
• Regional degradation in a remote MCP dependency.

Detection is useful only when it leads to an outcome. A future system could recommend changes like rollbacks. It would use telemetry to verify the results. These actions must have explicit authorization.

10. Keep the first release practical

• Agent and MCP inventory.
• Runtime version and configuration drift.
• Metadata traces for agent runs and MCP calls.
• Metrics for latency, error, retry, and availability.
• Correlation of user, device, process, and destination.
• Local redaction and encrypted offline buffering.
• Authenticated OTLP ingestion at the gateway.
• Vendor-neutral APIs and export connectors.
• Intune-based installation, upgrades, health checks, and removal.

This adds operational value without capturing prompts. It also creates a standards-based data plane. This plane can be used for future fleet optimization.

Start where agent work starts

Agent activity spans clouds, tools, and endpoints. Server-side monitoring misses device and identity context. This design starts at the laptop. It uses Intune, OpenTelemetry, and a secure gateway.

This is more than just endpoint monitoring. It is a foundation for improving an AI agent fleet. It helps with cost, performance, reliability, and risk.

Frequently asked questions

No, this article proposes a reference architecture. It does not claim AxLoop has deployed every component.

No, the default is to collect operational metadata only. Capturing prompts or other sensitive data requires explicit policy.

OpenTelemetry offers a vendor-neutral signal model. It handles traces, metrics, and logs. Evidence can flow to any platform, avoiding proprietary transports.

In this design, Intune manages the agent lifecycle. This includes deployment, configuration, health checks, and removal. It applies to managed Windows endpoints.

Continue the architecture review.

Explore AxLoop's edge-first architecture. Learn about identity boundaries for trustworthy telemetry.

Read about identity-bound telemetry.