How Vörr AI and CodeZero work together

Use caseAll users9 min

Vörr and CodeZero are two separate products that cover two halves of most engineering work. Vörr answers what is happening in the running system, from code, cloud, observability and CI, inside the assistant you already use. CodeZero answers where something lives in the code and what a change would touch, and carries the change from plan to approved execution in VS Code. This page explains each layer, where they meet, and which one to start with.

When you'd read this

Your team has access to both products and you want to know which one to open for a given question.
You found something in Vörr, such as an error, a deploy or an exposed resource, and need to turn it into a code change.
You are planning a change in CodeZero and want to check what it means in production first.
You are setting up the products for a team and need to know what to connect and who has to do it.
You want to know what the products add on top of Claude Code or ChatGPT on their own.

Two context layers

	Vörr AI	CodeZero
What it knows	Connected repositories, cloud resources (AWS, Google Cloud, Azure), metrics, errors, logs, traces, alerts and deploys from more than 30 tools, all mapped to workspaces, environments and services. AWS cost.	The organisation's indexed repositories: files, symbols, routes, config, dependencies, inferred cross-repository edges, data access, feature maps, plus Git history and your local working trees
Where it runs	As an MCP connector in Claude, ChatGPT or another MCP assistant. A web app for Cloud Mapping, scan results and Architecture.	A VS Code extension, with Claude Code, Codex, GitHub Copilot or Cursor as the agent
What it can change	Nothing from the assistant. It has read-only access to your systems.	Code, only through the agent, and only with your confirmation or under a plan you approved. The agent asks before editing outside the plan's repositories.
How code is read	Through the organisation code index	Through the same organisation code index, preferring local working trees when they are present
Typical question	Why did the payments deploy fail, and what changed in production at 14:05?	What calls this route across all repositories, and what would break if it changed?

What Vörr knows and does

Vörr connects the systems your organisation runs on and answers questions about them from your assistant. Each fact carries its source, the environment and how the service name was matched: explicit, identity, exact, name, suggested or unmapped. Names are resolved through the service map, then confirmed aliases, then catalogue names, then the raw name, so checkout, checkout-svc and web-checkout can be treated as one service.

Cloud: resource search and detail, exposure (public, private, isolated, unknown), neighbours, upstream and downstream blast radius, Terraform management, and scan coverage per service.
Live signals: error rate and latency per source, top errors with stacks, redacted logs, trace waterfalls, service health, SLOs, alerts, dashboards and Kubernetes consumers.
Deploys: one organisation-wide feed across connected CI/CD tools, regression windows Vörr detects (with Grafana connected), shown alongside deploys, and CI build-failure diagnosis.
Investigation: root-cause scoring across eight categories, the preceding deploy, recurring patterns, and guided error-to-code and config-to-code investigations.
Coverage: which sources can answer a question, why an answer might be wrong, and which services nobody watches.

The Vörr web app is for visual surfaces: Cloud Mapping, scan results and Architecture. You chat with Vörr in your assistant, not in the web app.

What CodeZero knows and does

CodeZero gives the coding agent the organisation's code as context, including repositories that are not cloned on your machine, and puts a plan and approval step between a request and an edit.

Understand: text and symbol search, references and callers across repositories, per-repository routes, config, dependencies and owners, and files read with last-commit provenance.
Graph: modules and files across repositories, plus inferred cross-repository edges (HTTP calls matched to routes, deployment config, queues). Each edge has file:line evidence, HTTP and config edges also show a confidence, and HTTP edges have a Verify action.
Functions: named functional areas traced from entry point through the code to the data they read and write.
Plan and build: Chat, plans that name repositories, phases and verification commands, tasks, and Auto, Planned and Normal modes. Coffee Mode finishes approved work unattended.
Git Tree: history, blame, branch comparison and everyday Git operations, with explicit confirmation for destructive actions.

What each one can change

Vörr: Nothing from the assistant. It scans and reads with read-only credentials, and stored credentials are never exposed to the assistant. It cannot roll back a deploy, restart a pod, silence an alert or edit infrastructure. Those actions stay in your own tools.
CodeZero: Code, through the agent. In Normal mode you confirm each change. In Planned mode the agent makes no code changes until you approve a plan. Auto asks before each small direct edit and plans bigger work; after approval, edits in the plan's repositories proceed. The agent cannot approve its own plan, it asks before editing outside the plan's repositories, and outside Coffee Mode only the declared verification commands run without asking.
Coffee Mode: Runs an approved, fully clarified plan unattended. It never commits, pushes, switches branches, rewrites or merges history, publishes or runs destructive commands. The changes stay in your working tree for you to review.

Separate products, carried by you

Vörr does not run inside CodeZero, and CodeZero does not call Vörr. They are connected to the same organisation, and both read code through the same organisation code index, so a repository and file named by one can be opened in the other. Nothing is passed between them automatically.

