Get startedHow LiveProbe works
How LiveProbe works
Understand the control plane, runtime data path, tenancy boundary, and what a probe can and cannot do.
What LiveProbe is
LiveProbe is a live debugger built for AI coding agents. Instead of reading a stack trace or grepping logs after the fact, an agent asks LiveProbe to place a temporary, read-only probe on a line of your running service and reports back what actually happened there — not what the source suggests should happen.
There is no separate LiveProbe dashboard. Every action — creating a project, issuing a credential, placing a probe, reading its evidence — is an MCP tool call your AI client makes on your behalf, typically from a plain-language request like “list services in project acme.” The full catalog is in the MCP tool reference.
| Probe type | What it tells you |
|---|---|
snapshot | The bounded values of locals, a watch expression, or several stack frames at that line, the next time it executes. |
log | A structured debug/info/warn/error line, emitted as LiveProbe telemetry rather than through the application's own logger. |
counter | How many times that line executed, pre-aggregated in the runtime. |
metric | Count, sum, min, max, and last for a numeric path or expression over time. |
A probe is temporary by design: it carries a hit limit and a TTL, and removing it uninstalls the instrumentation on the next agent poll — see Run a probe investigation for the full lifecycle.
Request path
Human users authenticate to the hosted MCP endpoint with Clerk. The broker resolves their active organization and applies tenant, project, and environment scope. Runtime agents use separately revocable service credentials and poll the broker for probe definitions.
The MCP process never opens a direct connection to an application process. Agents initiate all broker communication over outbound HTTPS, then return sanitized events.
Resource model
| Resource | Meaning | Example |
|---|---|---|
| Organization | Clerk workspace and hard tenant boundary | Astrea Engineering |
| Project | Repository or application identity | acme |
| Environment | Independent deployment scope | production |
| Service | Independently deployed process identity | api |
A service is registered once in a project and can run in multiple environments. Credentials, heartbeats, probes, evidence, source maps, safety state, and audit events are routed by project and environment.
Runtime boundary
LiveProbe is read-only by design. Probe expressions operate on captured values using a broker-compiled bounded AST. Calls, assignment, constructors, imports, reflection, dynamic property expressions, and prototype traversal are rejected.
Node inspector breakpoints and JVM JDI breakpoints may briefly pause an executing thread. Python monitoring callbacks execute inside the target process. Safety budgets bound LiveProbe activity but do not turn it into a no-overhead profiler.
Data lifecycle
- Agents poll probe definitions roughly once per second.
- Captured values are redacted and structurally bounded in-process.
- Counter and metric samples are pre-aggregated before transport.
- Each probe retains up to 500 events; oldest events expire first.
- Probe TTL and hit limits automatically stop instrumentation.
- Removing a probe uninstalls it on the next agent poll.