The Knowledge Graph Your Ops Stack Has Been Missing
Every cross-border operator I know is drowning in the same thing: scattered truth. Supplier specs live in a PDF in a Google Drive folder. Packing-list quirks live in a Gmail thread from 2023. Compliance rules sit in a Notion doc that contradicts the Asana ticket that contradicts the Alibaba message thread. When something goes wrong — a customs hold, a chargeback, a listing suspension — the answer exists somewhere, but nobody can assemble it fast enough. That’s the real reason I paid attention to yggy, a self-building knowledge-graph tool from the team at Dominik Müller’s group that launched on Product Hunt this week. It’s not a seller tool. But the problem it attacks — turning messy, multi-source documents into a queryable graph where every fact traces back to its origin — is exactly the problem an eight-figure DTC brand has across Shopify, Amazon Seller Central, and a dozen SaaS dashboards.
What yggy Actually Solves (and Why It’s Not Another Chatbot)
The pitch from the makers is refreshingly honest: most AI tools layered on company knowledge either “retrieve a pile of text chunks, or let an agent search through MCP and API calls and guess.” That’s a fair description of what happens when you point a generic LLM at your operations. It’s slow, it burns tokens, and — the killer — you can’t verify where an answer came from. When the answer is “your EU shipment needs a new EORI number,” a plausible guess is worse than no answer.
yggy’s answer is a knowledge graph that builds itself. You bring in documents, mailboxes, drives, and tickets; the system extracts entities and relations into an ontology you define, merges duplicates, and links every fact back to its source. You then query it in-app, via REST API, or by plugging the graph into your own agents through MCP. The team is explicit that transparency is the core feature: every answer points to where it came from, merges are reversible, and unclear cases route to a review queue rather than being silently resolved.
That last point matters more than the marketing copy suggests. The single biggest objection to any “AI organizes your data” product is trust — and co-founder Carlos Gienow basically admits the origin story was pain: they wanted to build knowledge graphs, then discovered how much time vanishes into ontology design, entity matching, and “explaining to five systems that they are talking about the same thing.” They automated the part that makes people quit. For a seller trying to reconcile a supplier’s SKU naming with Amazon’s ASINs with Shopify’s variant IDs, that’s not an abstract workflow problem — it’s Tuesday.
Why Amazon sellers should care more than Shopify ones
Pure-DTC Shopify operators have it comparatively easy: one catalog, one order source, one set of customer records. Amazon FBA brand owners live in a fractured reality — Helium 10 for research, Seller Central for inventory and fees, a separate 3PL portal, supplier WeChat threads, freight forwarder emails, and a returns spreadsheet someone maintains by hand. The entity-resolution problem (is this the same product across five systems?) is genuinely hard, and it’s where wrong answers cost real money: mis-matched SKUs become mis-forecast inventory become stockouts become lost Buy Box share. A graph that keeps provenance on every fact is, in principle, a better substrate for “why did we run out of the 2-pack in Q3” than any dashboard.
How It Stacks Up Against What You’re Probably Using
The honest comparison set isn’t other knowledge-graph startups — it’s the tools already in your stack. Against Notion or a Google Drive wiki, yggy wins on structure and loses on human readability; nobody wants to browse a graph when a clean doc will do. Against a RAG setup bolted onto Slack or a custom GPT, it wins on provenance and ontology compliance — the “pile of text chunks” critique is real, and I’ve watched teams burn weeks tuning retrieval before admitting the answers still weren’t auditable. Against enterprise graph platforms, the differentiator is the dev-first posture: REST API, MCP, CLI, SDKs, docs written for builders, plus multi-tenant isolation with SSO, scoped tokens, and an audit log. And for the privacy-conscious, it’s EU-hosted and GDPR-first, with the graph-rendering engine, graphraum, open-sourced under Apache 2.0.
The MCP angle deserves a sidebar of its own. If you’re already running agents against your ops data — a returns-triage bot, a listing-optimization assistant — the bottleneck isn’t model quality, it’s that every agent re-discovers your business from scratch via API calls and guesses. A shared, ontology-compliant graph behind MCP is a plausible fix: the agent stops guessing and starts reading. That’s the borrowable idea, and it’s the one I’d steal even if you never sign up.
What Cross-Border Operators Should Borrow From This
Three things, regardless of whether yggy fits your stack. First: define your ontology before you buy more tools. Most sellers can’t articulate their core entities — product, variant, supplier, shipment, order, claim — or how they relate. Write that down this week; it’s the highest-leverage document nobody owns. Second: demand provenance from every AI tool you pay for. If a tool can’t show you the source of a claim about fees, compliance, or demand, treat its output as a hypothesis, not a fact. Third: treat merge-review queues as a feature, not friction. The makers’ answer to the “how do you catch a wrong duplicate merge” question is instructive — merges are suggestions, merged entities become aliases rather than deletions, and a Resolved tab can split them apart again. That reversibility pattern is worth demanding from your PIM and inventory tools too.
Where the math breaks
Here’s my skepticism. The product is aimed at teams and companies — the maker confirmed the core “works for a single person too,” but the center of gravity is enterprise. A mid-size seller juggling 2,000 SKUs across three marketplaces has a data volume and messiness problem that a knowledge graph can absolutely help with, but the setup cost — ontology design, connectors, review-queue babysitting — is real labor, and the ROI only shows up if someone actually queries the graph weekly. My judgment: this is a build-it-into-your-ops-layer play for brands with an in-house engineer or a technical ops lead, not a plug-and-play subscription for a five-person team. The platform itself isn’t open source today; a self-hosted “yggy Community” under AGPL-3.0 is planned but not shipped, so self-hosting purists should wait.
What I’d Watch / Test Next
Two concrete moves this week. First, audit your own source-of-truth sprawl: list every system that holds product, supplier, or compliance facts, and count how many contradict each other on a single SKU. That number is your business case — for yggy or anything like it. Second, if you run agents against ops data, test the MCP pattern on one narrow workflow (returns triage is the safest) and measure how often the agent’s answer can be traced to a document. If it can’t, you’ve found your gap. I’ll be watching whether yggy ships its self-hosted community edition and whether connector coverage reaches the unglamorous places sellers actually live — freight forwarder portals and marketplace APIs, not just PDFs and mailboxes. Until then, borrow the ontology discipline and the provenance obsession. Those are free.
