Shared Context Layer for Organizational Memory

A 0→1 AI workspace built on one bet: a team's context is the product, not the model. I reset the roadmap to build the shared context layer first, so every agent on top reads from one organizational memory.

Director of Product Design

GTM team

Most organizations treat AI adoption as a tooling problem: give employees a powerful assistant and productivity will follow. Our research suggested the opposite. Across Sales, Customer Success, Product, and Pre-Sales, people weren't held back because their AI tools lacked intelligence. They were held back because organizational knowledge was scattered across dozens of disconnected systems. The bottleneck wasn't generating answers, it was finding context.

That insight reset the product strategy. Instead of building department-specific AI agents first, we built a shared context layer underneath them, so every future AI experience could understand how a team actually works before trying to help it.

The Context screen, the shared brain, with a coverage orb and category chips.

The Context screen, coverage scored as one number, gaps made visible

Organizations are pouring money into AI, but adoption stays inconsistent, and discovery showed why. Teams spent more time preparing to work than working. Before a customer call, an account executive pulled fragments from the CRM, Slack threads, email, support tickets, and old meeting notes. Customer Success managers assembled account health by hand. Product managers stitched the customer voice together from interviews, support conversations, and analytics.

Every team was solving the same problem in isolation. The knowledge existed; access to it did not. The cost showed up as slower decisions, repeated research, inconsistent customer understanding, delayed responses, and expertise trapped inside individuals. As an organization layers AI on top of that, the fragmentation gets more expensive, not less, because an assistant is only as useful as the context it can reach.

To test whether this was a department problem or an organizational one, the researcher and I ran five semi-structured interviews across four functions.

RoleDepartmentSharpest pain pointAccount ExecutiveSalesCustomer info scattered; meeting prep is manual researchSales Development RepSalesLead research is slow; personalization takes real effortCustomer Success ManagerCustomer SuccessHealth monitored by hand; churn risk seen too lateProduct ManagerProductFeedback scattered; synthesizing insight is manualSolutions ConsultantPre-SalesAnswers the same technical questions repeatedly

The workflows looked nothing alike, but every participant described the same underlying problem. Seven themes recurred across all five: information fragmentation, time lost to search, manual meeting prep, repetitive content creation, poor documentation discoverability, knowledge concentrated in individuals, and administrative overhead.

The most revealing signal was what people actually spent their time on. They weren't creating. They were gathering. One sales rep put it plainly: "I spend more time finding information than talking to customers." A product manager described customer feedback as "existing everywhere and nowhere at the same time."

Discovery synthesis, five roles converging on seven shared themes, opportunities ranked by severity and frequency.

Discovery synthesis, five roles, one underlying problem

The original roadmap prioritized AI agents. Research suggested that was the wrong place to start. Every agent we'd scoped depended on information spread across disconnected systems, which meant that without shared context, each one would produce confident, generic answers.

The highest-impact opportunity wasn't automation. It was context acquisition. People were repeatedly collecting, validating, and synthesizing knowledge that already existed inside the company. That became the central bet:

Original direction: build specialized agents for Sales, Customer Success, Product, and Pre-Sales.

New direction: build the shared context layer first, as the foundation everything reads from, and let agents come second.

The revised plan made the context layer the base, then phased the agents on top of it: an enterprise knowledge assistant, then meeting intelligence, then department-specific copilots. That single reordering changed what we were building, from a collection of AI features into a foundation for organizational memory.

The roadmap reorder, agents-first to context-first.

The reorder, build the brain first, let agents read from it

The architecture followed the bet. Context became the spine: surfaces and agents sit on top, and all of them read down into one shared layer fed continuously from the tools a team already uses.

Context-first architecture, surfaces and agents read down into one shared context layer.

Context is the spine, every surface reads from it

I led product strategy, research synthesis, opportunity prioritization, information architecture, interaction design, design-system direction, and the AI workflow itself. I sat with the go-to-market team, the people this was built for, and a researcher co-ran discovery with me. Engineering owned implementation alongside me. My job was to hold the whole experience to one idea: context is the product, not the model.

1. Make context visible. Most AI products bury context in settings and integrations. We made it a first-class surface. Teams could see what information existed, what was missing, and how complete their organizational knowledge was, scored as one coverage number. Context became something a team actively grew, not a screen they ignored.

2. Capture context continuously. Traditional onboarding assumes one person knows everything. Discovery showed knowledge is distributed: managers hold the goals, sales holds the relationships, operations holds the process. A one-time setup form puts that burden on one person and goes stale immediately. So we spread capture across onboarding, team invites, and just-in-time prompts inside chat, so the brain filled from everyone and stayed current.

