Data Locality for AI-Driven Investigations

When an incident triggers an investigation, teammates need fast, reliable access to logs, metrics, traces, and events. Organizations that route telemetry through Edge Delta give their AI teammates native access to 22 MCP tools purpose-built for autonomous investigation. Organizations that keep data in third-party platforms force teammates to reach across platform boundaries with fewer tools, limited schema awareness, and higher latency.

This use case compares two architectures and explains why data locality at the AI agent’s primary platform improves investigation quality and speed.

Environment setup

Data flow comparison

Architecture A: Data in a third-party platform

When telemetry is stored in a third-party platform, AI teammates must cross platform boundaries to access data. The third-party MCP connector exposes a limited tool set, typically without schema discovery, query validation, or visualization capabilities.

flowchart LR
    A[Applications] --> B[Edge Delta Pipeline]
    B -->|Route| C[Third-Party Platform]
    D[Incident Trigger] --> E[AI Team Channel]
    E --> F[OnCall AI]
    F --> G[SRE Teammate]
    G -->|Query via MCP| C
    G -.->|Limited tools| H[No schema discovery]
    G -.->|No query builder| I[Syntax errors]
    G -.->|No graph tools| J[No visualization]

In this architecture, the SRE teammate must construct queries without knowing what fields or values exist in the third-party platform. If a query fails, the teammate cannot validate syntax or discover the correct field names programmatically. Cross-signal correlation requires separate queries to separate platforms, increasing latency and context window usage.

Architecture B: Data in Edge Delta

When telemetry flows through Edge Delta pipelines into the Edge Delta backend, AI teammates access data through the native Edge Delta MCP connector with 22 tools spanning schema discovery, query building, search, visualization, and pipeline management.

flowchart LR
    A[Applications] --> B[Edge Delta Pipeline]
    B --> C[Edge Delta Backend]
    D[Incident Trigger] --> E[AI Team Channel]
    E --> F[OnCall AI]
    F --> G[SRE Teammate]
    G -->|discover_schema| C
    G -->|build_cql| C
    G -->|get_log_search| C
    G -->|get_metric_graph| C
    G -->|get_pipeline_config| C

In this architecture, the SRE teammate discovers the schema first, builds validated queries, searches across all signal types with a unified query language, renders graphs to visualize trends, and can modify pipeline configurations to remediate issues.

Investigation workflow

The following is an example of how teammates investigate an incident when data is available natively in Edge Delta. The exact behavior depends on your connector configuration, teammate instructions, and incident context.

1. OnCall AI receives an incident trigger (monitor alert, PagerDuty webhook, or user request) and opens an investigation thread
2. SRE calls discover_schema with scope log to identify available fields, sample values for common fields like service.name and severity_text, and valid CQL syntax
3. SRE uses build_cql to construct a validated query from structured filters, avoiding syntax errors that waste tool calls
4. SRE searches logs with get_log_search, then correlates with metrics using get_metric_search and traces using get_trace_timeline, all using the same CQL syntax and the same facet system
5. SRE calls get_log_graph and get_metric_graph to visualize error spikes and latency trends, identifying the onset time and blast radius
6. SRE uses get_pipeline_config to inspect the affected pipeline and, if needed, uses add_pipeline_source and deploy_pipeline to remediate the issue
7. OnCall AI synthesizes findings and proposes next actions, routing low-risk changes autonomously and escalating higher-risk changes for human approval

Why data locality matters

Schema discovery enables self-orientation

The discover_schema tool returns all available field names, sample values for common fields, CQL syntax reference, and sample queries. This allows teammates to orient themselves in an unfamiliar environment without human guidance. Most third-party MCP connectors do not offer an equivalent capability, forcing the agent to guess at field names or rely on hardcoded assumptions.

Query building prevents wasted tool calls

The build_cql and validate_cql tools let teammates construct and verify queries programmatically before executing them. Without these tools, agents frequently produce malformed queries, consume tool calls on retries, and risk exhausting rate limits on third-party APIs.

Unified query language simplifies correlation

Edge Delta uses CQL across all signal types: logs, metrics, traces, patterns, and events. The same field names, the same syntax, and the same facet system work everywhere. When data lives in multiple platforms, the agent must switch between query languages (PromQL for metrics, LogQL for logs, ES|QL for Elasticsearch), increasing the chance of errors and the number of tool calls required.

Pre-aggregated data reduces context window pressure

Graph tools (get_log_graph, get_metric_graph, get_trace_graph, get_pattern_graph) return pre-aggregated time-series data that conveys trends concisely. Instead of retrieving individual log records or raw data points, the agent receives bucketed counts and aggregated values over time. This is significantly more compact than raw records, which can vary wildly in size and risk saturating the context window.

Pipeline tools enable remediation

Pipeline management tools (get_pipeline_config, add_pipeline_source, deploy_pipeline) allow teammates to move from observation to action within the same platform. When data lives in a third-party platform, the agent can observe problems but cannot remediate them without switching to a separate pipeline management interface.

Native versus third-party MCP capabilities

When to use this pattern

This architecture is most valuable when:

• Your AI teammates are the primary responders for incidents and need fast, autonomous access to telemetry data
• Your investigation workflows require correlation across logs, metrics, traces, and events
• You want teammates to remediate issues (pipeline changes) in addition to diagnosing them
• You are consolidating from multiple observability platforms to reduce operational complexity

Data tiering to third-party platforms remains appropriate for long-term archival, compliance requirements, or specialized analytics workflows that do not require real-time AI-driven investigation.

Learn more

• Edge Delta MCP Connector
• Streaming Connectors
• Cross-Platform Telemetry Investigation
• PagerDuty Incident Response Automation