Ambience.Get started
What to expect

Ambience is the context layer underneath your team's agents.

Last updated 2026-05-10

Ambience sits below the agent tools your team already uses. Claude Code, Codex, Cursor, and MCP clients can all read from and write to the same governed context layer, instead of each session becoming a separate pocket of memory.

For users, that means Ambience mostly goes into the background. You keep working in the agent interface you chose. Behind it, Ambience retrieves the context you are allowed to use and writes back the decisions, assumptions, and references that should carry forward.

The short version

Ambience turns agent sessions into shared operating context. It captures what is worth carrying forward, removes what should not be stored, applies the right scope, and records how context moved.

Where Ambience sits

Ambience is not the chat surface, the IDE, the CRM, or the source of truth for the business. It is the layer that helps agents use those systems with the context your team has already built.

Operating model
Systems of record

CRM, repos, docs, tickets

Where the work and source material already live.

Agent interfaces

Claude Code, Codex, Cursor, MCP

Where users ask agents to operate on that work.

Context layer

Ambience

Where durable context is governed, refined, and made reusable.

The useful mental model is: your tools hold the work, your agents help operate on the work, and Ambience carries the durable context between agent sessions.

What users experience

From a user's point of view, Ambience is not another place you have to constantly maintain. It is the background layer that makes your agent less likely to start cold.

  1. You start a session in a connected agent such as Claude Code, Codex, Cursor, or another MCP client.
  2. Ambience makes relevant, permitted team context available at the start of the session.
  3. The agent works normally, using the context it is allowed to see.
  4. At the end, durable takeaways are extracted, redacted, scoped, and written back as memories.
  5. Future sessions can use those memories, subject to the same permissions and audit trail.

The important part is the loop: each session can benefit from what came before, and each session can leave something useful behind.

How a memory moves through the system

A memory moves through three layers before another user's agent can rely on it: the harness around the user's agent, the governance platform, and Ambience agents that refine context over time.

Memory lifecycle

Write path, governance path, read path.

looped context
User surface

User's agent

Claude Code, Codex, Cursor, or any MCP client doing the work.

session runs
Capture

Ambience harness

Wraps the session, fetches relevant context, and proposes durable takeaways.

Govern

Governance platform

Redacts, classifies, scopes, grants access, and writes the audit trail.

approved memory
Store

Memory graph

Personal, team, project, org, and sensitive context becomes durable.

Read rules are applied every time

A memory can exist without being visible to every teammate or agent.

The next session gets context

Only relevant, permitted memories are injected back into the user's agent.

Improve

Ambience agents

Monitor stale context, reduce duplication, refine titles, and suggest reusable skills.

The user sees better background.

The system work happens underneath the agent interface: retrieve, redact, scope, audit, refine, and reuse.

Detail path

session to reuse

  1. 01

    A session starts in the user's agent

    A teammate works in Claude Code, Codex, Cursor, or another connected client. The Ambience harness runs around that session and asks for relevant context the user is allowed to see.

  2. 02

    Permitted context is retrieved

    The governance layer filters by scope, project, team, and grants. The user's agent receives only the memories that match the work and the user's access.

  3. 03

    The agent does the work

    The user keeps working in their normal tool. The agent can use customer history, project decisions, territory notes, or team conventions without the user re-explaining them.

  4. 04

    Durable takeaways are proposed

    At the end of the session, Ambience extracts the parts worth keeping: decisions, assumptions, references, risks, handover notes, or a repeated pattern.

  5. 05

    Governance is applied

    The memory is redacted, classified, scoped, and written with an audit trail. Sensitive customer details, secrets, and identifiers are removed or constrained before storage.

  6. 06

    Ambience agents improve the graph

    Background agents monitor context quality: deduplicating, resolving conflicts, refining titles, spotting stale notes, and suggesting when repeated practice should become a reusable skill.

  7. 07

    The next session starts warmer

    A later agent run retrieves the memory when it is relevant and permitted. The user experiences that as background context, not another document to maintain.

