Keep context across the team

When you'd do this

• Every session starts with someone re-explaining the architecture to their assistant, and each person's explanation is slightly different.
• Two engineers ask the same question about a service and get different answers, and nobody can say which one is right.
• A teammate spent an afternoon confirming which service really calls an endpoint, and that finding now exists only in their chat history.
• You are the platform owner or an administrator setting up CodeZero and Vörr for a team, and want to do the connection and mapping work once rather than per person.
• People are joining, moving teams or leaving, and you want what they knew about the system to stay with the organisation.
• You lead an engineering team and want to know where the shared picture is thin: unmapped services, unverified dependencies, accounts that were not fully scanned.

Before you start

• CodeZero installed in VS Code for each engineer, with Claude Code, Codex, GitHub Copilot or Cursor as the agent, signed in to the organisation, and the organisation's repositories connected and indexed.
• Vörr onboarding completed once by an administrator: workspaces and environments created, at least one repository mapped and one cloud account connected. Other members do not repeat onboarding.
• Vörr added to Claude, ChatGPT or another MCP assistant by each person who will ask questions, with their own consent step. ChatGPT needs a paid plan with Developer mode turned on.
• An administrator for anything that changes the shared setup: Git providers, cloud accounts, connectors, workspaces, environments and the service map. Members can ask questions and read what their workspaces contain, and they can verify Graph edges and name features in CodeZero.

Operations

Shared context is built once, improved by everyone who uses it, and kept current. The operations below follow that order: separate shared from personal, set up the shared parts, improve answer quality, keep it current, bring people into it, and check that it is working.

Know what is shared and what is personal

Before improving anything, be clear about which parts of the context every member's assistant reads, and which belong to one person. Improvements to the shared parts help everyone; improvements to personal parts help only their owner.

A useful rule: if a finding would help the next person who asks, it belongs in one of the shared rows, not in a saved chat. A verified dependency is a Graph verdict, a name mismatch is a service map entry, and a functional area is a named feature.

Set up the shared context as an administrator

1. In Vörr, create a workspace for each team or ownership group, and the deployment environments the organisation uses, marking each as production or non-production.
2. Connect the Git provider and select every repository that takes part in the same product or service flow. A repository that is not connected is outside Vörr's knowledge, and Vörr says so rather than guessing at it.
3. Map each repository to the workspace that owns it, and map important branches to environments, for example main to Production and develop to Staging.
4. Connect the cloud accounts with read-only credentials and start a scan. Connecting only validates the credentials; a completed scan is what produces the resource map answers rely on.
5. Connect the observability, error-tracking, logging, tracing and CI tools the team uses, with read-only, least-privilege tokens such as a Grafana Viewer service account. Vörr supports more than 30 tools; CloudWatch comes through the AWS connection, and GitHub Actions, GitLab CI and Bitbucket Pipelines through the code connection.
6. Scope each connection to the workspaces that should see it, or leave it available to all of them.
7. In CodeZero, confirm that the organisation's repositories show as indexed in Files, including the ones no individual has cloned.

A good setup is one where a member who has never configured anything can ask about a service and get an answer that names its sources. Each connection is set up once, by an administrator, rather than each engineer installing a CLI or MCP server and pasting a token on their own machine.

Map the important services explicitly

1. In Vörr, list the real service, job and project names each connected tool uses. The same service is often checkout in the code, checkout-api in Datadog and payments-checkout-deploy in Jenkins.
2. Start with the services that matter most: the ones on call is responsible for, the ones in the main request path, and the ones people ask about most.
3. As an administrator, add each service to the service map and link its names across tools. You can do this from a connector's service mapping rows or in the service map itself.
4. Ask a source-specific question and check that the answer now reports an explicit match rather than an inferred one.

Vörr resolves names through the service map first, then confirmed aliases, then catalogue names, then the raw name, and every result says which route it took. A guess from the raw name is labelled name. Mapping a service turns every future answer about it, for everyone, into an explicit match.

Verify inferred cross-repository edges

1. Open Graph in CodeZero. Dashed edges are inferred: an HTTP call matched to a route in another repository, a service referenced through Kubernetes, Helm or Compose config, or a queue producer matched to a consumer.
2. Select an edge to see the file and line it was inferred from and, for HTTP and config edges, its confidence (high, medium or low for HTTP edges; high or medium for config edges).
3. On HTTP edges, use Verify to ask your agent to read the call site and decide: confirmed, wrong, or retargeted to the repository the call really reaches.
4. Prioritise low-confidence edges on services people make decisions about, and edges where a path literal matched routes in several repositories.

Verdicts are kept for the organisation, shown on the edge with who recorded them and when, and applied every time the graph is rebuilt, so a correction survives later indexing. A confirmed edge stays, a wrong one is removed from the graph, and a retargeted one points at the repository the call really reaches.

Name the functional areas

1. Open Functions in CodeZero. Before naming, functional areas appear as structural paths such as src/billing or src/webhooks.
2. Select Name all features. Naming uses your own coding agent, and the resulting names are shared with the organisation.
3. Open the features people ask about most and read each flow: Entry, Goes Through, Reads / Writes, and any dependency in another repository.
4. If a name is misleading, raise it with the team. The names are what new engineers and their agents will use to find the code.

