# How we use Ambience to build Ambience

> 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.

Ambience works best when it lives beside the work instead of waiting for somebody to tidy the work later.

## The working loop

1. Source: a call, ticket, PR, thread, doc, file, or agent session creates useful context.
2. Memory: Ambience stores the durable decision, convention, failure, skill, pattern, or reference.
3. Reuse: the next approved agent starts with the memory, source, scope, and redaction state.

Example memory:

- Type: decision
- Title: Run onboarding as a permissioned app sweep
- Body: Ambience onboarding shows available agent-connected sources, asks what to include, and proposes source-linked memories for review before saving.
- Scope: org
- Source: product call and implementation session

## 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.

## Related

- [How to build company context with Ambience](https://ambience.sh/blog/build-company-context-with-ambience)
- [Company Context Maturity Model](https://ambience.sh/company-context/maturity-model)
- [Granola call to memory](https://ambience.sh/examples/granola-call-to-memory)
- [GitHub PR to engineering memory](https://ambience.sh/examples/github-pr-to-engineering-memory)