The expert-network language layer: how transcript vendors are standardizing entity tagging for LLM ingestion

When an agent pulls a Guidepoint transcript excerpt referencing Databricks, an AlphaSense-Tegus filing excerpt tagging Databricks Inc. as a private company, and a Bloomberg ASKB result routing the same entity through a third feed, the agent has to decide whether these three fragments describe the same company. The citation is intact. The timestamp is intact. The redaction pass has run. And still the merge fails, because none of the three vendors has agreed on which identifier holds the entity together.

Our read is that entity resolution is the layer sitting one level beneath the citation-provenance work the expert-network category has spent the last eighteen months building. It is less visible than a source link and less legally freighted than an MNPI redaction, but it is the join key on which multi-vendor agent retrieval either compounds or fragments. The networks that adopt or publish an interoperable tagging standard become the default routing layer for agent-driven primary research. The ones that do not become a source the agent quotes once and cannot cross-reference again.

The layered stack agents actually see

A useful way to hold the problem is to see the MCP-era research stack as four layers, each of which had to be negotiated before the next became visible.

The first layer is transport. MCP itself, plus the equivalent connector standards Bloomberg, Anthropic, and OpenAI have converged on, gave agents a common way to call into a research vendor's corpus. That layer is settled enough that Guidepoint, GLG through Bloomberg ASKB, AlphaSense-Tegus, and Aiera are all shipping against it.

The second layer is citation provenance. When an agent surfaces a claim, the reader needs to know which transcript it came from, at what timestamp, from which expert, on which date. INFLXD has covered how the category has converged on citation formats specific enough to survive an investment-committee defense. That layer is not fully standardized, but it is close enough that an analyst can trace an agent claim back to a source in seconds rather than hours.

The third layer is compliance-adjacent redaction. Expert networks have spent two decades building the MNPI filtering discipline that lets a transcript be published at all. Agents inherit that filtering; they do not replace it. This layer is mature inside each vendor and largely non-interoperable across them, which is arguably correct given the divergent legal exposure of each firm.

The fourth layer, the one that is neither settled nor mature, is entity resolution. The agent has the transport, the citation, and the compliant text. It still does not know that the Databricks in the Guidepoint transcript, the Databricks Inc. in the AlphaSense filing tag, and the Databricks reference in a Tegus call are the same private-company entity, unless one of two things is true: either every vendor tagged the entity with the same identifier, or the agent has enough context to disambiguate on the fly.

Both conditions fail more often than the marketing materials suggest.

Why public-company identifiers are not the answer people assume

There is a temptation to treat this as a solved problem because public-company identifier infrastructure has existed for decades. CUSIP handles North American securities. ISIN handles international. LEI, established after the 2008 crisis, identifies legal entities across jurisdictions. PermID from LSEG is open and covers organizations, instruments, people, and events, with detailed company coverage documented publicly. FactSet Entity ID and S&P Capital IQ ID sit inside their respective ecosystems. OpenFIGI, Bloomberg-sponsored, offers a permissive-license identifier for financial instruments.

The infrastructure is real. The problem is that each identifier system was built for a different consumer with different licensing constraints, and none of them was designed to be embedded in a transcript-tagging pipeline that a third-party agent would then read across vendors.

CUSIP and ISIN carry licensing restrictions that make them awkward as public tags in agent-readable content. LEI is free and open but covers legal entities, not necessarily the operational entity an expert is discussing on a call. PermID is open and structurally well-suited, but adoption in the expert-network content layer is uneven. FactSet and S&P Capital IQ identifiers are excellent inside their respective platforms and effectively invisible outside them. OpenFIGI is strong on instruments and weaker on the entity-level questions transcript readers typically ask.

The net effect is that even for public companies, a transcript vendor that wants to publish machine-readable entity tags has to make a licensing and coverage choice that is genuinely non-obvious. The result is what one would expect: each vendor tags with whatever identifier system best fits its native workflow, and the cross-vendor merge happens either at the agent layer through fuzzy matching, or at a downstream vendor like Daloopa or FactSet through structured overlays.

Where the problem gets materially harder: private companies

Expert networks are disproportionately valuable precisely on the entities that public identifier systems handle worst. The core buyer use case for a Guidepoint or Tegus call is not confirming a fact about Apple. It is triangulating on a private company: a late-stage venture-backed enterprise, a portfolio company inside a private-equity fund, a supplier or customer that shows up in a public company's ecosystem but is itself opaque.

