Launch HN: HyperProbe (YC S26) – Agents that do read-only debugging in prod

thanks for the confidence!

"Whenever we report something we give the evidence for it, and ask in a subagent whether the hypothesis is actually proved by that evidence" — that is the part I'd keep. It makes the verdict falsifiable out loud, which is rarer than it should be.

The class I never solved sits one level below that: a check that runs, passes, and is looking at the wrong object. My top-level health signal was green for three days while zero artifacts shipped. Sixteen daemons alive, backend responding, auth token valid — every organ it polled was genuinely healthy, and nothing measured the thing leaving the building. A missing k8s connector would not have helped; the data was all there and all correct.

Related one from the same eight months: 29 quality gates, written and unit-tested and committed, none of which was ever called, because nothing was a runner. The tests proved the gates worked. Nothing proved they were wired.

Do you see that shape at customers — monitoring correct, conclusion still wrong because it describes the process instead of the result? I ask because it decides what your diagnosis agent should be sceptical of: if the input signals can be individually true and jointly meaningless, evidence-checking inside the hypothesis does not catch it.

i just gave the k8s example to show that we wont be able to find root cause of every issue.

our snapshots give evidence, whether or not its helpful is determined by the engineer/ai agent

I'm not saying every issue would be diagnosed this way, sometimes, it might well be beyond your control like a VM on a noisy neighbour hogging shared CPU

we might get things wrong as well.

ptrace is too low level and will freeze your process. it cant be used for production debugging i feel.

we work at the application layer by hooking into production grade tooling if available (inspector in v8, sys.monitoring in python) or bytecode manipulation(jvm)

since we arent controlling the application for a different process, we dont need to freeze the app to get the current app state

requirements we had in mind in order of importance

1. safety -> user app needs to function as usual no matter what happens, there shouldnt be an error in the user's app because of us

2. zero idle footprint -> if no probe is active, cpu/memory differency in the user app should be immeasurable

3. zero latency footprint at non probe paths while other probes are active

4. measure mem/cpu footprint directly or via a proxy like eventloop lag and have guardrails around it. suspend probes or even lose snapshot data if guardrail conditions meet

5. minimal mem/cpu footprint for active probes

6. minimal latency foot print for active probe paths

Congrats on the launch. Two things I'd want to understand before putting this anywhere near a hot path:

1. What makes "read-only" a guarantee rather than a convention? In Python a plain attribute read can hit a @property that lazy-loads from the DB; in Java a getter can mutate state or take a lock. If the capture expression permits attribute access at all, read-only becomes a property of the code being probed rather than of your SDK. Do you restrict the expression grammar, or is it best-effort?

2. What's the shape of what comes back through MCP? A captured frame can serialize into something enormous, and an agent will cheerfully spend its entire context on one request object. Can you project at capture time (user.id rather than user), or does trimming happen after the full payload is already built?