RC
MIT's researchers put a hard number on something a lot of GTM leaders already suspected: across enterprise GenAI pilots, 95% returned nothing. The diagnosis was not the model. It was that the systems "do not retain feedback, adapt to context, or improve over time." (MIT Project NANDA, The GenAI Divide, 2025)
That single finding is the reason we built wysdym's knowledge layer before we built anything a customer sees. Here is a build-in-public look at what it is, and at the part we care about most: a graph that grades itself on outcomes.
Why we started with the graph, not the agent
Every GTM team is being sold an agent this year. Almost none of them are being sold the thing an agent needs to be useful past the demo.
We took the opposite approach. Before we shipped a single customer-facing routine, we built the memory underneath it. wysdym is the operating layer for agentic go-to-market, and the graph is what every agent on it reads from and writes to. The wager is simple. Models are converging and getting cheaper. What stays scarce is a structured, trustworthy, per-account picture of your market that improves every week. You do not prompt your way to that. You have to build and maintain it.
The same MIT work makes the demand explicit: two-thirds of the executives surveyed said they wanted AI that learns from feedback, and 63% wanted tools that retain context. A knowledge layer is the answer to that request.
What the wysdymGraph actually is
Underneath the naming, it is a typed, per-tenant property graph. Both of those words carry weight.
Typed means the graph knows the difference between an offering, a competitor, a pain point, an objection, a talk track, and a buyer stage. Today that is 13 core node types and more than 19 edge types, with industry overlays for SaaS, professional services, and ecommerce. A generic vector store can tell you two documents look similar. It cannot tell you that this objection counters that value pillar for this segment. The schema is where years of GTM judgment get encoded, and it is the piece a competitor with a model key and three months cannot shortcut.
Per-tenant means your graph is yours. It is isolated at the data layer, and it fills with your products, your personas, your win patterns, and your losses. The longer your team runs on it, the richer it gets, and that asset does not exist anywhere else.
Behind the schema sits a four-store design: a system of record for entities and audit, a graph store for multi-hop traversal, a vector store for semantic recall, and a versioned document store for the authored knowledge base. A sync engine keeps them consistent. Every node and edge carries its source, a confidence score, and a version, so nothing in the graph is unattributed. Any answer an agent gives can be traced back to where it came from. That schema, the four stores, and the per-tenant isolation are built and running today.
How it grades itself on outcomes
Here is the part we care most about, and the part we are closing right now with our design partners.
A knowledge base that only ever grows is a liability. It fills with stale claims, one-off assertions, and things that used to be true. So the wysdymGraph is designed to keep score. When an agent answers a question, every piece of the graph it leans on is tagged to that session. When the session resolves into an outcome your CRM already tracks, whether a booked meeting, a won deal, or a lost one, that result is attributed back to the exact nodes and edges that were used. Knowledge that keeps showing up on the way to good outcomes gains weight. Knowledge tied to dead ends loses it. And stale nodes decay on their own, so the graph quietly forgets what no longer applies.
The effect is a memory that is opinionated about what is working right now, not just what was written down once. New signal, whether a call transcript, a document, or an agent-proposed update, runs through a scoring step before it touches the graph. Anything below a confidence threshold routes to a human review queue, where an approve, an edit, or a reject all become training signal for the next pass.
To be precise about status: the schema, the four stores, and the per-tenant isolation are live in production today; the reinforcement loop, the outcome attribution wiring, and the productionized ingestion pipeline are in active development [ROADMAP].
Why we think this is the durable part
The agent layer is contested, and it will stay that way. New models ship monthly, and customers should be free to bring whichever one they trust. That is exactly why we did not put our moat there.
Three things make an outcome-graded graph hard to copy. The schema is the artifact, and it encodes GTM domain depth that takes far longer than a quarter to get right. The per-tenant reinforcement signal is not portable, because the weight on your graph accumulates over months of your team's activity and resets to zero the moment it is cloned elsewhere. And outcome attribution requires deep, governed CRM integration, which generic observability tools do not have and closed agent platforms only have for their own agent.
Put together, that is a knowledge layer that compounds. The more agents you run on wysdym, the more signal flows back into the graph, and the smarter the next agent starts. That is the whole thesis: don't bet on the agents, bet on what every agent needs to work.
We are building this with a small group of design partners now. If you lead GTM, you are trying to make agents useful past the demo, and you want the knowledge layer to be an asset you own rather than a prompt you keep rewriting, we would like to compare notes. Talk to the founders.
