Dependency Tracking

Dependency tracking systems automatically detect and catalog external calls as they are made, eliminating the need for manual configuration. This is achieved through instrumentation libraries that hook into the agent's execution framework.

• Dynamic Mapping: The dependency graph is built in real-time as the agent operates, reflecting the actual runtime behavior.
• Protocol Agnostic: Tracks calls over HTTP, gRPC, WebSocket, and custom TCP connections.
• Metadata Capture: Automatically records the hostname, port, API endpoint, and protocol for each discovered service.

The core output is a visual service map that renders dependencies as a directed graph. This provides an immediate, intuitive understanding of system architecture and failure propagation paths.

• Nodes represent services (e.g., payment-api, vector-db, weather-service).
• Edges represent calls and are annotated with metrics like latency and error rate.
• Topology Changes: The graph updates dynamically, highlighting new dependencies, deprecated calls, or changes in traffic flow.

When a dependency fails or degrades, the tracked map enables immediate blast radius analysis. Engineers can see all upstream agents and downstream services affected.

• Root Cause Isolation: Quickly determine if a system-wide issue originates from a single failing API.
• Cascading Failure Visualization: See how a timeout in a primary database call causes retries and backlog in dependent query services.
• **This is critical for Service Level Objective (SLO) management, as it directly links dependency health to user-facing reliability.

Dependency tracking is powered by and feeds into distributed tracing systems. Each external call generates a span that is part of a larger trace.

• Span Attributes: Dependency metadata (e.g., db.system="redis", http.url="https://api.example.com") is stored as span attributes, populating the dependency catalog.
• Trace Correlation: The unique trace ID links the agent's initial request through every subsequent external call, providing full context.
• Backend Integration: Spans are exported to backends like Jaeger, Grafana Tempo, or Datadog, where dependency graphs are often generated.

Tracks deviation from an approved or baseline architecture. This is essential for security and compliance in regulated environments where unauthorized external calls pose a risk.

• Baseline Comparison: Alerts when an agent attempts to call a new, unapproved API endpoint.
• Shadow IT Detection: Identifies dependencies on services not managed by the central platform team.
• License & Cost Auditing: Provides a factual inventory of all third-party SaaS APIs in use for vendor management and cost attribution.

Assigns a quantitative health score to each dependency based on aggregated telemetry, enabling proactive management.

• Score Components: Typically combines latency (P95), error rate, timeout rate, and rate limit utilization.
• Automated Alerting: Triggers alerts when a dependency's health score falls below a threshold, prompting investigation before user impact.
• Capacity Planning: Identifies dependencies that are consistently high-latency, indicating a need for optimization or scaling.

A method of observing requests as they propagate through a distributed system. For agents, it captures the end-to-end journey of a task, correlating timing and metadata from each internal step and external tool call. It constructs a visual timeline (a Trace) from individual units of work (Spans), providing the foundational context for performance analysis and root cause diagnosis when dependencies fail.

• Core Components: Traces, Spans, and Span Attributes.
• Key Benefit: Answers 'What happened?' and 'How long did each part take?' across service boundaries.

The fundamental building block of a distributed trace. A Span represents a single, named, and timed operation within an agent's workflow. In tool call instrumentation, each invocation of an external API, database query, or software tool is typically represented as its own Span.

• Contains: Start/end timestamps, operation name, status code (error/success), and key-value Attributes (e.g., tool.name="google_search", http.status_code=200).
• Purpose: Provides granular visibility into the performance and outcome of each individual dependency.

A quantitative measure of a service's behavior from the user's (or agent's) perspective. For dependency tracking, SLIs are derived from instrumented tool calls to create objective reliability metrics.

• Common Dependency SLIs:
  • Success Rate: Percentage of tool calls that complete successfully.
  • Latency: The time taken for a tool call to complete (often measured as P95 or P99).
  • Availability: The proportion of time a dependency is reachable and functional.
• Usage: SLIs are the raw measurements used to define Service Level Objectives (SLOs).

A resilience design pattern that prevents an agent from repeatedly calling a failing dependency. It functions like an electrical circuit breaker: after a defined threshold of failures (e.g., timeouts, 5xx errors), it 'trips' and fails fast for subsequent calls, allowing the downstream service time to recover.

• Three States: Closed (normal operation), Open (failing fast), Half-Open (testing for recovery).
• Observability Tie-in: The trip/reset events are critical Span Events or log entries, providing clear signals for anomaly detection and incident response.

The technique of propagating a unique trace identifier across process and network boundaries to link related operations. When an agent calls an external tool, it injects this ID (e.g., via HTTP headers like traceparent). If the external service is also instrumented, its resulting spans are sent to the observability backend with the same ID, automatically linking them into a single, cohesive end-to-end trace.

• Enables: True dependency mapping by visualizing the actual call flow between services, not just inferring it.
• Standard: Primarily implemented using the W3C Trace Context specification.

A scripted, automated test that simulates an agent's interaction with its dependencies from outside the production environment. It proactively executes predefined tool calls on a schedule to monitor for:

• Functional Correctness: Is the API returning the expected data schema?
• Availability & Latency: Is the dependency reachable, and is performance within baseline?
• Geographic Performance: How does latency vary from different cloud regions?

This provides a canary in the coal mine alerting mechanism before real users or production agents are impacted by a dependency degradation.