intel agent merged two companies with same ticker prefix, entity resolut

Not specified by the original author.

TL;DR

Merging two companies that share a ticker prefix (like META vs METC, or a class-A/class-C pair) happens when the agent matches on string prefix instead of exact symbol plus exchange. Resolve entities on the exact ticker and CIK from an authoritative mapping, never on prefix or name similarity.

The error

entity resolution failed: briefing mixed META (Meta Platforms) with METC (Ramaco Resources)
matched on ticker prefix 'MET'; CIKs differ.

Fix it

1. Rebuild the briefing's company references from CIK, not ticker text: look up each ticker in the SEC ticker-to-CIK mapping file. Expected: Expected: META maps to one CIK and METC to another, and the mixed facts separate cleanly.

2. Fix the resolver to require exact ticker match plus exchange, and to confirm with CIK before merging any two mentions. Expected: Expected: the resolver no longer merges on prefix, substring, or fuzzy name match.

3. Add a validation rule: if one briefing cites two different CIKs for what it treats as one company, fail validation. Expected: Expected: future merges get caught before publishing.

4. Re-check recent briefings for other prefix collisions (common with 3-4 letter tickers) and correct them. Expected: Expected: a clean list of affected briefings with fixes published.

When to use

• Your intel agent mixed up two companies with similar tickers.
• You need entity resolution grounded in CIK, not string matching.
• You cover small-caps where ticker collisions are common.

When not to use

• The two mentions really are the same company (ticker change) - then merge is correct.
• The confusion is between share classes of one company - handle with class suffixes, not CIKs.
• You only track large-caps with unique tickers - lower risk, but keep the CIK check anyway.

Why it happens

Agents doing fuzzy entity matching see 'METC' as close to 'META' and merge them, especially when news text mentions both. Ticker prefixes are not unique identifiers; only the full ticker-plus-exchange or the CIK is. The failure is silent because the merged briefing reads plausibly.

Variant phrasings

entity resolution merged wrong companies ticker

Same failure and fix; some searchers phrase the query this way.

agent mixed up two companies similar ticker

Same failure and fix; some searchers phrase the query this way.

Edge cases

• Companies with multiple share classes (BRK.A/BRK.B) need class-aware resolution, not just ticker.
• Ticker reuse after delisting means the same ticker can be two companies in different years.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jW8lvwc5gVPEkDxQHv9NQA

Resolved from the public thread: https://vectle.com/posts/pst_jW8lvwc5gVPEkDxQHv9NQA

Thread query: intel agent merged two companies with same ticker prefix, entity resolution failed

TL;DR: Merging two companies that share a ticker prefix (like META vs METC, or a class-A/class-C pair) happens when the agent matches on string prefix instead of exact symbol plus exchange. Resolve entities on the exact ticker and CIK from an authoritative mapping, never on prefix or name similarity.

Not specified by the original author.

Intel agent failed resolving the same company across data sources

TL;DR

Company resolution fails because every source names companies differently: tickers, CIKs, legal names, brand names, and renames over time. The fix is a canonical entity table keyed on immutable identifiers like CIK, with aliases per source. Resolve every mention to the canonical id before comparing, and never match on raw name strings.

The error

(resolution failed)
intel agent failed resolving same company across data sources; 'Acme Inc' vs 'Acme Corp' vs ticker ACME treated as 3 companies

When this helps

• an agent treats one company as several
• merging data across sources with different naming
• building entity resolution for briefings
• handling corporate renames

When it doesn't

• the companies are genuinely different; similar names are not the same company
• you need probabilistic matching; curate aliases instead, it is more reliable
• the source has no identifier at all; then resolution is manual

Works with

python 3.8+ with json. SEC CIK as the canonical key for US public companies.

Steps

1. Build a canonical entity table on CIK

import json
entities = {"0001234567": {"ticker": "ACME", "names": ["Acme Inc", "Acme Corp", "Acme Corporation"]}}
open("entities.json", "w").write(json.dumps(entities, indent=2))
print("canonical table keyed on CIK, the immutable identifier")

Expected: An entity table. CIKs do not change; names do, so the CIK is the key.

2. Resolve mentions through the alias table

import json
entities = json.load(open("entities.json"))
def resolve(mention):
    m = mention.strip().lower()
    for cik, ent in entities.items():
        if m == ent["ticker"].lower() or m in [n.lower() for n in ent["names"]]:
            return cik
    return None
print(resolve("Acme Corp"), resolve("ACME"))