For these entities, the identifier landscape is materially more fragmented. PitchBook maintains its own company keys. Crunchbase maintains another set. LSEG, S&P, and FactSet each carry private-company coverage that varies in depth. Vendor-native keys, the internal company IDs each expert network assigns to entities in its own coverage universe, remain the highest-fidelity option inside a single vendor and the worst option across vendors.

The private-company entity problem is where MCP-era cross-vendor retrieval either delivers on its promise or reduces to a citation index with no join. A researcher pulling a Guidepoint call about a private cybersecurity company and an AlphaSense-Tegus call about the same company should be able to see both as evidence about a single entity. If the two transcripts tag the entity with different keys, and the agent has no shared schema to resolve them, the researcher gets two adjacent quotes and no merge.

This is a solvable problem, but the solution is neither cheap nor politically neutral. It requires either a shared open identifier that vendors agree to co-adopt, or a mapping service that reconciles vendor-native keys through a common intermediate.

The Databricks example, worked through

Consider the specific case the thesis names. An agent session opens with a research question about Databricks. The agent has connectors into Guidepoint, AlphaSense-Tegus, and a Bloomberg feed that surfaces GLG-sourced content.

Guidepoint's transcript, taken from a call with a former Databricks employee, tags the entity with Guidepoint's internal company ID and includes the string Databricks in the transcript text. The AlphaSense-Tegus filing excerpt tags Databricks Inc. as a private-company entity in AlphaSense's coverage universe, with a Tegus-inherited internal identifier and possibly an AlphaSense entity key. The Bloomberg-ASKB result, routing through GLG's integration, carries Bloomberg's internal entity handling.

All three references are to the same company. None of the three tagged identifiers is guaranteed to match. The agent has three options: match on the string Databricks, which works for uncommon names and fails for common ones; match through an external identifier service that maps vendor-native keys to a shared spine; or fail to merge and present the three excerpts as adjacent, unrelated evidence.

String matching is what most agents currently do, and it is why demonstrations of cross-vendor retrieval work well for entities with distinctive names and degrade for entities whose names collide with common words, product SKUs, or older corporate identities. External identifier mapping is the correct engineering answer and depends on the existence of the mapping service. Failing to merge is the honest default when neither of the first two options is available.

Product SKUs and person entities: the two flanks nobody is watching

The entity-resolution conversation typically focuses on company entities because that is where the buy-side reads the primary signal. Two flanks matter almost as much and are further from resolution.

Product SKUs sit inside expert calls constantly. A former operator discussing a semiconductor customer will refer to specific chip families, foundry nodes, and product generations. A healthcare expert will name specific device models, drug candidates by internal code, and clinical-trial identifiers. These are the entities that make expert-network content differentially valuable relative to filings, precisely because filings aggregate them into segment reporting. A shared tagging schema for products and SKUs does not exist at the category level. It would need to.

Person entities are the second flank. Experts themselves, plus the executives, board members, and named third parties they reference, are entities with their own identifier requirements. LSEG's PermID covers people. LinkedIn has effectively become the reference layer for professional identity. Neither is a natural tag inside an expert-network transcript. Yet the ability to say with confidence that the former VP referenced in a Guidepoint call and the CTO named in an AlphaSense-tagged press release are the same person is exactly the kind of join an agent should be doing and mostly is not.

Daloopa's structured-data thesis, read against this problem

Daloopa's fundraising narrative, positioning structured data as the binding constraint on AI-driven finance accuracy, is worth taking seriously in this context. Their published claim of a 71-point retrieval-gap improvement when structured data is available versus unstructured baselines is a vendor-authored number and should be read with the usual skepticism about self-reported benchmarks. But the shape of the claim is consistent with what the entity-resolution problem implies: an agent operating over well-tagged, well-identified content performs materially better than an agent operating over string-matched unstructured text.

Our read is that Daloopa's thesis and the expert-network entity-resolution problem are two views of the same underlying constraint. Daloopa addresses it by producing a structured layer over filings and financial documents. The expert networks address it, or fail to address it, by choosing how to tag entities inside transcripts. The two workstreams meet at the agent, and the agent's cross-vendor accuracy is bounded by whichever layer resolves the entity first.

Three scenarios for how the schema layer settles

We see three scenarios for how entity tagging converges in the expert-network category, and we hold them as MECE.