In practice you carry the finding. Copy the service, environment, deploy (and its commit or version, where the CI source reports one), repository and file from the Vörr answer in Claude or ChatGPT, and paste them into a CodeZero prompt in VS Code. Going the other way, take the route, table or service a CodeZero plan touches and ask Vörr what it looks like in production.

Hand-over prompt in CodeZero

Vörr shows the 14:05 production deploy of inventory (the CI source reports version d40b7f1) preceded a p99 increase in checkout; the bottleneck span is the stock lookup in inventory/src/stock/repository.ts. What changed in that file since the previous deploy, and what calls GET /stock/:sku across all repositories?

Hand-back prompt in Vörr

Using Vörr, the CodeZero plan changes the stock lookup route in inventory. Which services call inventory in production, what are their current error rate and p99 per source, and is the inventory database Terraform-managed?

These prompts are illustrative: replace the service, file, route and version names with your own.

Capability map

This shows which product carries each kind of work. Both means the work usually needs one product for the running system and the other for the code.

Activity	Vörr	CodeZero	Both
Understanding a codebase or system	Services, environments, cloud topology and who calls whom at runtime	Graph, Functions, search and Chat across repositories	Architecture as designed in code, checked against what runs
Building and changing code	What a change means in each environment	Plan, approval, scoped edits, verification	Cross-repository features with production impact checked first
Testing	Failing tests from CI logs	Tests as plan verification commands; finding which tests cover a path	Reproducing a production failure as a test
Code review	Runtime callers and health of the services touched	Impact across repositories, history, blame	Reviewing a PR against both code and production dependencies
Deploys and CI	Organisation-wide deploy feed, build-failure diagnosis	The commits and files in a deploy's range	From a failed build to the fix
Debugging	Metrics, errors, logs and traces per source, root-cause scoring	Code path, callers, configuration the code reads	Signal to code to verified fix
Incidents	Preceding deploy, blast radius, recurring patterns	The fix as an approved plan	From the first alert to the fix that closes it
Observability	Service health, SLOs, alerts, coverage gaps, unwatched services	Where instrumentation lives in the code	Adding checks where coverage is missing
Infrastructure	Resources, neighbours, blast radius, Terraform coverage	Infrastructure-as-code and deployment config in repositories	Tracing a resource to the code and config that use it
Security and exposure	Exposure classes, network path to load balancers and security groups	Code and config behind an exposed service	Reviewing exposure and changing the config that causes it
Cost	AWS spend, waste, savings, rightsizing	The code and config that set instance sizes or retention	Turning a savings finding into a reviewed change
Planning and decisions	Current state of the system, from the assistant without an IDE	Impact across repositories, owners by commit history	Plans and decisions grounded in code and production

Each activity has its own page with operations and copyable prompts.

The combined loop

Most work that involves both products follows the same six steps. The prompts below are the shape to copy; replace the names with your own.

Signal (Vörr, in Claude or ChatGPT): ask what is happening. Check the source, environment and match quality on each fact, and ask about coverage before trusting a quiet result.
Narrow (Vörr): get to a deploy, a service, a repository and a file, using the deploy feed, root-cause scoring or an error-to-code investigation.
Code (CodeZero, in VS Code): paste those facts into a prompt. Read the file and its history, check callers and cross-repository edges, and verify the edges you rely on.
Plan (CodeZero): describe the change. The agent investigates, asks the decisions only you can make, and proposes a plan naming every repository, phase and verification command.
Approve and run (CodeZero): approve the plan, then run tasks one at a time or hand the remainder to Coffee Mode. Review the working tree in Git Tree, then commit, push and open the PR yourself.
Verify (Vörr): after the change deploys, confirm the deploy in the deploy feed and compare the signal before and after, in every source.

1. Signal (Vörr)

Using Vörr, is checkout degraded in production? Give error rate and p50/p95/p99 per connected source for the last hour against the same hour 7 days ago, with the matched service name and match quality.

2. Narrow (Vörr)

Using Vörr, list every production deploy in the organisation in the hour before the change, run root-cause scoring for checkout, and take the top error to the repository, file and function that produce it.

3. Code (CodeZero)

In inventory, what changed in src/stock/repository.ts since the previous deploy (version d40b7f1)? What calls getStockLevels and GET /stock/:sku across all indexed repositories? Show the evidence and confidence for each edge.

4. Plan (CodeZero)

/plan Fix the stock lookup in inventory so it uses the (sku, warehouse_id) index again. Reproduce it with a failing test first, list every repository that calls the route, and use the test suite and the query-plan check as verification commands.

6. Verify (Vörr)

Using Vörr, the inventory fix deployed at 16:40. Confirm the deploy in the deploy feed, then compare checkout p99 and error rate from 16:45 to 17:15 with 13:30 to 14:00, per source.

The loop also runs the other way. Start in CodeZero with a planned change, check the production picture in Vörr before approving, and confirm in Vörr after it ships.

