In the path of every prompt

For a stretch this winter, we described what Promptster does as "MCP-based process telemetry." It was close enough to be useful and wrong enough to be worth correcting in public.

The capture mechanism isn't MCP. It's a proxy plus hooks. The combination is what makes process telemetry work, and it's worth being precise about which surface does what, because the difference is also why incumbents can't retrofit this with a feature ship.

Two surfaces, one timeline

When a candidate runs our installer, the CLI does two things at once.

It redirects the agent's API base URL at a Promptster proxy and swaps the API key for a per-session token. In Claude Code that's ANTHROPIC_BASE_URL and ANTHROPIC_API_KEY; Codex exposes the equivalent redirect, and both are supported the same way. (Cursor is the reason this is a real constraint rather than a formality: it routes agent traffic through its own backend and exposes no such redirect, so there is no path in which the hiring team's key is used or metered. That is why Promptster instruments agents, not editors — work in Cursor if you like, on Claude Code or Codex.) From that moment, every prompt the candidate sends and every response the model returns flows through us. We forward upstream with the resolved key, pipe the streaming response back, and log both turns of the conversation. The proxy sees the system prompt, the tool definitions, the model and sampling params, and the full assistant message. There is nothing about the conversation surface that's hidden from us.

It also installs the agent's native hooks where the agent exposes them. Claude Code fires PreToolUse, PostToolUse, UserPromptSubmit, Stop, and Notification. Each fires on the candidate's machine, buffers events, and streams them up. The hooks fill in the operational surface the proxy can't see: tool calls, file diffs, commands, lifecycle markers, paste and pause cadence. Agents that expose less of a hook surface produce a thinner operational layer, which the rubric marks as not collectible rather than scoring against the candidate.

Together they produce one timeline, source-tagged. source: 'proxy' for the conversation. source: 'hook' for the workflow. One event schema, one ordering, one replay.

Why the proxy is the right primary surface

A capture mechanism that lives inside an agent only sees what the agent shows it. A capture mechanism that lives in the network path sees the conversation as the model sees it. The proxy gives us four things hooks alone cannot:

Full request fidelity. The system prompt, the tool schemas, the temperature, the model. These don't surface through hooks because hooks are not the protocol the model speaks. They surface through the API. If you want to score "did the candidate scope this problem before solving it," you need to see the system prompt and the tool list the model was given. The proxy is where that lives.

Streaming responses. Claude Code uses SSE. You can't reliably reconstruct an SSE stream from after-the-fact hook events; the model's chain of thought, partial tool calls, and intermediate text don't get replayed, only the final state. The proxy pipes the stream and records it as it happens.

Billing on a meter we control. Tokens, cost, model, billing source — written at the proxy, not derived. maxBudgetUsd is enforced as a gate on the request path. A candidate who blows past the cap gets a 429 with a friendly message at the moment of overage, not after the fact when a webhook reconciles. For an HR team running 100 traditional technical assessments a quarter, predictability beats a refund.

BYOK without architecture changes. Engineering orgs that hire at scale don't want their candidate cost on our invoice. We support per-org Anthropic keys with three modes per assessment — platform key, org default, per-assessment BYOK — and the candidate's experience doesn't change. The proxy resolves the upstream key per request. The org's quota, pricing, and rate limits apply natively. Hooks have no equivalent; there is no "use your own key" for a hook.

Where the record gets written

The conversation record is produced at the proxy, on infrastructure the candidate does not run and cannot reach back into. That placement carries more weight than it first appears to, and the reason is worth spelling out.

A capture agent running on a candidate's laptop is a reporter. It watches what happened and files an account afterward, and whoever controls the machine controls the filing: the account can be edited, delayed, or quietly dropped. A proxy sitting in the request path is a different kind of object. The request has to reach us before it can reach the model at all, so the record is a byproduct of the work being possible rather than a report about it. A candidate who wants a turn to go unrecorded has to give up the turn.

Hooks are reporters, and we treat them as such. They contribute tool calls, file diffs, and command history, and they are the part of the record a determined candidate could suppress. What they cannot do is contradict the proxy record without the contradiction becoming visible. A diff with no prompt behind it, or a claimed test run with no matching command in the log, is exactly the kind of gap the review surface is built to surface.

So when a procurement officer asks how you know the transcript wasn't doctored, the answer is architectural. Nothing about the conversation layer depends on the candidate's machine being honest. Cloud-only sandbox capture can't make that claim about agent work, because it never sees the agent conversation in the first place.

What we don't capture

Worth being explicit. The proxy fires on the candidate's coding session. The hooks fire on the agent's tool surface. Neither reads the rest of the laptop. Neither watches the browser. Neither captures keystrokes outside the agent. The consent screen, which a candidate sees before the session begins, lists every event type we capture and every one we explicitly don't. Redaction tooling is built in.

Process telemetry has to be honestly bounded or it tilts into surveillance. The proxy and the hooks together let us draw a clean line: this is what happened inside the agent, replayable end to end. Nothing else.

Why incumbents can't retrofit this

Browser-based assessment platforms shipped AI features by bolting a chat pane onto a sandboxed IDE. The architecture they built years ago (candidate codes inside our environment, we record what happens) is the ceiling of what they can observe. They don't sit in front of the model. They don't capture native tool calls in the candidate's real shell.

Adding a proxy to a sandboxed IDE is not a feature. It's an architecture change that admits the sandbox was the problem. That's a hard move to make for a company whose entire moat is the sandbox.

Sitting in the path of every prompt is what lets us see the workflow, record it somewhere the candidate has no write access to, and meter what it costs. We expect the incumbents to make noise about real-environment capture before they ship it. We don't expect them to ship it soon.

That's the bet we're making. So far the architecture has earned it.