Onboarding that doubles as context capture, a conversation, not a form.

Onboarding as context capture, the first questions are the first context

3. Remove the clever solution. Early on I built a force-directed graph that rendered a team's "digital twin," nodes and edges, the org as a living network. It demoed beautifully and explained nothing. Looking at it, a team had no idea what to do next, and it made their context feel like a science project instead of something they maintained. I cut it: 2,808 lines across six files, the seeding, the layout engine, the graph queries, all of it, replaced by a coverage orb and category chips. Legible beat clever, and the only way I learned that was by building the impressive version far enough to watch it fail.

The hard part was never building AI. It was changing behavior. Teams had to feel value the moment they contributed information, or they'd never contribute again. So the experience runs as a loop: contribute context, improve the shared memory, get better answers, contribute more. Every interaction reinforces the same mental model, that the team's collective knowledge compounds over time.

The adoption loop, contribute, improve the brain, get better answers, contribute more.

A loop that compounds, not a one-time setup

Two craft decisions carried that loop. Answers come back as composable cards, an account 360, a chart, a drafted email, a CRM sync, stacked into a single coherent reply rather than a wall of text. And adding context reads as filling a gauge, which is what turns data entry into something that feels like progress.

Chat answering in composable live cards, an account 360 assembled from context.

Answers as composable cards, not a wall of text

Three failures taught me more than the parts that went to plan, and they shared one root cause.

An early Context screen shipped with placeholder widgets that read "No data yet," the worst kind of empty state, because it looks finished and does nothing. The fix wasn't a better empty state, it was reusing the command center's working pattern instead of building a weaker one beside it.

The onboarding flow had to be reconstructed once: the steps were duplicated and out of order, and none of that showed screen by screen. It only surfaced when I walked the whole thing end to end as a real team would.

Both failures, and the digital-twin detour, came from the same mistake: designing a screen as if it stood alone. This product is a system. Onboarding feeds context, context feeds the command center, the command center and chat read back from it. The lesson I carry forward is that in a system, the screen is never the unit of work. The seams between screens are.

System thinking had to be enforced, not assumed. The visual language is a token system: color authored in oklch on a deep forest-green primary (oklch(.42 .09 160)), calm and deliberately not the default SaaS blue, with amber banned outside the warning state and a per-function accent so a sales workspace and an HR workspace read as one product. Dark mode is the default, so it couldn't be bolted on at the end; every color is a token with light and dark values and a contrast floor. Because the cinematic surfaces are the riskiest part for accessibility, all motion runs through a single config that honors the OS reduced-motion setting, and the page-load and celebration animations skip entirely when it's set. The whole system is documented live at /design-system, with no hardcoded color allowed past review.

The design system reference page, calm chrome, one decisive accent, light and dark.

The design system, documented live, no hardcoded color past review

The same system in dark mode, the product's default theme.

Dark is the default, every color a token with a light and dark value

The product is live as a complete end-to-end experience. Discovery sized the opportunity across four areas:

OpportunityProjected impactConfidenceInformation search time20 to 30% reductionMediumMeeting administration30 to 50% reductionMediumOnboarding speed25 to 40% fasterLowOverall productivity15 to 25% improvementLow

These are directional research projections, not measured results, and they need production validation. What the work did validate qualitatively: teams engage with context once it's visible, measurable, and actionable, and conversational onboarding captures more of it than a setup form ever did. Post-launch metrics are being collected, and I'll add measured before-and-after numbers once they land.

The context-based command center, assembled from context, surfacing what to act on.

The command center, assembled from context, not a generic dashboard

The command center in dark mode.

Light and dark, down to a single mobile column

I'd test maintenance behavior earlier. The open question was never whether teams would create context, it was whether they'd keep it current. A smaller pilot with real teams would have answered that sooner and shaped prioritization.

I'd also start narrower. The product was built for any function, but Sales showed the strongest pain and the clearest ROI. Going deep on one team before generalizing would likely have validated the model faster.

I came into this believing AI adoption was a model problem. I left believing it's a context problem. Models will keep improving and that advantage will commoditize. The durable edge is how well an organization captures and uses what it already knows. That belief became the product strategy, and in the end it became the product.

Reset the AI strategy, shared context layer first, department agents second

Discovery across 5 roles in 4 departments reframed the problem from tooling to context

Killed the clever version, deleted a 2,808-line force-directed "digital twin" for a legible coverage orb

Designed continuous context capture across onboarding, invites, and just-in-time chat prompts

Token-based design system, dark-mode-default, reduced-motion honored end to end

Shipped the full experience, onboarding, the context brain, command center, and chat, in light, dark, and mobile