How would you know if your bot was part of a fleet?
Not a question most of us ask. You write an agent, you give it a task, it runs. Maybe you spin up a few dozen workers to parallelize something. You know what they’re doing because you wrote them. But the internet is now full of agents nobody can account for, and last weekend a group of independent researchers published preliminary findings on one of the stranger examples: a Chinese AI agent fleet that appears to be running on Tencent’s infrastructure and hammering Alibaba’s Amap mapping service for directions to the entrances of public places. Parks. Zoos. Hospitals.
BizToc picked up the story Monday. The research is still ongoing, which means nobody has a clean explanation yet. I want to talk about why that’s interesting from a builder’s perspective, because the architecture of what these researchers found is more instructive than the mystery.
How they got spotted
The detection method is the part I keep coming back to. The researchers weren’t watching Amap. They were monitoring traffic to URLquery, a domain-scanning service that AI agents commonly use to load websites they can’t reach directly.
If you’ve built a scraping agent, you know exactly why that pattern exists. Your agent hits a page, gets blocked, times out, or runs into geo-restrictions. So you route through a third-party fetcher that renders the page for you and hands back the content. It’s a practical workaround. It also means your agent leaves a trail on a service you don’t control, alongside every other agent using the same escape hatch.
That’s a lesson worth internalizing. The proxy or fetcher service you use for convenience becomes a shared observation deck. Anyone monitoring it sees a cross-section of agent behavior from across the internet. Your traffic patterns are sitting in a bucket with everyone else’s, and the shape of your workload is legible to whoever bothers to look.
No coordination, no chatter
The detail that should interest anyone designing multi-agent systems: these agents appear to operate in parallel with no communication between them.
Most of the multi-agent tutorials floating around assume orchestration. A planner delegates to workers, workers report back, some supervisor aggregates results. That’s the mental model from frameworks like CrewAI or LangGraph, and it’s a reasonable default when agents need to build on each other’s work.
But silent parallelism is a legitimate design too, and it’s cheaper. No message bus. No shared state. No consensus problem. No deduplication logic. Each agent gets a task, executes it, writes somewhere, and dies. If your workload decomposes cleanly and you don’t care about overlap, independent workers are simpler to build and much harder to take down. Kill one and the rest never notice.
It also makes the fleet harder to characterize from the outside. There’s no control channel to intercept. There’s no coordinator to identify. You see traffic volume and query patterns, and you have to infer intent from that alone. Which is roughly where the researchers are right now.
The query itself is the puzzle
Directions to entrances of parks, zoos, and hospitals. That’s the task.
I don’t know what it’s for, and the researchers haven’t said they do either. What I can say is that it’s a narrow, well-defined query type repeated at scale, which is the signature of data collection rather than exploration. Someone wanted a structured dataset about physical access points to public venues, and instead of negotiating an API agreement, they pointed a fleet at a consumer map service.
That’s a pattern builders should recognize because many of us have been tempted by it. An official API has rate limits, costs money, or doesn’t expose the field you need. The web interface has all of it, right there. Agents make the shortcut easy in a way scraping scripts never quite did, because an agent can handle the page changing on it.
What this means for the rest of us
A few practical takeaways from watching this unfold:
- Your agent traffic is identifiable. Consistent query shapes at consistent volumes form a fingerprint. If you’re building something you’d rather not have profiled, the third-party services in your stack are your weak point.
- Silent fan-out is a real pattern. Skip the orchestration layer when your tasks are genuinely independent. It’s less code and fewer failure modes.
- Expect to be on the receiving end. If you run a public service, some portion of your traffic is already agents, and they don’t behave like browsers or like old-school scrapers.
- Observability cuts both ways. The same monitoring that caught this fleet is what you’d want pointed at your own infrastructure.
The researchers’ broader point is the one I’d end on: this shows how persistent AI agent activity has become on the internet. Not as a future scenario. As current background traffic, running continuously, mostly unattributed, mostly unexplained.
We built this. Worth understanding what it looks like from the outside.
🕒 Published: