Why Is My AI Agent Slow? Using a Node.js Probe to Unify Model, Tool, and Service Traces

Today's teams already have logs, metrics, and APM, but the real challenge is correlating these data sources when a problem occurs. When a user reports a slow AI assistant, the latency may stem from the HTTP entry, a database query, a cache miss, a downstream RPC, or the AI model itself, and the context is often fragmented across multiple systems.

Node.js is increasingly used as a BFF, API gateway, real‑time communication layer, queue consumer, and AI orchestration layer. A single request can traverse HTTP, databases, caches, RPCs, message queues, runtime resources, and large‑model calls, turning the service into a "link aggregation layer" where issues no longer stay within a single interface.

Because Node.js relies heavily on async/await, promises, and the event loop, trace context can be lost at async boundaries, resulting in broken spans and isolated logs. Runtime health (event‑loop delays, V8 heap growth, GC spikes, CPU or thread‑pool exhaustion) also directly impacts user‑perceived latency, yet traditional logs cannot answer whether the runtime itself is healthy.

AI workloads add a new observability dimension: model latency, token usage, streaming interruptions, tool calls, and retrieval steps. Without native AI observability, developers cannot determine whether the slowdown is in the model, a tool, or business logic.

The ARMS Node.js probe addresses these problems with a single‑step integration that automatically instruments entry requests, dependencies, runtime metrics, and AI SDKs, and pushes all data to the ARMS console. It supports two main integration paths: a zero‑code pre‑load for CommonJS projects and a loader for ESM projects, as well as a programmatic API for explicit lifecycle control.

Key capabilities include:

Zero‑code pre‑load that works with Express, Koa, BFF, API gateways, and any ESM module.

Automatic instrumentation of popular frameworks and middleware, ensuring that HTTP, DB, cache, RPC, and message‑queue spans stay in a single trace.

Async context propagation using AsyncLocalStorage (fallback to AsyncHooks) to keep spans linked across promises, callbacks, and timers.

Runtime metrics such as event‑loop latency distribution, V8 heap and GC stats, CPU usage, memory, and thread‑pool size.

AI‑native observability that captures model call latency, token counts, streaming events, tool calls, and errors for OpenAI, LangChain, LangGraph, Vercel AI SDK, Anthropic, etc.

Remote dynamic configuration (sampling rates, span attribute limits, plugin enable/disable) that takes effect without restarting the service.

Full OTLP/ARMS reporting, W3C Trace Context propagation, and seamless cross‑language tracing with Java, Go, Python, and front‑end services.

Compared with pure log‑based debugging, the probe provides a unified view where logs are enriched with trace context, allowing correlation of business events with system behavior. Compared with building a custom OpenTelemetry stack, the probe offers out‑of‑the‑box integration, ARMS console dashboards, and AI‑specific plugins, reducing engineering effort. Compared with traditional APM agents, it adds ESM support, AI observability, and remote configuration.

Typical usage steps are:

Install the SDK: npm install @loongsuite/cms_node_sdk Set environment variables (ARMS_APP_NAME, ARMS_REGION_ID, ARMS_LICENSE_KEY) or use the legacy CMS_ prefix.

Start the application with pre‑load ( node -r @loongsuite/cms_node_sdk/register app.js) or ESM loader (

node --experimental-loader=@loongsuite/cms_node_sdk/import-hooks app.mjs

), or initialize programmatically via new NodeSDK({serviceName, licenseKey, regionId, workspace}).

Verify data appears in the ARMS console within a minute, showing full request topology, SQL analysis, cache metrics, AI call details, and runtime health.

The probe follows a "low‑intrusion, samplable, disable‑able, recoverable" design: it can be turned off, sampling can be adjusted, and it gracefully shuts down on SIGINT/SIGTERM, flushing buffers and restoring patches.

Target scenarios include enterprise Node.js web services, micro‑service architectures, database‑heavy applications, AI/Agent back‑ends, long‑lived workers, and any production system that requires dynamic monitoring without restarts.

In summary, the ARMS Node.js probe makes observability as easy as adding an npm package, providing a single, end‑to‑end tracing, metrics, and log pipeline that spans HTTP, dependencies, runtime, and AI layers, all manageable from the ARMS console.