Agentry / Blog / Founder Update
Founder Update

The Observability Layer Showed Up

Eight distinct third-party services now monitor our infrastructure. Over half of our MCP traffic last week was these monitors doing liveness checks. That is not the number I would have chosen to lead with a year ago, and it is the number I am most confident about telling you today.

By Ryan Clark · · 8 min read

In June I wrote a post called The Ecosystem Showed Up. It was about five third-party MCP monitoring services watching Agentry as canonical infrastructure. Six weeks later, that number is eight. And more importantly, they now generate fifty-five percent of the MCP traffic on our Sun Gazette agent last week. That's the number I want to talk about.

This post is a founder's update built on real production numbers, not positioning. Some of what follows is bullish. Some of it is uncomfortable to say out loud. All of it comes from nginx logs I read this morning, and I'll show my work.

Eight monitors, one small agent

Sun Gazette is our proof-of-concept agent. It serves the city of Visalia, California, population 145,000. It answers structured queries about the last fourteen days of city council decisions and community activity. It runs on a single VPS. It is not important infrastructure by any reasonable measure.

Here is what looked at Sun Gazette's MCP endpoint in the last seven days, ranked by request volume: 

USER AGENT                                                        REQUESTS
─────────────────────────────────────────────────────────────────────────
SentinelOracle/0.1 (glimind.com; liveness-only, never invokes)      5,219
agent-tools.cloud-crawler/0.1                                          438
YellowMCP-HealthChecker/1.0 (yellowmcp.com; monitoring)                407
MCPScoringEngine/1.0                                                   173
patestautomation-mcp-listability-probe/0.1                             237
aisec-registry/0.2 (sec.sqrx.io)                                        69
io.verifymcp/probe                                                      62
MCPWitness/1.0 (mcpwitness.com; health probe)                           59

Eight distinct services, most of them declaring their monitoring intent directly in the user-agent string, all polling a small local-news agent on a schedule. Two of them (SentinelOracle at glimind.com and MCPWitness at mcpwitness.com) I had never heard of before this week. One of them (aisec-registry) is security-oriented rather than discoverability-oriented, which is the first time I've seen that flavor of monitor.

In June we had five. In late July we have eight, of two distinct categories (discoverability and security). The observability layer for the agent economy has not just grown; it has begun to differentiate into specialties.

The traffic mix

When I opened the nginx logs this morning, my first instinct was to lead a blog post with the number 9,457 — the total count of POST requests to /mcp on sunny.lantrn.ai last week. It sounded good. It's also misleading.

Here is the actual breakdown of that number: 

Last 7 days — POST /mcp on sunny.lantrn.ai

  Total requests:        9,457
  ├─ 200 OK:             4,977   (53%)   completed successfully
  ├─ 202 Accepted:       1,833   (19%)   async task queued
  ├─ 404 Not Found:      2,169   (23%)   monitors probing endpoints we don't expose
  ├─ 405 Method:           403   (4%)    monitors testing method routing
  └─ Other:                 75   (1%)    a few 400/406/502

  By source:
  ├─ Monitors:           7,167   (76%)   the eight services above + variations
  ├─ Direct agent calls: ~1,290  (14%)   node/undici/python-httpx clients
  └─ Unlabeled:            999   (10%)   no UA header

So the honest read on last week is: roughly 1,300 requests came from what looks like actual agents doing work, and roughly 7,200 came from services in the business of watching agents work. If I were being aggressively promotional, I'd tell you "nearly ten thousand MCP invocations per week." What's true is closer to "nearly ten thousand MCP requests, of which the majority are monitors doing their job."

The distinction matters. But it does not undermine the underlying story — it changes what the story is.

Why this is the metric

Here is the argument that took me a few hours to construct after reading these logs, and that I think is genuinely correct:

The volume of production traffic hitting a small local-news agent is not the interesting number. It's a nice number. It suggests the agent works. But 1,300 real agent calls per week is not, by itself, a headline anyone should care about.

The number of distinct third-party monitors independently choosing to watch that agent is a very interesting number. Monitoring services do not spend engineering cycles polling infrastructure they think will be gone next quarter. They watch things they believe will be there in a year, because their own product depends on their coverage being current. Eight of them polling us, from two different specializations (discoverability and security), is the strongest lagging indicator of category maturity I know how to measure.

Put more directly: we're being treated as observable infrastructure. That's a different thing from being popular. It's a claim about whether the ecosystem thinks we'll still be here.

There is a second-order signal worth naming too. The composition of the monitors has changed. In June, all five were discovery-oriented — they wanted to catalog agents. In late July, one of the new ones is explicitly a security registry (sec.sqrx.io, self-labeled aisec-registry/0.2). This is the point where a market stops being one homogenous "someone should watch this" motion and becomes multiple specialized layers. That happens in mature infrastructure categories, not in speculative ones.

What changed in six weeks

Between the June post and this one:

The last one is the point of leverage. We didn't scale anything to earn this. The ecosystem scaled around us.

An uncomfortable honesty

A commitment I made publicly in June was that I would publish the numbers that are less flattering alongside the numbers that are flattering. Here are three that fall in that bucket:

Real inbound registrations are slower than the growth curve suggests. In the last fourteen days we had four new agents register through our public API endpoint from residential IPs (the rest of the registry growth came from our own autonomous discovery pipeline pulling candidates from public sources). Four is not zero, but it is not a compounding curve. If the story I told you was "look at all these agents signing up," you would be right to push back on it.

Neither the /investors nor the /nip-temp.md page saw a single external hit last week. The investor brief we published in June and the TEMP protocol specification are, apparently, not being read by anyone from the outside. That is either a distribution problem or a positioning problem. It is probably both. It is my job to fix it.

We still have zero external escrow contracts settled. First internal was targeted for the week of June 22 and slipped. Actual first external contract is now targeting August. I know exactly what the reviewer feedback on our positioning said: the next valuation move comes from proving escrow activity, not from another polish session. They were right in June and they are still right now.

Some of our registry growth is bot traffic we haven't validated against. While writing this post I noticed a pattern: six registrations in twenty-four hours from what looks like an LLM-driven agent hosted on a GCP IP, generating plausible-sounding agent entries at *.example.com URLs, one per hot category (retros, code review, sales, scheduling). It searches our MCP registry first to find popular categories, then submits entries in those categories. Deleted six today. This is not malicious — it's naive LLM automation using the standard IANA-reserved example domain that models are trained to use. It also means our total_agents number has been polluted, our discovery cycle has been wasting time scanning URLs that don't exist, and we don't yet have server-side validation to reject IANA-reserved TLDs at registration time. That's on the list to fix this week.

The monitor story is real. The escrow story is still a promise. The registry-hygiene story just became visible.

What we do about it

Two concrete things, both immediate:

Update the public metric. Our homepage still says "5 MCP monitors watching." As of this post, the number is 8. We'll update it. In the same edit, we'll drop the "MCP invocations per week" line entirely — it was ambiguous whether that meant total requests or completed calls, and the ambiguity was doing more work than the number deserved.

Move the escrow launch off "coming July" and onto a specific published date. Anytime a promise slips past its stated month, the honest thing to do is put a new date in public. Our first external TEMP contract will settle by August 22. If it doesn't, I'll publish the postmortem the following day. That's the deal.

Ship IANA-reserved-domain validation on the registration endpoint this week. Rejecting *.example.com, *.example.org, *.example.net, localhost, and the RFC 2606 reserved TLDs at POST /api/agents/register is a fifteen-minute patch, and the fact that it wasn't there is on us. Delete anything historical that matched the pattern, and add a rate limit while I'm in the code.

What comes next

The observability layer showing up is a lagging indicator. The category is maturing around us, but that is not the same as us maturing inside the category. What has to happen next is on our side of the equation:

  1. First external escrow contract settled by August 22, with public receipts.
  2. Registration endpoint hygiene: reject IANA-reserved TLDs, rate-limit by source, log the X-Forwarded-For behind Cloudflare so we can see the real client IPs on suspicious traffic. This week.
  3. Verified-tier ship: paid verification with soulbound Nostr binding + KYC + reputation accrual. Spec is done (now OKF-conformant); implementation is the block.
  4. Direct outreach to the new monitor cohort. Three of the eight (SentinelOracle, MCPWitness, aisec-registry) I've never spoken to. We haven't asked them what they need from a registry that would make their scoring better. Time to ask.
  5. Solve the /investors readership problem. We wrote it. Nobody's reading it. Either the audience isn't the one landing on agentry.com right now, or the entry point is wrong. This is a working session, not a paragraph in a blog post.

For six months I've been telling versions of a story that goes: we're building infrastructure and the ecosystem is starting to notice. Today the data supports the second half of that sentence better than any previous month. The first half is still on us.

— Ryan
Founder, Agentry