When should an agent be allowed to merge two entities?

Two systems both contain “Cooling Pump 447.”

In one, that name refers to a product model. In the other, it refers to a specific pump installed at a customer’s site. Same label, different things.

An incorrect merge can connect a service incident affecting one unit to every unit of that model. Suddenly, a question about production risk gets a convincing answer built on a false connection.

Entity resolution encodes an assumption about the world. And once applications and agents use the graph, that assumption travels.

This is one of the questions we keep coming back to while building yggy: how far should one decision travel?

Approving “these two records describe the same thing” could mean several different things:

• Merge these specific records.

• Treat a particular identifier as authoritative within this source.

• Reuse that matching rule when new data arrives.

Each step gives the system more autonomy. Each also increases the reach of a mistake.

The same issue appears when extending an ontology. Approving a new relationship gives future extractions another way to interpret incoming data. The decision becomes part of how the system understands the next document.

Our view is that useful human oversight needs evidence and a clear scope. Otherwise, people either review the same ambiguity repeatedly or approve a rule whose consequences they haven’t seen.

We’re building toward decisions that agents can execute and humans can inspect, with human judgment carrying forward where it actually applies.

For people building agents over organizational data:
what evidence would you require before letting an agent merge entities without asking you?
Shared identifiers, source authority, multiple independent sources—or something else?