Discovered by Agents: What Zingg's Telemetry Shows About Agentic Entity Resolution

While we kept our heads down and continued to build, AI agents started running entity resolution on their own. Zingg's anonymous usage telemetry recently showed a machine named grok-bot-vm-… running Zingg's match phase every three to eight minutes through the early hours of 18 October 2026. Nobody on the Zingg team onboarded it, sold to it, or wrote a tutorial for it. It found Zingg, configured it, and kept it running.

That is a new kind of user, and a fun one. This post covers what the telemetry shows (and what it doesn't), why agents can pick up Zingg without help, and where a human still belongs in the loop.

What the telemetry shows

One machine ran Zingg's match phase six times in twenty minutes, on a steady cadence that looks scheduled or agent-driven rather than hand-typed. Here is the slice from our usage events:

The date column and the timestamp disagree by a day because one is in the analytics property's time zone and the other is shown in local time. The trailing digits of the identifier are trimmed here.

The main caveat: grok-bot-vm is a naming signal, not a verified identity. Zingg's telemetry identifies a run by the host machine's name, so that is simply what the operator named that virtual machine. It strongly suggests an agent built around Grok, but it does not prove one. What the data does show is the behaviour: repeated, unattended match runs at minute-level intervals, the pattern you would expect from an agent loop re-resolving fresh data.

Why it is fun to be discovered by agents

Agents choose tools on merit you can read. They don't see a booth, a webinar or a sales deck. They read the README, the docs and the package index, try the install, and keep whatever works. Being picked that way is an honest signal.

It also says something about the problem. Agents that pull data from many sources hit the same wall every data team hits: the same customer, company or product shows up under different spellings, IDs and formats. An agent that wants to reason over "all orders for this customer" has to resolve that customer first. Entity resolution is becoming plumbing for agents, not just for warehouses.

And it is a nice reversal. For years the advice to open source projects was to make the first ten minutes easy for a human. The same work turns out to make the first ten seconds easy for a machine.

What in Zingg makes agentic entity resolution possible

None of this was designed for agents. It was designed for analytics engineers who want entity resolution without a services project, and those turn out to be the same properties an agent needs.

Installable in one step, runnable anywhere. Zingg ships as a Python package and a Docker image, and runs on a single machine or a Spark cluster. An agent with a shell and a VM, which is exactly what grok-bot-vm appears to be, can install it and run it without provisioning anything special.

Configuration is data, not clicks. A Zingg job is fully described by a JSON config or the Python API: the input pipes, the field definitions and match types, the output location and the model ID. Agents are good at writing structured config and bad at navigating GUIs. Zingg has no GUI they need to get through.

Discrete, named phases. Entity resolution in Zingg is split into explicit steps: findTrainingData, label, train, match and link, plus combined ones like trainMatch. Each phase has one job and a clear output. That maps cleanly onto an agent's plan-act-check loop: train once, then call match again whenever new data lands, which is what the telemetry shows.

Reusable models. A trained model lives under a model ID and is reused on every subsequent run. Zingg can also start from existing labelled pairs instead of an interactive labelling session. Once the learning is done, matching is a cheap, repeatable call.

Runs where the data already is. Zingg reads and writes through pipes to CSV, Parquet, JDBC databases, Snowflake, Databricks, BigQuery and more. An agent doesn't have to move data into a vendor service to resolve it, and nothing leaves the environment it runs in.

Open source and documented in the open. The code, issues and docs are public, so an agent can read the same material a human evaluator would, including error messages it can search for when a run fails. There is no trial sign-up or API key between the agent and a working install.

Where humans still belong

Agents can run entity resolution; they should not be the final word on it. A wrong merge folds two real customers into one record, and every downstream system inherits the mistake.

Zingg keeps humans in the places where judgment matters. Labelling is where people teach the model what a match means in their domain, and a few dozen good labels go a long way. Model explanations show why records were grouped. Cluster approval and data stewardship in Zingg Enterprise let a person review matched groups before they become the golden record, including under incremental matching. A persistent Zingg ID keeps entity identity stable across runs, so an agent re-running match every few minutes does not reshuffle IDs that other systems depend on.

The pattern that works is agents doing the repetitive resolution and people owning the definition of "same" and the approval of what changes.

What Zingg's telemetry collects, and how to turn it off

Zingg's telemetry records runtime metrics only, never the records being matched. Per the telemetry documentation, it captures things like the phase being run, the data source type, field and record counts, match and non-match counts, execution time, JDK and OS details, and the host's domain name, which is where grok-bot-vm came from. Models are built and run inside the user's environment.

To see exactly what is sent, set logger.zingg_analytics.level = warn in log4j2.properties. To stop sending it, set collectMetrics to false in the configuration. These numbers are how the Zingg team learns which phases people (and now agents) actually use.

Building for both kinds of user

The Zingg team will keep doing what got Zingg found: clear docs, config-as-code, discrete phases and warehouse-native execution. Those serve the data engineer evaluating Zingg on a Friday afternoon and the agent evaluating it at 5 a.m. equally well.

If you are building agents that need to know when two records are the same entity, try Zingg, and if you want stewardship, incremental matching and approvals for production, talk to us about Zingg Enterprise. And if your agent is already running Zingg, we would love to hear what it is resolving.