AxLoop

Agent interaction observability

Reconstruct the story behind an AI-mediated action.

Software observability often begins after a request arrives. AxLoop starts earlier: at the edge where a user, agent, model, skill, and tool come together.

Discover today. Map next. Build toward traceable AI interactions.

Request a demo See how it works

Platform progression

Understand the interaction before trying to control it.

AxLoop's current discovery foundation answers what exists. The next step maps supported relationships. Tracing, evaluation, policy, enforcement, and audit build on that evidence.

  1. 01available now

    Discover

    What AI exists?

  2. 02near term

    Map

    What is connected?

  3. 03roadmap

    Trace

    What happened?

  4. 04roadmap

    Understand

    Did it work?

  5. 05roadmap

    Govern

    Should it have happened?

  6. 06roadmap

    Enforce

    What should happen next?

AI Interaction Trace

One evidence model for the observable path.

A future trace links the maximum supported evidence across the interaction while marking what was observed, correlated, inferred, or unavailable.

The example is product direction, not a claim that every field or interaction is currently observable.

Illustrative interaction

Update a customer record

Product direction

User

Human initiated

2

Claude Desktop

Agent

3

CRM skill

Skill

4

Salesforce MCP

Configured service

5

update_customer

Tool

Salesforce

Application

Source
Employee MacBook
Agent
Claude Desktop
Tool
update_customer
Result
Success
Latency
842 ms
Human initiated
Yes

This example shows the intended trace experience. Visibility depends on supported evidence and integrations.

The core product object

The interaction is bigger than the final API call.

Traditional monitoring may record request → application → response. An AI-mediated interaction can contain many more decisions and systems.

Not every field will be available. AxLoop's design principle is to show the strongest available evidence without turning correlation into certainty.

  1. 01Actor↓
  2. 02Intent↓
  3. 03Agent↓
  4. 04Model↓
  5. 05Skill↓
  6. 06MCP↓
  7. 07Tool↓
  8. 08Application↓
  9. 09Action↓
  10. 10Result↓
  11. 11Outcome

Available now · Native AI discovery

Discovered from operating-system evidence — no integrations required.

Running AI processes

Darwin process APIs identify supported assistants, agents, and coding tools — with process lineage, without exporting raw command lines.

What AI is active right now?

Installed AI applications

Desktop assistants, AI-native editors, local model tools, coding agents, and developer utilities — identified with versions, never executed.

What AI software exists on this device?

AI CLIs and coding agents

A detection catalog covering Claude Code, Codex, Gemini CLI, Copilot CLI, Aider, Goose, Continue, and more — expanding as the ecosystem changes.

What are developers actually using?

IDE extensions

Supported AI extensions across VS Code, Cursor, Windsurf, VSCodium, and JetBrains — from extension metadata, never source code.

How is AI embedded in the workflow?

MCP configurations

Client, server name, transport, executable identity, and source for each declaration — never env values, headers, arguments, URLs, or credentials.

Which clients declare which servers?

Local models and hardware

Model-weight formats like GGUF, SafeTensors, ONNX, and PyTorch, plus Metal, Neural Engine, CPU, and memory context on Apple silicon.

Where are models actually running?

Containers

AI workloads inside Docker, Colima, OrbStack, and Podman — discovered through local sockets without pulling env contents or mount details.

What AI runs in local containers?

MCP capability classification

Local classification of what a discovered tool appears capable of — read-only, filesystem access or mutation, shell execution, network access.

What could this tool do?

Available now · MCP discovery

MCP discovery starts before the first tool call.

An AI client can declare MCP servers through local configuration. AxLoop discovers supported declarations across Claude Desktop, Claude Code, Codex, Cursor, VS Code, Copilot CLI, and supported workspace configurations.

Configured is evidence. Connected is different evidence. That distinction matters.

Client
Which AI application owns the configuration?
Server
What MCP server name was declared?
Transport
stdio, SSE, or streamable HTTP where supported.
Executable
What safe executable identity is associated?
Source
Where did the declaration come from?

Not every MCP tool has the same risk

A read-only search tool is different from one exposing shell execution. Classification happens locally — to show what a discovered tool appears capable of doing.

  • Read-only
  • Filesystem access
  • Filesystem mutation
  • Shell execution
  • Outbound network

Process lineage

Agents don't always look like one process.

Modern coding agents spawn shell workers, Node and Python processes, and short-lived subagents — many alive only for seconds. AxLoop associates them with the parent AI application instead of thousands of disconnected records.

Agent↓Worker processes↓Execution context

Privacy before export

Collect the minimum evidence required to understand the AI estate.

Sensitive values are filtered before they reach the telemetry outbox. Privacy isn't a dashboard setting added later — it is part of the data contract.

  • Prompts or model responses
  • Source code
  • Tool input or output
  • Transcripts
  • Credentials or API keys
  • Authentication tokens
  • Environment-variable values
  • Raw command lines or arguments
  • Full workspace paths
  • Raw MCP URLs

Evidence, not guesses

Installed is not running. Configured is not connected.

These states are never collapsed. A device that stops reporting is stale — not automatically deleted. The inventory stays trustworthy.

Installed

The software exists on the device.

Running

The supported process was observed.

Configured

A supported configuration declares the component.

Present

The asset is in the current device snapshot.

Every observation has state

A reconciled inventory, not an endless stream of identical scans.

Sanitized inventory lives locally in SQLite. When nothing meaningful changed, no duplicate event. When a tool appears, a version changes, or an asset disappears — a new observation.

Designed for unreliable networks

Endpoints sleep, roam, and go offline.

A durable local outbox keeps observations queued and retried. Discovery continues even when telemetry delivery temporarily cannot.

  • Local persistence
  • Bounded batching
  • Retry state
  • Backoff
  • Lease-based delivery
  • Terminal failure handling
  • Deduplication

OpenTelemetry-native

Endpoint AI context for the systems you already operate.

AxLoop Edge
Privacy Filter
Local Inventory
Durable Outbox
OTLP
Enterprise Collector
Your Stack

AI asset discovery becomes part of the enterprise telemetry architecture — not a separate proprietary island.

One contract across the AI edge

Each platform exposes different signals. The asset model stays consistent.

The native macOS implementation is the verified foundation. Broader platform profiles are product direction, and each can collect only what its operating system safely allows.

  • macOS · available foundation
  • Windows · direction
  • iOS · direction
  • Android · direction
  • Linux / servers · direction

Built for enterprise deployment

  • Native Rust + Swift
  • SwiftUI menu-bar app
  • Privileged system daemon
  • User-session agent
  • Authenticated Unix-socket IPC
  • No open TCP listener
  • Native .pkg packaging
  • LaunchDaemon + LaunchAgent
JamfKandjiMicrosoft Intune

Lightweight by design

Endpoint agents need to earn the right to stay installed — continuous AI discovery without turning discovery itself into an endpoint problem.

  • Direct Darwin process APIs
  • Bounded filesystem reads
  • Allowlisted discovery paths
  • Digest caching
  • Differential telemetry
  • Local Unix sockets
  • No interpreted runtimes
  • Battery-aware scheduling

Current outcomes

Start with an evidence-backed view of the AI edge.

AI Asset Inventory

Supported AI applications, agents, runtimes, extensions, MCP configurations, and related infrastructure.

Shadow AI Discovery

Surface AI software that exists outside procurement or approval workflows.

MCP Inventory

Understand which supported clients declare which MCP servers.

Change Visibility

Know when new AI infrastructure appears or existing assets change.

Local AI Visibility

Identify supported local inference and model-runtime evidence.

Risk Context

Capability context for discovered MCP tools and infrastructure.

Fleet Telemetry

Export normalized endpoint state through OpenTelemetry.

What AxLoop is not

  • Another generic application monitor
  • Another MCP gateway
  • Another prompt logging platform
  • Another employee surveillance system
  • Another endpoint-management suite

Discovery is the foundation. Interaction mapping comes next; evaluation and control require reliable evidence first.

From discovery to interaction observability

First understand the interaction. Then evaluate, govern, and enforce it.

See the current product and the direction it is building toward.

Request a demo See how AxLoop works