Workflows to try first

The best first workflows are places where context already leaks between tools, people, and meetings. Start with one narrow loop where the handoff cost is obvious.

Workflow

Customer handover

Support
  1. StartA support engineer finishes an implementation session for Acme.
  2. MemoryAmbience keeps the integration decisions, unresolved risks, preferred escalation route, and next customer-facing promise.
  3. Next sessionWhen an account manager or solutions engineer starts their own agent session, the customer context is already there, scoped to the account or project team.

Territory planning

Sales
  1. StartA sales team researches a territory and asks an agent to cluster accounts by segment, objections, and likely buying triggers.
  2. MemoryAmbience stores the territory assumptions, target-account rationale, competitor patterns, and messaging that worked or failed.
  3. Next sessionFuture planning sessions can reuse the operating picture instead of rebuilding the territory from scratch each quarter.

Project delivery

Engineering
  1. StartAn engineer uses an agent to debug a rollout problem across a customer integration and an internal service.
  2. MemoryAmbience keeps the architecture constraint, the fix that worked, the log source that mattered, and the thing not to try again.
  3. Next sessionThe next engineer's agent sees the project memory and avoids repeating the same investigation.

Team onboarding

People
  1. StartA new teammate opens their first agent session inside an unfamiliar repo, account, or territory.
  2. MemoryAmbience retrieves the team's conventions, recent decisions, common failure modes, and the project references worth reading first.
  3. Next sessionThe agent can guide them using the team's actual working context, not a generic onboarding script.

What gets kept

Ambience is interested in durable context, not every stray token from a conversation. Good memories tend to look like:

  • Decisions the team made and why they were made.
  • Project conventions, naming patterns, and preferred approaches.
  • References an agent or teammate should know about next time.
  • Failure modes, fixes, and things the team has already tried.
  • Reusable skills or playbooks that should become team muscle memory.
decision1d ago

Use project-scoped rollout notes

Release notes for the payments project stay with the implementation team and do not leak into org-wide context.

scopeprojectbyRinarolloutpayments
failure3d ago

Do not retry webhook replay without idempotency key

The last incident came from replaying customer events without the original dedupe key. Keep the warning visible.

scopeteambyMarcusredactedwebhooksincident

What stays protected

Shared context is only useful if people can trust it. Before a memory is stored, Ambience redacts sensitive information such as secrets, tokens, contact details, and customer identifiers. Then the memory is placed in a scope: personal, team, project, org, or sensitive.

A future agent run only receives context the current user is allowed to read. Every read and write is recorded in the audit log, so admins can understand how context moved through the organisation.

The principles

Context belongs below the tool

Teams use more than one agent. Ambience sits underneath them, so context can move across Claude Code, Codex, Cursor, and MCP clients without being trapped in one interface.

The graph should reflect the business

Customer work, territory plans, project decisions, and team playbooks need different audiences. Scopes let context follow the shape of the organisation.

Governance comes before recall

The question is not just whether an agent can remember. It is whether the right agent can read the right context, with redaction and audit already handled.

Work should leave a trail

A good session leaves behind decisions, assumptions, references, and next steps that another teammate or agent can build on later.

What Ambience is not

Ambience is not a replacement for human judgement, source control, security review, or documentation that people need to read directly. It is also not a blank cheque for agents to see everything your organisation knows.

Think of it as governed recall for the work your agents are already doing. It helps the right context show up sooner, with fewer repeated explanations and fewer lost decisions.

How to get the most from it

  • Pick one workflow first: a customer account, a territory, or an active project.
  • Let agents capture the why, not just the final answer.
  • Use project and team scopes deliberately.
  • Promote repeated lessons into reusable skills.
  • Review sensitive or unusual context before it becomes shared practice.

The next session should not have to rediscover the last one.

Install Ambience, connect your agents, and let the useful parts of your team's work start compounding.


For a deeper trust view, read Security & trust. For the product category, read Single-agent memory vs team context. Explore skills.