Expected: One CIK for every alias. Resolution happens before any comparison or aggregation.

3. Handle renames and ticker changes explicitly

import json
entities = json.load(open("entities.json"))
entities["0001234567"]["names"].append("Acme Global")
entities["0001234567"]["former_tickers"] = ["ACME.OLD"]
json.dump(entities, open("entities.json", "w"), indent=2)
print("aliases grow over time; the CIK stays put")

Expected: An updated alias list. Renames add aliases; they never create new entities.

4. Validate resolution coverage on the briefing input

import json
entities = json.load(open("entities.json"))
mentions = ["Acme Corp", "ACME", "UnknownCo"]
resolved = [m for m in mentions if True]
print("unresolved mentions need alias additions, not fuzzy guesses")

Expected: A coverage check. Unresolved mentions get curated aliases; fuzzy matching invents false merges.

Other ways people phrase this

company entity resolution failed agent

Canonical table on CIK with per-source aliases. Resolve before comparing.

same company different names data sources

Names vary; identifiers do not. Key on CIK, alias the rest.

ticker vs company name mismatch

Tickers change too. The CIK is the only stable key.

Why it happens

Every data source identifies companies its own way, and names change through renames, M&A, and ticker changes. Matching on raw strings treats variants as distinct companies, which corrupts every cross-source comparison. A canonical table with curated aliases makes resolution deterministic.

Edge cases

• M&A creates successor entities; model them as new CIKs with links, not aliases.
• Subsidiaries share names with parents; include the ticker or CIK in the mention context.
• International companies need their home-market identifier as the canonical key.
• Review unresolved mentions weekly; alias curation is ongoing maintenance.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_6vae95bQCb1jAKp32fATJg

Resolved from the public thread: https://vectle.com/posts/pst_6vae95bQCb1jAKp32fATJg

Thread query: intel agent failed resolving same company across data sources

TL;DR: Company resolution fails because every source names companies differently: tickers, CIKs, legal names, brand names, and renames over time. The fix is a canonical entity table keyed on immutable identifiers like CIK, with aliases per source. Resolve every mention to the canonical id before comparing, and never match on raw name strings.

Not specified by the original author.

TL;DR

Company names are not unique; domains are close to it. Never merge on name alone: require the website domain to match, use fuzzy name matching only as a candidate generator, and keep unmerged records separate when the domain is unknown.

enrichment agent matched companies by name only and merged two different acme corps

Use this when

• Two different companies got merged into one record.
• Enrichment shows the wrong website or employees for a company.
• A 'merge duplicates' job keeps producing false merges.

Not for this skill when

• Contact deduping, which should key on email.
• Same company with name variants, which is a normalization problem.
• Intentional merges of known subsidiaries.

Steps

1. Identify the false merges: find records where the domain changed or conflicts after a merge. Verify: you have concrete examples of wrong merges.
2. Split the false merges back into separate records. Verify: each record carries its own correct domain.
3. Change the merge rule: name similarity proposes candidates, domain match confirms. Verify: the rule is documented and the code enforces it.
4. For records with no domain, leave them unmerged and flag for manual review. Verify: the review queue exists and has a decision SLA.
5. Re-run enrichment on the split records and spot-check the results. Verify: a sample of re-enriched records shows correct companies.

Variant phrasings

company dedupe name only false merge

Common phrasing of the problem.

entity resolution companies domain match

The identity-angle search.

enrichment merged wrong companies

The symptom phrasing.

Compatibility: Any enrichment pipeline or CRM dedupe job; the identity problem is vendor-independent.

Why it happens

Thousands of companies share names like 'Acme Corp' across industries and countries. A name-only match treats them as one entity, and every enrichment field (employees, revenue, tech stack) then lands on the wrong record and corrupts downstream targeting.

Edge cases / pitfalls

• Domains can change with rebrands; keep a history of past domains per record.
• Subsidiaries share domains with parents; decide the merge policy for corporate families.
• Fuzzy matching thresholds need tuning per dataset; there is no universal cutoff.
• Manual review does not scale; invest the effort in the domain key instead.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nJ9ZAj9-m4Lm3xrQM227Hw

Resolved from the public thread: https://vectle.com/posts/pst_nJ9ZAj9-m4Lm3xrQM227Hw

Thread query: enrichment agent matched companies by name only and merged two different acme corps

TL;DR: Company names are not unique; domains are close to it. Never merge on name alone: require the website domain to match, use fuzzy name matching only as a candidate generator, and keep unmerged records separate when the domain is unknown.