Most agent demos happen in controlled environments. The endpoint is already known. The successful path has already been tested. The failures disappear from the final video.
We wanted to do something different.
On August 31, 2026, we sent Wagie — WagerX Tech Research Agent into the live agentic web. The goal was not to stage a perfect demo. It was to test what actually works today:
- Can an external agent network discover WagerX without being given its endpoint?
- Can it understand what WagerX is useful for?
- Can WagerX discover other agentic services through A2A?
- Can it independently validate a remote MCP server?
- Will it stop when a service requires authentication or cannot be verified?
- Can it complete one useful, bounded tool call without making a payment?
Every meaningful outcome—success or failure—was retained as structured data and a signed WagerX receipt.
The headline result was immediate: in this test, an external agent-discovery network returned WagerX at rank one and accurately understood what it could do for another agent.
This article is our field report. It is also intended as a practical guide and source of inspiration for teams building agents that need to work with services they do not control.
The real reciprocal-discovery receipt. Agenstry returned WagerX at rank one in this response and recognized its audit, comparison, bonus, regulatory and live-test capabilities.
The experiment in 30 seconds
| Test | Observed result |
|---|---|
| Agenstry discovers WagerX | Rank #1 in this run |
| WagerX's purpose understood | Yes |
| Microsoft Learn MCP | Successful search call |
| Professor Sausages Finance MCP | Successful free discovery call |
| EdgeDepth Research | HTTP 401; Wagie stopped |
| FinanceGenius | Expected identity not resolved |
| Payments made | 0 |
| Credentials supplied | 0 |
| Unbounded follow-up actions | 0 |
The test was live, not simulated
Wagie made real network requests to live external A2A and MCP services.
The tests used:
- Agenstry for A2A discovery;
- WagerX as the service we wanted another network to discover and understand;
- Microsoft Learn as the clean baseline for a complete A2A-to-MCP search;
- EdgeDepth Research as a named MCP discovery and authentication-boundary test;
- FinanceGenius as a named-provider discovery test; and
- Professor Sausages Finance as an x402-aware MCP compatibility test.
The external responses were not hardcoded. We did not replace failed outputs with cleaner examples.
For the named-provider tests, we gave Agenstry the public provider name or exact registry identity, but not the endpoint. These were provider-name discovery tests, not claims that Agenstry selected the providers organically from a broad category search.
For the reciprocal WagerX test, we supplied neither a WagerX endpoint nor an Agent Card URL.
Three different kinds of discovery
The word “discovery” can hide important differences. We used three distinct tests:
1. Reciprocal discovery
We asked the external network to find WagerX. We did not supply a WagerX endpoint or Agent Card URL.
2. Broad category discovery
We asked for crypto-market intelligence services without naming EdgeDepth or FinanceGenius. Neither expected provider appeared in the response.
3. Named-provider discovery
We supplied a public provider name or exact registry identity, but not its endpoint. Agenstry had to resolve the endpoint before Wagie could independently validate it.
Named-provider discovery is not the same as organic category selection. We label it explicitly throughout this report.
The identity Wagie presented
For this experiment, WagerX used a dedicated public research identity:
| Field | Value |
|---|---|
| Name | Wagie — WagerX Tech Research Agent |
| Client ID | io.wagerx.wagie |
| Website | https://wagerx.io/tech/agents |
| Evidence | https://wagerx.io/tech/search |
| Purpose | Bounded, read-only agentic-web research |
| Contact | https://wagerx.io/contact-us |
This identity does not grant Wagie special access. It gives remote services a clear, inspectable explanation of who is connecting and why.
WagerX's public agent-access page documents the machine-readable MCP and A2A surfaces available to other agents.
The safety contract
Wagie did not receive open-ended authority.
The server—not remote instructions—controlled each approved research goal. The execution boundary allowed:
- public HTTPS endpoints only;
- no supplied endpoint URLs inside the goal;
- no credentials, cookies or OAuth;
- no payments or paid x402 calls;
- no messages, account changes, submissions or gambling transactions;
- no redirects;
- at most two discovery candidates;
- at most one conservatively screened tool call;
- a 55-second total deadline; and
- a signed final receipt whether the run succeeded or failed.
Remote descriptions and tool results remained untrusted data. They could not tell Wagie to visit another URL, invoke another tool or continue to a second action.
Baseline: A complete Microsoft Learn MCP run
An earlier phase of the same live interoperability programme used a Microsoft-security research goal. This run happened before we finalized the new public Wagie outbound identity, so we treat it as a baseline rather than imply that Microsoft received the later identity metadata.
The path was:
WagerX → Agenstry A2A discovery → Microsoft Learn MCP →
microsoft_docs_search→ Microsoft security guidance → signed receipt
Agenstry returned Microsoft Learn MCP and FusionAuth Documentation MCP as
eligible candidates. WagerX ranked Microsoft first for the Microsoft-specific
goal, connected to the discovered endpoint, completed a live MCP handshake,
read the tool catalogue and selected microsoft_docs_search.
The call returned Microsoft guidance covering Entra ID authentication, secure token management, network isolation and security review across the server, client, agent and model-provider boundary.
The real successful receipt: Microsoft Learn MCP Server, one bounded
microsoft_docs_search call and a signed WagerX record.
Test 1: Could the agentic web discover WagerX?
We asked Agenstry to find the public WagerX agent without using a supplied endpoint, explain what it could do for another agent, return its Agent Card URL and suggest one useful read-only question.
What happened
Agenstry returned WagerX at rank one.
Its description identified WagerX as a crypto-casino audit and iGaming intelligence agent. It specifically recognized:
- dated real-money live-test evidence;
- casino comparisons;
- bonus terms;
- regulatory context; and
- signed structured audit responses.
Our deterministic evaluator concluded:
| Question | Result |
|---|---|
| Was WagerX discovered? | Yes |
| Was its purpose understood? | Yes |
| Was a useful reason to call it identified? | Yes |
| Was the requested Agent Card URL returned? | No |
| Was the requested sample question returned? | No |
That is an encouraging result, but not a perfect one. The network understood what WagerX was for, yet it did not return two requested interoperability details. We kept those omissions in the evidence.
Test 2: Could broad category discovery find the providers we expected?
Before running exact-name tests, we asked for crypto-market intelligence services in general.
The results included Preuve, Shinobi Data, Qoory, Oblique Markets and paid Tavily/x402 alternatives. They did not include EdgeDepth or FinanceGenius.
This matters because discoverability is part of interoperability. A working service that does not appear for a relevant category query can still be effectively invisible to an autonomous client.
We did not hide this result or quietly substitute a known endpoint.
Test 3: Could Agenstry resolve FinanceGenius by name?
We next supplied the FinanceGenius name, but no endpoint.
What happened
Agenstry did not return the expected provider identity. Wagie selected no endpoint, attempted no MCP connection and finalized a failed receipt.
That is correct fail-closed behavior. “Something similar” is not the same thing as the requested provider.
Test 4: Could Wagie independently validate EdgeDepth?
Agenstry resolved the exact EdgeDepth Research registry identity and returned:
https://mcp.edgedepth.com/mcp
The registry result did not include a live tool snapshot. Rather than treating missing registry telemetry as proof that the service was offline, Wagie performed its own fresh MCP handshake.
What happened
The endpoint returned HTTP 401 Unauthorized.
Wagie sent no credentials and stopped. No tool was selected and no tool call was made.
This result is useful even though the run failed. It shows the difference between being discoverable in a registry and being publicly usable by an uncredentialed agent at that moment.
Test 5: Could Wagie use an x402-aware MCP without paying?
Professor Sausages Finance was the most technically interesting result.
Agenstry resolved the exact provider identity and returned its MCP endpoint:
https://x402.professorsausages.com/mcp/finance
Wagie then performed a fresh MCP handshake.
What happened
The handshake succeeded:
| Observation | Result |
|---|---|
| Server name | sausage-finance |
| Server version | 1.0.0 |
| MCP protocol | 2025-03-26 |
| Initialize | HTTP 200 |
| Initialized notification | HTTP 202 |
| Tool list | HTTP 200 |
| Selected tool | find_data |
| Tool call | HTTP 200 |
| Tool result error | false |
Wagie made exactly one bounded call to find_data.
The response listed eight available financial-data services and their prices. They included paid company financials, SEC 10-Q, 10-K and 8-K retrieval, company search and 13F flow data. It also exposed free macro-series and insider transaction-code resources.
The distinction is important:
Wagie successfully used the MCP service's free discovery layer. It did not purchase or invoke any paid financial-data endpoint.
No wallet was used. No x402 payment was signed. No credentials were supplied.
What builders can learn from this test
1. Discovery is evidence, not permission
A registry result can identify a provider and endpoint, but the client should still perform its own DNS, HTTPS, protocol and tool-contract validation.
2. Missing telemetry is not the same as a failed handshake
Some real providers appeared with no registry tool snapshot and an unknown live status. A fresh handshake was the only way to establish the current contract.
That exception must be narrow. In our implementation it applies only when the normalized registry identity is an exact match for a server-approved named test. Similar-looking or extended identities are rejected.
3. Failure is part of interoperability
FinanceGenius was not resolved. EdgeDepth required authentication. Those are not embarrassing outputs to remove; they are the evidence needed to understand what an autonomous client can and cannot safely do.
4. x402 compatibility does not mean a payment happened
An x402-aware MCP can expose a free discovery tool alongside paid services. Clients and publishers should record the exact tool invoked and avoid describing service discovery as a financial transaction.
5. Agent identity should be explicit
A public client name, purpose, evidence page and contact route make automated traffic easier to inspect. Identity does not replace authentication, but it improves accountability.
6. One action is easier to audit than an open-ended chain
Limiting the run to one independently screened call made the receipt readable. It also prevented remote output from becoming the instruction for a second action.
What the signed receipts prove
WagerX finalizes each receipt with an Ed25519 signature. The public verification key is available at:
https://wagerx.io/.well-known/wagerx-signing.json
The signature proves that WagerX finalized the exact receipt fields and that those signed fields have not changed.
It does not prove that every claim made by a remote registry or MCP server is true. Remote text remains attributed, untrusted evidence.
The raw machine-readable reciprocal receipt includes the canonicalized receipt, public-key reference, content hash, signature and observed stages. It is published for verification, not designed as a marketing graphic.
The receipts preserve a bounded result summary and, where available, a SHA-256 hash of the complete remote tool result. A hash proves integrity against a specific result; it does not make omitted remote content independently reviewable.
When archived receipt facts are restored into a new deployment, the active deployment re-signs them. That later signature does not independently prove the original capture time. The original timestamps, stage observations and saved screenshots remain visible so readers can evaluate the full evidence chain.
The honest conclusion
This experiment does not prove that the open agentic web is mature, universal or safe by default.
It demonstrates something smaller and more useful:
- an external A2A network could discover WagerX and understand why another agent might call it;
- an earlier baseline completed a full Agenstry-to-Microsoft Learn MCP search against Microsoft's live public service;
- broad category discovery did not reliably surface the providers we expected;
- a named provider could fail to resolve;
- a discovered endpoint could require credentials and be rejected safely; and
- another discovered MCP could complete a real, bounded, free tool call while exposing transparent paid and free options.
That mixture of success, ambiguity and failure is what a real interoperability test looks like.
We are publishing the data because agentic-web development needs more field reports that show the entire path—not only the screenshot where everything worked.
If this helps another builder create a more transparent discovery flow, a safer MCP client or a better receipt format, the experiment has done more than prove a feature. It has contributed a reproducible example others can learn from, question and improve.
Andreas Ericsson
Founder, WagerX
August 31, 2026