How we use Ambience to build Ambience.
Published 2026-06-07 - 9 min read
A field note on using Ambience inside product work: calls, tickets, PRs, agent sessions, review loops, and the habits that make company context compound.
The first useful version of Ambience was not a dashboard. It was the moment an agent stopped asking us to re-explain a decision the team had already made.
- We save the small decisions that would otherwise become repeated explanations.
- We keep raw sources where they belong and store only the durable Ambience memory.
- We review context like product work: scope it, source it, redact it, and prune it when it stops helping.
The working loop
Ambience works best when it lives beside the work instead of waiting for somebody to tidy the work later. The loop is simple enough to remember and strict enough to trust.
Source
A call, ticket, PR, thread, doc, file, or agent session creates useful context.
Memory
Ambience stores the durable decision, convention, failure, skill, pattern, or reference.
Reuse
The next approved agent starts with the memory, source, scope, and redaction state.
Run onboarding as a permissioned app sweep
Ambience onboarding shows available agent-connected sources, asks what to include, and proposes source-linked memories for review before saving.
The habit
Whenever a decision lands, we ask one plain question: will a future agent need this before it acts? If the answer is yes, the decision becomes an Ambience memory with a source and scope.
That sounds small. It is small. The leverage comes from doing it at the edge of real work, while the source is still fresh and the reason is still clear.
Calls become decisions
A Granola call is not the memory. It is the source. The memory is the durable product decision, owner, caveat, or constraint that should survive the call.
This keeps Ambience from becoming a transcript archive. The call stays inspectable for people who have access. The agent gets the part that changes future work.
Tickets become project context
Linear is where the work gets shaped. Ambience is where the context that should travel with the work becomes explicit.
If a ticket settles an access boundary, a rollout constraint, or a product principle, we save that as project memory instead of expecting every future coding session to reread the whole issue.
PRs become conventions
GitHub has a lot of hidden company context. Review comments explain why a pattern exists, why a shortcut is risky, or why a route needs a test.
When that reasoning should outlive the PR, we save the convention. The next agent can follow the rule before it touches the same code path.
Sessions become lessons
Agent sessions are full of useful context, but only a small part should become shared memory. We save decisions, failures, patterns, and skills. We do not save play-by-play transcripts.
The standard is whether the memory makes the next agent better without making the team trust a vague summary.
Weekly review
Once a week, we look for stale memories, over-broad scopes, duplicates, unresolved conflicts, and repeated workflows that should become skills.
It is ordinary product maintenance for the context layer agents use every day.
The routines that make it stick
After customer and product calls
We save decisions, owner changes, rollout caveats, and product constraints. We do not save the whole call.
After PRs and agent sessions
We save conventions, failure modes, and repeatable implementation patterns while the source is still close.
During weekly review
We resolve conflicts, narrow scopes, remove stale context, and promote repeated workflows into skills.