Which one to start with

Situation	Start with	Then
An alert fired or an error rate moved	Vörr: confirm per source, get the deploy and file	CodeZero for the fix
A build or deploy failed	Vörr: build-failure diagnosis from CI logs	CodeZero if the fix is in code
You need to add or change a feature	CodeZero: Functions, impact, plan	Vörr to check the services touched in production
A change spans several repositories	CodeZero: cross-repository edges and a plan naming every repository	Vörr to check runtime callers before approving
You are new to a codebase	CodeZero: Graph and Functions	Vörr for how it runs and where it is deployed
Someone asks if a resource is internet-facing	Vörr: exposure and network path	CodeZero for the config that sets it
Finance asks why the AWS bill went up	Vörr: spend trend, waste and savings	CodeZero for the change that implements a saving
A manager or PM needs an answer without an IDE	Vörr from Claude or ChatGPT	Usually nothing else
Reviewing a pull request	CodeZero: impact across repositories	Vörr for the health and callers of affected services

Who uses which

Developers: Both. Vörr for runtime and cloud questions, CodeZero for understanding and changing code.
On-call and SRE: Vörr first, to connect errors, deploys and resources. CodeZero when the fix needs a code change.
Tech leads and reviewers: CodeZero for impact and plan review. Vörr for what a change means in each environment.
Engineering managers and product: Vörr from Claude or ChatGPT, for questions about the system without opening an IDE.

Principles both products share

Provenance: Answers show what they are based on. CodeZero gives file references with the indexed commit. Vörr gives the source, environment and match quality for every fact.
Labelled uncertainty: Inferred cross-repository edges carry file:line evidence, HTTP and config edges also carry a confidence, and name, suggested or unmapped service matches are labelled as such. Neither product presents a guess as a fact.
No false zeros: Vörr separates a verified zero from scanned-empty, access denied, failed or not connected, and returns "no connector" when no tool can answer. CodeZero shows repositories that are still indexing or failed, so a missing result can be traced to its cause.
People approve change: Vörr changes nothing from the assistant. CodeZero's agent cannot approve its own plan, and Coffee Mode leaves commits, pushes and merges to you.

Setup checklist

Step	Product	Who
Complete organisation onboarding: company profile, workspaces, environments marked production or not	Vörr	Admin
Connect GitHub, GitLab or Bitbucket and map repositories and branches to workspaces and environments	Vörr	Admin
Connect cloud accounts with read-only credentials	Vörr	Admin
Connect observability, error-tracking and CI/CD tools	Vörr	Admin
Map important services in the service map	Vörr	Admin
Add the Vörr connector to Claude, ChatGPT or another MCP assistant and grant consent	Vörr	Each member, for themselves
Grant CodeZero seats	CodeZero	Admin
Link source control and choose repositories to index	CodeZero	Whoever sets up the organisation
Install the extension in VS Code 1.90.0 or newer, sign in with Frigga and select the organisation	CodeZero	Each member
Install and sign in to Claude Code, Codex, GitHub Copilot or Cursor	CodeZero	Each member, with their own agent account
Check the repositories you need show as indexed	CodeZero	Each member

Vörr answers from the organisation's connected sources, and workspaces label what comes back. Each Vörr authorisation belongs to the user who granted it, and removing the connector from the assistant changes nothing inside Vörr. CodeZero uses your agent's own subscription or API credentials and does not modify them.

What Claude Code and ChatGPT already do on their own

Neither product replaces your assistant or coding agent; they supply context and guardrails to it. On its own, Claude Code in a local checkout reads, searches and edits every repository you have cloned, runs git, tests, builds and gh, and uses cloud and cluster CLIs or vendor MCP servers for tools like GitHub, Sentry or Datadog if you install and credential each one. ChatGPT and Claude chat reason well over pasted logs, stacks and diffs, search the web and use whatever connectors you enable.

The gaps are specific. Only cloned repositories are visible, and HTTP, queue and environment-variable links between services are not references a search finds. Each tool needs its own setup and credentials on the laptop, service names differ between tools, and the agent has to stitch the results together itself. An empty result looks the same as an unconnected or unscanned source, and there is no deploy timeline across CI systems unless you query each one. Broad searches cost context and steps, so agents tend to stop early. Edit scope depends on each user's own agent settings, not on an agreed plan. Vörr closes the runtime and coverage gaps; CodeZero closes the visibility and approval gaps.

Where AI engineering gets stuck

Limits

Nothing moves between the products automatically. If a finding is not pasted into the other product, it does not get there.
Vörr answers only from tools you have connected, and name matching is only as good as the service map.
CodeZero indexes committed code on the default branch; other branches and uncommitted work are visible only in local checkouts. References are matched by name and callers are heuristic, not compiler-accurate.
Neither product deploys, rolls back or changes infrastructure. Those stay in your own tools and processes.