KNOWLEDGE GRAPH
Your company knows more than anyone in it can access.
The knowledge that makes your company run is scattered: chat threads, meeting recordings, spreadsheets, documents, code, tickets, and the undocumented expertise in people's heads. The knowledge graph brings it into a single retrieval surface that any agent or person can query. One interface over everything the organization produces and consumes. The foundation that makes every AI workflow more effective, and the reason the fiftieth workflow is dramatically more powerful than the first.
THE BOTTLENECK
The model isn't the problem. The context is.
Decisions made on a fraction of the available context. Risks visible only in retrospect. The same questions answered from scratch across dozens of conversations. The cost of this gap is the largest hidden tax on knowledge work.
People talk about "AI for the enterprise" as if the bottleneck were the model. It isn't. The bottleneck is that the model never sees more than 10% of what the company already knows. Fix that, and a competent agent outperforms a brilliant human who only has access to their own inbox.
THE UNLOCK
The value is in composability.
Any single integration produces marginal value. A Slack search is a Slack search. But the most valuable knowledge in an organization isn't in any tool at all. It's in people's heads, in undocumented processes, in the institutional expertise that walks out the door when someone leaves. The knowledge graph captures both: it connects to existing systems AND makes legible the things that were never written down. Once that knowledge is structured and queryable, connections emerge that no one had the bandwidth to notice. The leverage compounds when an agent can correlate a message thread, a meeting transcript, a time entry, an undocumented process, and a piece of institutional knowledge in a single retrieval pass.
Slack channels, threads, DMs. The informal layer where most real decisions happen.
Full transcripts with speaker attribution. The context that's usually locked in the heads of the people who were there.
Deals, contacts, engagement history. The commercial context.
Issues, sprints, milestones, status. The delivery context.
Commits, pull requests, file changes, review threads. What actually shipped.
Hours, allocations, budgets. The financial reality underneath the project narrative.
Drive, Notion, wikis, shared files. The institutional knowledge that was written down.
Meetings, availability, patterns. Who's talking to whom, how often, about what.
A reasonable place to start is connecting individual tools directly to an AI assistant. That gets you raw access to each source. But each tool returns its own data with its own schema, its own identity model, and no awareness of the others. "Jordan Park" in your messaging tool is unrelated to "Jordan Park" in your meeting transcripts is unrelated to their project allocation in your time tracker. The agent has to figure out the connections on every query, using context window to do work that should already be done.
The knowledge graph resolves this once. Entities are deduplicated across sources. Relationships are extracted and tracked over time. When an agent queries the graph, the connections are already there: a person is linked to their projects, their meetings, their messages, their code contributions, and their time entries. A single question, like "is Project X on track?", gets answered by correlating the latest standup transcript, this week's sprint progress, the current budget burn, the relevant Slack threads, and the project lead's calendar load. In a single pass, with the relationships pre-resolved.
IN PRACTICE
What it looks like to query the knowledge graph.
Different roles, different questions. The same knowledge graph composes the answer from whatever sources are relevant, with citations back to the original data.
TokenMaxx wants us to build their inference optimization platform. $600K, 6 months. Should we take it? What do we know about them?
Here's what I can assemble from our data:
The deal itself: Troy's been in conversation since March. Technical scope is well-defined (inference cost optimization for their customer-facing API). They've done two rounds of technical validation and the engineering fit is strong. Close date estimated mid-June. [Knowledge Hub — HubSpot deal record, TokenMaxx]
Financial concern: TokenMaxx closed a Series B 14 months ago ($18M from Gradient Ventures). No public announcements since. In Troy's last call, their VP Eng mentioned they're "being thoughtful about runway," which in context sounded like they're watching cash. A 6-month $600K engagement is roughly 20% of their raise. [Knowledge Hub — Fathom transcript, Troy + TokenMaxx VP Eng 5/8] [Knowledge Hub — web research, TokenMaxx funding history]
Capacity fit: The project needs ML infrastructure engineers. Marcus Webb and the Atlas team rolling off in July have the right skills, and the timing works. Staffing is feasible without displacement. [Knowledge Hub — allocation records, bench projections]
My read: The technical and staffing fit is good. The financial risk is the client's runway. I'd recommend structuring the SOW with monthly milestones and payment terms that give us early signal if they hit cash constraints. A $600K fixed-price with payment at the end would be high risk. Monthly T&M with a cap, or milestone-gated payments, would de-risk it substantially.
There's an ICLR workshop on agentic alignment next month in Vienna. Should we send Diogo? Is it worth the trip?
I think yes, and here's why the timing is particularly good:
Research relevance: Three of the accepted papers cite our Self-Other Overlap work, and one of the workshop organizers (Dr. Kira Patel from DeepMind) referenced Diogo's DARPA AICRAFT presentation in her opening remarks at the NeurIPS side event last December. There's an active conversation happening around our research that we should be present for. [Knowledge Hub — research citation tracker] [Knowledge Hub — Fathom, NeurIPS debrief 12/19]
Business development angle: Two companies we've been trying to reach (Anthropic's enterprise safety team and a stealth EU AI governance startup) have people presenting at this specific workshop. Troy has been trying to get a meeting with the Anthropic team for three months. A hallway conversation at ICLR is worth more than another cold email. [Knowledge Hub — HubSpot outreach history] [Knowledge Hub — conference attendee list cross-reference]
Calendar check: Diogo has no client-facing commitments that week. The research team standup can be async. No conflicts. [Knowledge Hub — calendar data, week of Jun 16]
Cost: Flights + hotel + registration is roughly $4,200. If it produces either the Anthropic meeting or a connection to the EU startup, the ROI is asymmetric.
I haven't been able to attend the Acme standups this week. What happened? Anything I need to act on?
Three things from this week:
UAT passed. Document pipeline hit 97.2% accuracy on the client's real data set on Wednesday. Lisa Huang (VP Product) was in the review and said it was "the first thing that actually works on our messy data." This is good news worth amplifying. [Knowledge Hub — Fathom transcript, Demo Review 5/22] [Knowledge Hub — Slack #acme-sans 5/22]
Load testing is still unresolved. Jordan Park raised it in Monday's standup, Wednesday's standup, and Friday's standup. Third consecutive week. No load testing plan exists in the Sprint 15 backlog. Jordan is engaged and constructive about it, but the concern is getting louder. [Knowledge Hub — Fathom transcripts, Standups 5/19, 5/21, 5/23] [Knowledge Hub — Linear Sprint 15 board]
You should act on the load testing. Jordan is the client's internal champion. Leaving a technical concern unaddressed for three weeks risks shifting them from advocate to skeptic. I'd recommend getting a planning session scheduled before Sprint 15 kicks off. Sarah Chen can set it up.
NexGen Robotics is about to close. Who do we have available to staff it? They need an ML engineer, a senior engineer, and a PM.
Here's what I see for availability around the expected start (week of June 9):
ML Engineer: Marcus Webb is available June 2. He's currently on Atlas Logistics at 32 hrs/wk but that engagement is transitioning to optimization phase (0.5 FTE). He has computer vision experience from the Coastal Energy project last quarter. Good fit. [Knowledge Hub — allocation records + project history]
Senior Engineer: Rachel Torres is available June 9 if Atlas shifts to 0.5 FTE as planned. She's been on Atlas since January and knows the API/infra patterns NexGen will need. [Knowledge Hub — allocation records]
PM: This is the gap. Sarah Chen is at capacity on Acme (20 hrs/wk through at least July 28). No other PMs are available before July. [Knowledge Hub — PM allocations + calendar data]
You'll need to either hire, reassign, or delay the PM staffing. Want me to check whether the new PM hire has a confirmed start date?
I sent the BrightPath SOW three weeks ago and haven't heard back. What do we actually know about what's happening on their end?
The silence correlates with an internal reorg at BrightPath.
What we know: Your champion (VP Data, Jamie Torres) attended every call through April and was actively driving the engagement. Last substantive contact was April 28. On May 5, BrightPath announced an internal reorganization. [Knowledge Hub — HubSpot deal timeline + Fathom transcripts, last 60 days]
What we don't know: Whether Jamie's role, budget authority, or reporting line changed in the reorg. No public announcements about the VP Data role. Jamie hasn't responded to your May 8 or May 15 follow-ups, but also hasn't responded to two LinkedIn messages from others at AE during the same period. [Knowledge Hub — HubSpot activity log + Slack #sales outreach notes]
A possible path: Dr. Amy Lin (CTO) attended the original technical demo and asked substantive questions about the architecture. She's a level above Jamie and would know what changed. A direct, low-pressure check-in with Amy is probably the fastest way to find out whether this deal is alive or needs to be re-qualified with a new stakeholder. [Knowledge Hub — Fathom transcript, Technical Demo 3/14] [Knowledge Hub — HubSpot contact record, Amy Lin]
Illustrative output. Names and data are fictional. Structure and source citations reflect the actual system.
ARCHITECTURE
Two retrieval surfaces over the same data.
Who, what, when
Deterministic queries against typed records. People, projects, allocations, availability, documents. For questions with known schemas: who's on the bench in June, what's the budget for Project X, when did the kickoff happen.
Fast. Cheap. Paginated. The foundation agents resolve entity IDs against before reaching for anything more expensive.
What is true, what was true, how we know
A temporal property graph of claims, episodes, and entity states. Every claim traces to raw source episodes (a message, a transcript chunk, a commit, an API snapshot). Every claim carries a time window: when it became true and when it stopped being true.
This is where intelligence-layer agents spend most of their time. The graph is the connective tissue between everything the company has said, decided, and built.
TIME-AWARE
Facts expire. The graph knows that.
"Sarah is on Project X" was true in March and not in May. A graph that doesn't represent expiry will, within months, become a confused union of every state every entity has ever been in. The knowledge graph tracks when things became true and when they stopped being true. Expired relationships are preserved for history, not treated as current state.
Sarah → Member of → Project X Mar 2026 → present
Mike → Assigned to → Issue #412 Apr 12 → Apr 19
Client CEO → Discussed → Budget concerns May 20 → present
This means you can ask "what was true about this project in March?" and get an accurate answer, even if everything has changed since then. The audit trail is built into the data model.
AGENT-NATIVE
Built for agents to consume.
The knowledge graph is delivered as an MCP server. Any agent, any automation, any chat interface speaks to the company's knowledge through one protocol. The same interface is consumed by AI assistants, internal automation services, intelligence-layer agents, and people using chat-based tools. New surfaces plug in without re-implementing the data layer.
Read from the graph to produce weekly briefs, strategic recommendations, and cross-functional analysis.
Query the graph to execute workflows grounded in the company's actual data.
Ask questions in natural language through chat interfaces. Get answers with source citations.
Code assistants with access to project history, architecture decisions, and institutional context.
PRIVACY & ACCESS CONTROL
Visibility is built into every layer.
Access control is stamped on data at the point of ingestion, not applied as a filter at query time. Every raw event, every extracted claim, every entity connection carries metadata about who should see it: project scope, content classification, and source identity. Queries respect these stamps at every layer.
Raw events are stamped with project, source, and content class at ingest. The stamp travels with the data everywhere it goes.
Extracted relationships respect the same scoping. A query about Project X only returns claims from sources visible to Project X.
Different roles see different views. Leadership briefs include team dynamics. Team-facing views don't. Praise in public, correct in private.
Every claim traces to its source episodes. Every query is logged. The system is designed to be challenged and verified.
HOW IT BUILDS
Start simple. Grow into a graph.
The knowledge layer doesn't start as a full graph. It starts as a focused data model, grounded in how the company actually operates. Structured tables that map the specific information agents need. Easy for humans to understand, easy for agents to query.
As more workflows connect and more data flows through, the relationships multiply. At a certain point, the relational model becomes too complex for a person to hold in their head. That's when the graph becomes worth it: not as a replacement for the structured layer, but as a semantic layer on top of it. The structured data stays. People manage it through applications and APIs. Periodically, snapshots feed into the graph, where the relationships and connections live.
Both layers evolve in parallel. The graph doesn't eat the database. It extends it.
The pattern is general. The unit of work is yours.
For AE Studio, the knowledge graph is built around client engagements. Every source connects to projects. Every brief is scoped to a project. Every cross-project pattern surfaces through the graph.
For your organization, the unit of work will be different. It might be the customer account, the engineering team, the research program, the patient, the case file. The architecture is the same. The sources connect to your unit. The intelligence layer watches your signals. The knowledge compounds around what matters to your business.
Talk to us about building yours