Context Graph Engineer
The context graph is our actual moat: the layer that knows what a user's documents, calendar, tasks, and mail mean to each other, so an agent never asks for a re-upload. It is half data engineering, half information retrieval, and it has to work under a permission model that says 'no' a lot. You will build it.
What you will do
Design and build connectors that sync third-party data into the graph incrementally, respecting every scope boundary at ingestion time, not query time.
Build the retrieval layer — what slice of the graph does this run actually need, and how do we load it in under a second.
Own freshness: a calendar that is five minutes stale is a calendar that books conflicts.
Make deletion real — when a user revokes a tool, its data leaves the graph completely, and you can prove it.
Define the schema evolution story so connector v2 does not orphan a year of synced data.
What we need
5+ years working on data-intensive systems — pipelines, search, sync engines, or storage layers.
Hands-on experience with at least one of: embedding-based retrieval, knowledge graphs, or CRDT/sync systems.
You have integrated against messy third-party APIs and have the rate-limit-handling code to prove it.
You think about deletion and access control as first-class design inputs, not compliance chores.
Comfortable owning a service in production, dashboards and all.
Nice to have
You have built RAG systems and know precisely where they disappoint.
Experience with Google Workspace / Microsoft 365 APIs specifically.
Background in information retrieval or a related research field.
Apply — we reply to everyone