Named features give the team a shared vocabulary that maps back to real files, so "the refund flow" means the same code to everyone and to every agent.

Close coverage gaps

1. In Vörr, check scan coverage per cloud service. Completed and scanned-empty are answers; access denied, failed and throttled mean the area was not fully seen.
2. Fix access-denied results by extending the read-only role or policy for that service, and re-run the scan. Re-run throttled or failed scans at a quieter time.
3. Review unindexed resource types and Terraform coverage, so you know which questions the resource map cannot answer.
4. Ask Vörr which services nobody watches and which questions return no connector. Each one is either a tool that should be connected or a service that genuinely has no monitoring.
5. In CodeZero, check that every repository in a flow is connected and indexed. A repository missing from the index is invisible to everyone's agent.

An answer that says no connector, or shows a service as unwatched, is useful information. It tells you exactly what is missing, rather than returning an empty result that looks the same as "nothing is wrong".

Keep it current

1. Rely on the code index to follow the default branch; it covers committed code only.
2. Remember that it does not see unmerged branches or uncommitted work. For your own repository, CodeZero prefers your local working tree, which does include them.
3. Re-scan cloud accounts after significant infrastructure changes. Vörr does not scan automatically; a scan is started deliberately.
4. When a service is added, renamed or split, update the service map and the workspace and branch mappings in the same change, as an administrator.
5. Review mapping and coverage gaps on a regular schedule: services newly matched by name or left unmapped, unwatched services, scan errors and low-confidence edges.

Bring someone into the shared context

1. Add them to the organisation and to the right workspaces in Vörr. Their view follows the workspaces they belong to.
2. They add Vörr to their own assistant, giving explicit consent. That authorisation is theirs; it does not change anything in Vörr, and it does not expose stored credentials to the assistant.
3. They install CodeZero, sign in to the organisation and see every indexed repository in Files, without cloning anything first.
4. They start from the shared context: named features, verified edges in Graph, and the service map behind Vörr's answers.

The new person gets the same connections, names and verified relationships as everyone else, rather than a copy of someone's prompt file. The onboarding page covers the full first week.

• Understand and onboard to a codebase

Check consistency between teammates

1. When two people get different answers to the same question, compare the sources, match quality and environment each answer reports.
2. If the sources differ, check workspace membership first: each person sees the connections scoped to their workspaces.
3. If one answer used an explicit match and the other an inferred one, or one says no connector, that is a mapping or connection gap, not a disagreement about the system.
4. If two metric sources disagree, Vörr reports each separately and flags the disagreement rather than averaging them. Decide which source is authoritative for that service.
5. Fix the gap in the shared context (map the service, verify the edge, connect the source, adjust the workspace scope) and ask again.

Answers should agree because they come from the same index, service map and connections, not because people use the same prompt. When they disagree, the provenance tells you which shared piece is missing.

See what teammates are working on

CodeZero Tasks can show work started by other people on your team alongside your own, so you can see who is changing which repository before you plan a change that touches it. See Delegate approved work.

Keep knowledge when people leave

• Verdicts, feature names, service map entries and connections belong to the organisation, so they stay when the person who created them leaves.
• That person's assistant authorisation is tied to them. Removing their membership or the connector from their assistant ends their access and changes nothing in the shared context.
• Their saved conversations are personal and unsaved ones expire after seven days. Before someone leaves, turn anything they worked out into a verdict, a mapping or a named feature, or into your own written docs.
• Connections set up with personal tokens are a risk. Prefer service accounts for connectors, so a departure does not silently break a source everyone relies on.

Measure whether it is working

There is no single score. Look at the answers people actually get and at the gaps the products report:

• Answers about important services carry explicit matches, not name or unmapped ones.
• Edges people rely on in reviews and incident work are verified rather than inferred, and wrong edges have been rejected or retargeted.
• Scan coverage shows completed or scanned-empty for the services that matter, with access-denied and throttled results closed.
• Fewer questions come back with no connector, and fewer services show as unwatched.
• Fewer sessions start with someone re-explaining the architecture, and fewer "who knows how this works" interruptions reach senior engineers.
• When two people disagree about the system, the provenance points to a specific gap that someone then fixes.

Without CodeZero or Vörr

Teams already share context without these products, and it helps. A CLAUDE.md or AGENTS.md committed to each repository, a shared prompt library, architecture docs and runbooks all give every assistant a better starting point. Claude Code reads the files in your checkouts and runs whatever CLIs and MCP servers are configured on your machine; ChatGPT works with what you paste and the connectors you enable. The limits are in what that shared text can carry.

Keep your CLAUDE.md files and docs. They carry intent, conventions and decisions that code cannot show. CodeZero and Vörr cover the parts docs cannot keep current on their own: what the code does now, which repositories and tools exist, verified relationships and per-user access.

With CodeZero and Vörr

One code index (CodeZero)

Committed code on the default branch of every connected repository, readable by everyone's agent without a local clone.

Verified relationships (CodeZero)

