ORION

Click once, and your whole company's context is updated for every person and every agent.

Inspiration

Sales cannot see what engineering is building, and engineering cannot see what sales promised. Nobody posts in Slack after changing the Google Ads budget. The information exists, but it lives on the page someone just edited or in the commit someone just pushed, and writing the update is the step everyone skips.

We wanted to remove that step. In ORION, the click is the update.

What it does

ORION is a shared company context map fed by two sources:

A browser extension. One click captures the page you are on, such as an ads dashboard or a deal record, and turns it into the few things a teammate would need to know changed.
A codebase agent. When code is pushed, it turns the changes into plain-language feature cards that a salesperson can understand, and marks whether each feature is safe to mention to customers.

Everything lands in one graph of features, deals, campaigns, decisions, and risks, linked by relationships such as "blocks" and "feeds".

People see the graph as an interactive star map. Clicking a star shows a summary, what to do, and what to read. Asking a question in the chat bar, such as "What can sales promise about voice mode?", answers in plain sentences and reshapes the map to show the relevant stars.

AI agents query the same graph through a context endpoint that already knows who is asking, so each person and each agent gets the items most relevant to their role.

How we built it

We split into four tracks and agreed on a shared contract first: the shape of a node, an edge, the five API endpoints, and the view command the chat uses to reshape the map. That let three tracks build against a mock server while the backend was still being written.

Browser extension: Chrome Manifest V3 and TypeScript with a plain HTML popup. It captures a screenshot and a cleaned copy of the page, with an optional blackout tool for hiding parts of the screenshot.
Codebase agent: a sync script that runs as a GitHub Action on every push to main, plus a Claude skill file so Claude Code follows the same rules. Lines in .gitignore that start with +. mark paths the agent must never read or publish.
Backend: Next.js route handlers with the Anthropic SDK. Claude reads each capture (screenshot plus HTML) or code diff and returns structured nodes and edges through tool use. Nodes are deduplicated, embedded with Google's EmbeddingGemma through OpenRouter, and ranked for each user with a per-user steering vector blended from their role, the items they own, and the items they have touched. Gap and ripple checks are plain, deterministic TypeScript.
Adaptive UI: Next.js, TypeScript, Tailwind, zustand, and react-force-graph-2d. The chat endpoint returns a view command that sets the layout, focus, and highlights on the map.

Challenges we ran into

Building in parallel around a critical path. Every track depends on the backend, so we had to fix the data contract early and work against mocks until the real endpoints existed.
Friction versus privacy. A capture tool only gets used if it is one click, but one click sends whatever is on screen. We kept the default path at zero friction, added an optional blackout, and stated the remaining risk plainly.
Keeping private code private. We needed a rule that engineers would not have to remember. The +. convention lives in a file every repository already has and is applied by the sync script and the skill, not by people.
Two sources, one vocabulary. Page captures and code changes describe work in different terms. Agreeing on one set of statuses, and on where feature cards are written, took more discussion than the code did.
Avoiding duplicates. The same campaign or feature shows up across many captures and commits, so every ingest has to merge into existing nodes instead of adding new ones.

Accomplishments that we're proud of

The whole product, from the user's side, is one button.
People and agents read from the same graph, so there is one source of context instead of two.
Pushing a commit that touches only a private path creates nothing on the map.
The chat does not just answer. It rearranges the map so you can see the answer.
Two people asking for context get different results based on their role.
We describe the retrieval honestly. It is vector similarity underneath; what is ours is the graph structure, the per-user steering, and the precomputed rankings.

What we learned

Agreeing on the data contract before writing code is what makes parallel work possible.
The lowest-friction path is the one people actually use, so friction has to be designed out, not documented.
Language models are good at reading messy pages and diffs, but anything people need to trust, such as gap checks, is better as deterministic, tested rules.
Personalization can be cheap. A weighted blend of a few vectors, computed once after each ingest, makes lookups both fast and personal.
Plain language matters. A feature card is only useful if someone outside engineering can repeat it.

What's next for ORION

Real accounts and permissions, replacing the user ID setting.
Trust and evidence tracking, so every item on the map shows where it came from and how current it is.
Safer capture by default, such as site allowlists and automatic redaction of sensitive fields.
More sources beyond the browser and the codebase, including chat, CRM, and documents.
A direct connector so coding agents and assistants can pull ORION context without custom integration.
Storage that scales past a single file as the graph grows.