Scenario one: a dominant vendor publishes a schema and adoption follows. In this path, one of the larger networks, most plausibly AlphaSense-Tegus given the scale of its transcript archive post-acquisition, or Guidepoint given its early MCP posture, publishes an entity-tagging schema and encourages other vendors to adopt it. The schema likely leans on PermID or LEI for public entities and defines a mapping convention for private entities against PitchBook or Crunchbase keys. Other vendors adopt because their agent-visible content is otherwise stranded in string-matched retrieval. This is the fastest path to interoperability and the one that most rewards whichever vendor moves first.

Scenario two: a consortium or downstream intermediary carries the schema. Aiera's consortium-backed content platform, routing broker research, transcripts, filings, and expert content into agents through MCP, is a candidate for this. So is any of the incumbent identifier providers extending its coverage into expert-network content with vendor-side APIs. The consortium path is slower and politically harder but produces a more durable outcome because no single vendor owns the join key. It also produces less commercial upside for any one participant, which is why it tends to move slowly until the pain is acute.

Scenario three: no shared schema emerges, and agents solve the problem at the retrieval layer. In this world, entity resolution stays inside the agent, whether Claude, a Bloomberg agent, or a bespoke buy-side tool. Vendors tag with whatever identifier system suits them. The agent maintains its own mapping service, likely as a paid enterprise capability, and cross-vendor merges become an agent-vendor feature rather than a content-vendor feature. This is the path of least resistance and the worst outcome for the expert networks themselves, because it moves the join, and therefore the routing decision, into the agent layer and out of theirs.

We read the base case as a hybrid of scenarios one and three: a partial schema emerges among the two or three largest transcript archives, private-company coverage remains fragmented for longer than public-company coverage, and agents carry a meaningful share of the resolution burden through the transition.

What the counterargument looks like

The honest counterargument is that entity resolution has been a solvable problem in every prior generation of financial technology and has never quite gotten solved, and yet the industry has functioned. Bloomberg terminals, FactSet workstations, and Capital IQ have coexisted for decades without a unified identifier, because the analyst at the desk does the merge in their head. Perhaps agents will do the same, and perhaps the entity-resolution problem is a preoccupation that matters more to infrastructure vendors than to end users.

We take this seriously. Two features of the MCP-era workflow make us think the analogy breaks. First, the analyst at the desk is not doing the join anymore; the agent is, and the agent has neither the domain instinct nor the accountability of the analyst. Second, the citation-provenance work the category has just completed created an expectation that agent outputs are traceable and defensible. An entity misjoin, an agent asserting that two references are the same company when they are not, or missing the merge when they are, is a specific and repeatable failure mode that erodes exactly the trust the citation layer was built to establish.

The counterargument is right that the industry survived without unified identifiers before. It is likely wrong that the industry survives without them once agents are doing the primary research reading.

Who is affected, in order of exposure

The expert networks themselves sit at the center of the exposure. Guidepoint's MCP posture, AlphaSense-Tegus's archive scale, GLG's Bloomberg integration, and Aiera's consortium approach are each bets on a different resolution of the entity-tagging question, whether or not they are framed that way internally.

The identifier providers, LSEG with PermID, S&P, FactSet, Bloomberg with OpenFIGI, sit in the second ring. Whichever identifier becomes the transcript-tagging default gains a material distribution win that its licensing model may or may not be structured to capture.

Structured-data vendors, Daloopa and its peers, sit adjacent. Their pitch depends on the same underlying claim, that unstructured content plus good tagging outperforms unstructured content alone.

Buy-side and sell-side research consumers sit at the outer ring. They will experience the resolution or non-resolution of this layer as a quality signal, better cross-vendor retrieval or worse, without necessarily seeing the schema debate that produced it.

Questions we would put to an expert

A research analyst working this thesis would want to put five questions to the right expert:

• Which identifier systems does each major transcript vendor currently use for internal entity tagging, and how are those tags exposed, if at all, through MCP-facing outputs?
• How are private-company entities resolved across PitchBook, Crunchbase, and vendor-native keys inside the largest agent-facing deployments, and what is the observed accuracy of that resolution?
• What licensing constraints on CUSIP, ISIN, FactSet Entity ID, and S&P Capital IQ ID materially limit their use as public transcript tags, and how do vendors work around those constraints today?
• Where do product SKU and person-entity tagging sit on the roadmaps of the largest transcript vendors, and is anyone treating them as first-class entities rather than free text?
• Which agent platforms currently perform cross-vendor entity resolution as a first-class feature, and what mapping services or techniques do they use?