Inferred cross-repository edges with file:line evidence (and a confidence on HTTP and config edges), and verdicts kept for the organisation.

Shared vocabulary (CodeZero)

Named features that map functional areas back to entry points, files, data and other repositories.

Team view of work (CodeZero)

Tasks showing teammates' work and which repository each part belongs to.

Connections set up once (Vörr)

Repositories, cloud accounts and more than 30 observability and CI tools, connected by an administrator with read-only credentials and scoped to workspaces.

Consistent names (Vörr)

The service map and confirmed aliases, with every result reporting its source, match quality and environment.

Visible gaps (Vörr)

Scan coverage per service, no connector instead of a guess, and services nobody watches.

The two products work side by side, not inside each other. A dependency verified in CodeZero's Graph and a service mapped in Vörr are separate pieces of shared context; together they mean a question in the editor and a question in Claude or ChatGPT both start from the organisation's picture of the system rather than one person's.

Worked example: two answers about the refund flow

The repositories, service names and results below are examples, not output from a real run.

Two engineers on the payments team ask Vörr whether the refund service is erroring after a deploy. One gets a clean answer from Sentry and Datadog. The other gets Sentry only, with the Datadog result marked inferred. The team lead asks Vörr to explain the difference.

refunds: errors, last 60 min, production (illustrative)
  Sentry    refunds-api        explicit (service map)   14 events, top issue TimeoutError
  Datadog   payments-refunds   name                     error rate 0.8%
  Jenkins   -                  no connector in workspace 'payments'
Coverage notes
  Datadog result matched by name only; map payments-refunds to refunds to make it explicit.
  Deploy history for refunds unavailable: the Jenkins connection is scoped to workspace 'platform'.

Two gaps explain the difference: the Datadog name is not in the service map, and the Jenkins connection is scoped to a workspace the second engineer does not belong to. An administrator maps payments-refunds to refunds and adds the payments workspace to the Jenkins connection's scope. Separately, a developer opens Graph in CodeZero to check what calls the refund endpoint.

Inferred edges into refunds-api (illustrative)
  orders-worker  -> POST /refunds        medium   src/jobs/cancel.ts:88
  support-tools  -> POST /refunds        low      src/admin/refund.ts:41

Verify: orders-worker -> refunds-api
  Base URL from REFUNDS_URL, set to refunds-api in helm/values-prod.yaml.
  Verdict: confirmed.
Verify: support-tools -> refunds-api
  Base URL from LEGACY_BILLING_URL; the call reaches billing-api's /refunds route.
  Verdict: retargeted to frigga-example/billing-api.

Conclusion: both engineers now see Sentry, Datadog and Jenkins for refunds, all with explicit matches, and anyone looking at the refund endpoint in Graph sees one confirmed caller and one corrected one, each with a note. Verification: both engineers ask the original question again and get the same sources, match quality and environment. Follow-ups: the lead adds the remaining payments services to the service map, and schedules a monthly review of name matches and low-confidence edges.

Verify and follow up

• Provenance: every Vörr result names its source, match quality and environment. After a mapping change, check that the match is now explicit.
• Workspace scope: when answers differ between people, confirm which workspaces each person belongs to and which workspaces each connection is scoped to.
• Graph: check that verdicts appear on the edges you verified, and that edges you marked wrong are gone.
• Coverage: re-check scan coverage after changing permissions, and re-run the scan; confirm access-denied and throttled results are gone.
• Index state: in CodeZero Files, check that repositories show as indexed rather than still indexing or failed.
• Next: carry gaps you found into a regular review, and use the shared context in the work it supports: onboarding, reviews, incidents and cross-repository changes.

Limits

• The index covers committed code on the default branch. Unmerged branches and uncommitted work are not shared; only your own local working tree adds them, for you.
• Inferred edges and name-based references are heuristic, not compiler-accurate. Same-named symbols can appear, and an edge stays inferred until someone verifies it.
• The shared context is only as complete as what is connected, scanned and mapped. A repository that is not connected, or an account that was not fully scanned, is a gap for everyone; the products report it rather than fill it in.
• Changing connections, workspaces, environments and the service map needs an administrator. Members can report gaps and verify edges, but cannot change the shared Vörr setup.
• Vörr is read-only towards your systems from the assistant. It reads code, cloud resources and signals; it does not change infrastructure, code or CI.
• Each person's assistant authorisation and chat conversations are personal. Unsaved conversations expire after seven days, and findings in them are not shared until someone records them in the shared context.
• CodeZero and Vörr are separate products. Vörr does not run inside CodeZero and CodeZero does not call Vörr; you bring findings from one to the other yourself.
• Neither replaces written decisions, conventions or runbooks. They describe what the system is and does, not why it was built that way.

Related

• Understand and onboard to a codebase
• Understand system architecture
• Answer system questions without the IDE
• Make engineering decisions
• Delegate approved work
• What the research says
• CodeZero: Work across repositories
• CodeZero: Explore the Code Graph
• CodeZero: Trace a product feature
• Vörr: Set up your organization
• Vörr: Connect and map repositories
• Vörr: Connect observability and CI tools
• Vörr: Roles and permissions
• Vörr: Security and privacy