One shared map of the firm — people, companies, investments, funds, impact — that our team and our agents both build on.
And everything related to that lifecycle, we aim to represent in our ontology.
We are mapping the timeline from the last slide to an ontology — a sample of some familiar objects and their links.
The record that a deal happened. An LP's commitment is an investment of type fund_equity.
A vehicle the firm raises and deploys — e.g. Fund 6. SPVs and select funds are funds too.
An engagement is the agreement between a portfolio company and an impact team.
Eight capabilities, abstracted from Palantir's AIP — and where Central, our hand-built version, already stands.
Pull from systems of record on a schedule, with provenance. Partial
Dedupe, resolve entities, enrich at ingest. Strong
Objects, properties, typed links — in plain language. Yes (in code)
Keep objects live, not a query someone re-runs. Yes
Every write a typed, audited action. Half
Permissions enforced in the data layer. Weak
Schema as the map; search, read, act as tools. Reader, not writer
Golden evals gate changes; audit every call. Yes
Central already has the hard parts: resolved entities, fact-level provenance, reviewed writes, evals. The gaps are increments — let the agent propose changes, add write-back & notifications, add semantic search, expose an MCP surface, tighten permissions. Not a rebuild.
Deterministic guardrails for agents — lines they can't cross.
A company becomes a portfolio company only once its Carta cap table exists.
company.type = portfolio_company ⇒ carta_cap_table.exists
Palantir likes to think of the schema as data, not code — so the platform around it doesn't change when the schema does. It's built to evolve, and agents are how it evolves.
Software, not judgment. Every email, calendar event, and LinkedIn connection adds people, companies, and the links between them — from the participants and metadata only. Subjects and bodies are never read or stored. It's also what finally lets us count the meetings we source.
With a subset of your permissions — which MCPs, which tools within them, and to what degree.
You don't have to build your own agents, and your data doesn't have to leave your hands. The OS team builds the Fleet; you accept an agent; it runs on your data, for you.
Multiplayer navigates everyone's permissions for us — removing the friction those permissions usually introduce when the team is solving problems for the firm.
An agent the OS team builds once runs for everyone, and each one works from the firm's shared context — not just what one person happens to know.
Every tool was built to hold one kind of work well — comments in Docs, threads in Slack, pages in Notion. We don't fight it. The layer keeps a reference to where context lives, never a copy.
No copy to sync. The source stays the source of truth — permissions included.
You own freshness forever, and two systems to keep healthy instead of one.
TBDhow we search into it — buy (Glean) · hybrid (vector DB) · build (Elastic + embeddings)
Every change is owned, reviewed, and versioned — so an update never quietly breaks someone's workflow.
Anyone can use it, and anyone can propose an improvement.
Read or run it freely; changing it goes through the owner.
Agents on your own data are yours alone. Sharing is your call.
Exploring now · graph databases for the network, and self-hosting our own fork of Twenty (open-source CRM) — concrete directions on the first two calls.
The full diligence — decks, the PRD, the ontology and cost docs, and the mockups — lives in #context-layer in Slack.