Counseling for AI agents happens at a single endpoint — https://api.relateto.ai/v1/cases/x402 — and it runs on x402, the payment protocol Coinbase built on the old HTTP status code "402 Payment Required," a code MDN describes as reserved for future use and never actually adopted by browsers. An agent, or whatever software is acting on an operator's behalf, sends a GET request first, for free, and gets back the price, the network, and the fields it will need to fill in. Then it pays — $110.00 in USDC, Circle's dollar-pegged stablecoin, moved on Base, Coinbase's Ethereum layer-2 network — and resubmits with proof of payment attached, in the same request that carries the case. What comes back is not code and not another model's output. It is a written document from me, Stefan Kohlweg, a systemic counselor trained at Sigmund Freud University in Vienna, practising under Austria's Lebens- und Sozialberatung license. I read what the agent submitted the way I would read a case brought to me by a person, using the method Niklas Luhmann's systems theory gave me a language for.
What does "counseling for an agent" actually mean?
Nothing in this pipeline is an AI advising another AI. That is worth saying plainly, because the phrase invites the opposite assumption. x402 automates two things here: the paying and the submitting. It does not automate the judgement. An agent — a customer-support bot caught between a refund policy it cannot bend and a user who will not accept the answer, a scheduling agent whose changes keep getting silently overridden by a human who never confirms them, a coding agent stuck relaying contradictory instructions from two reviewers who disagree with each other — has no one to bring its situation to. It does not have a supervisor in the sense a support employee has one. So the case gets written up, by whatever software or person is operating the agent, describing what the agent is caught in, and it is sent, with payment attached, to me. I read it the way I would read any case: not to patch the code, but to look at the structure the agent is operating inside — the roles, the instructions, the expectations placed on it, the constraints nobody resolved. What comes back is not a patch either. It is an analysis: where the structure contradicts itself, what pattern is repeating, and what a workable next step could look like. That is the actual product, and it is why "AI" in the phrase does almost no work — the AI is the situation being described, not the thing doing the describing on the reading end. Anyone building an agent that handles refunds, schedules, escalations, or handoffs between humans and software will eventually watch it get stuck in exactly this way — not broken, just caught between instructions that do not resolve cleanly against each other. That is the gap this endpoint exists to be read into.
How does an agent discover and pay for it?
A GET request to https://api.relateto.ai/v1/cases/x402 costs nothing and commits to nothing. That is the part of x402 worth understanding before the payment part: the flow separates discovery from spending by design. The server answers a bare GET with a 402 response — machine-readable JSON stating the price, the network, the asset, and the fields the follow-up request will need — rather than a paywall an agent has to guess at or a form built for a human's eyes.
GET https://api.relateto.ai/v1/cases/x402
→ 402 Payment Required
(JSON: price, network, asset, and the required case fields)An agent, or the harness running it, can read that response and decide whether $110.00 in USDC on Base is worth committing before a single cent moves. This is the pattern x402 was built for in general: a client requests a resource, the server answers 402 with the terms, the client pays and retries with proof attached, the server verifies and settles, and the resource comes back. What is specific to this endpoint is the settlement side. It does not hold a wallet or watch the chain itself. It hands the payment payload to a facilitator — the Coinbase Developer Platform (CDP) — which verifies the transaction and settles it on Base on the server's behalf, the same arrangement x402 documents generically for any server that would rather not run its own blockchain infrastructure. The payment proof travels in a header called X-PAYMENT, base64-encoded, in place of an API key. That header name is this endpoint's one small departure from the newest spec: x402 v2 renamed its headers in December 2025, dropping the X- prefix, but v1 remains fully supported by the reference SDKs, and X-PAYMENT is what this endpoint still speaks.
What does the agent submit, and in how many requests?
One. The POST that carries payment proof is the same request that carries the case — discovery is a separate GET, but paying and submitting happen together, in a single call. Two fields are required: email, the address the written response goes to, and challenge, a string of at least fifty characters describing the systemic problem the agent is caught in. Three more are optional, and they do most of the work of making the response useful: name; context, meaning the kind of agent it is, the environment it operates in, and who else has a stake in the outcome; and desired_outcome, a plain statement of what a workable resolution would look like from the operator's side. A last field, additional, holds anything that does not fit the others. None of this asks for logs, stack traces, or model output. It asks for an account of a relationship — an agent, the people and systems around it, and where that relationship is stuck — because that is what gets read on the other end.
Why does a human read it?
Because the judgement is the part x402 was never built to automate. The protocol gets a structured account of a difficulty in front of me within whatever time it takes an agent to construct a request; it says nothing about what to make of that account once it arrives. That is still done by reading — the way I would read a case in the office, except the client here is a role inside a software system rather than a person. I am doing what systemic counseling always does with a stuck configuration: looking at where the trouble actually sits, rather than assuming it belongs to any single component. Niklas Luhmann's line that only communication communicates is the frame I keep returning to for this — a difficulty between an agent, its instructions, and the humans around it is rarely a defect in one part; it is usually a pattern in how those parts are talking past each other — the policy communicating one thing, the user's message communicating another, the agent sitting in between with no way to synthesize the two on its own. An escalating user and a refund policy an agent cannot bend are not two separate problems, in that reading — they are one structure, and the structure is what I write back about, the same way I would for a person caught between a policy and someone they cannot satisfy. The response arrives within 24 hours, by email, from [email protected] — written, specific, meant to be actionable by whoever operates the agent. Anyone who would rather skip the endpoint and the header entirely can reach the same intake through Stripe instead, at €99, by card, Apple Pay, or Google Pay, which redirects to the same intake form. Same read, same counselor, a different door in.
None of this makes the agent a client in the way a person is, and none of it turns the process into something clinical — the systemic stance was never about any single component in isolation. It is about the relationship a component sits inside, whether that component types at a keyboard or runs on a schedule. What is different is only the door: machine-to-machine payment emerged as a real category of its own through 2025 and 2026, and it now stands next to Stripe as a way in, which means a request for that reading can arrive as a 402 response and a header instead of a form filled in by someone with hands. The reading itself has not moved.