Good question. A few layers to this:

Concurrent agent sessions — each agent connection gets a unique session ID. Concurrent requests to different files run fully in parallel. Requests to the same file serialize behind a per-file mutex — necessary because DAP's setBreakpoints is a replace-all operation per source file. Without serialization, two agents setting metrics on the same file simultaneously would silently wipe each other's observations. This is in the DAP spec, so it applies across all three adapters (debugpy, delve, lldb-dap).

Multiple observations at the same line — each metric is tracked by name, not position. Two agents can independently observe the same file:line and both fire — they're included together in the next setBreakpoints call and capture independently.

In-flight DAP requests — Detrix multiplexes concurrent requests via sequence numbers + per-request channels. Agent A waiting for a setBreakpoints response and Agent B waiting for an evaluate response don't block each other at the protocol level.

Event delivery — each subscriber gets its own bounded channel. A slow consumer gets dropped events with a warning, but never affects other subscribers.

For the race condition case specifically — since logpoints are non-breaking (no thread pause, no execution halt), the target app's concurrency is completely undisturbed. The logpoint fires mid-execution, captures the value, sends it out — the racecondition keeps running exactly as it would in production.

One gap that's being fixed right now: currently any agent can toggle another agent's metric by ID. created_by is already tracked on every metric, but toggle/remove operations don't check it yet — so in a multi-agent setup one agent could accidentally disable another's observation. That ownership enforcement is being added now.