Technical brief

Written for the engineers who get sent this link. No scroll journey, no reveals: every section is anchored, so a specific answer can be linked directly.

Last updated 2026-07-25

What it is, and what it isn't

Dandori is an orchestration, verification and coordination layer. It runs the agent CLIs your team already uses, in real sandboxes, against your repositories.

It is not a model: you bring your own. It is not an IDE. It is not a replacement for Claude Code, Codex or Cursor, and it does not try to out-write them.

If your engineers are already productive with those tools individually, Dandori is what makes them work as a team without paying the collision tax. If you have one engineer and one agent, you probably do not need it yet.

Who builds it

Dandori is built and maintained by a former Google engineer whose work was large-system architecture on products at Gmail scale, and later the early integration of AI models into developer tooling: the generation of work today's AI coding tools descend from.

Relevant here because it explains the shape of the product. The hard part of running agents as a team was never the model, which is why Dandori is infrastructure (environments, coordination, proof) rather than a prompting layer, and why it does not try to compete with the CLIs it runs.

Its first users are design partners rather than arm's-length customers: large production codebases from the same team. Treat their quotes on the home page accordingly, and ask for the live demo on your own code instead.

Built for agents, with dashboards on top

One design decision explains most of what follows. The tooling underneath Dandori is written to be driven by an agent, and the human interface is a view over it. The common alternative is to take tools built for humans and wrap them so an agent can operate them, which leaves the agent negotiating an interface designed for eyes and hands.

The practical consequence is what an agent can finish unattended. Where a wrapped human tool needs a person to click the thing it cannot reach, an agent-first tool exposes that step directly. It is why verification depth and release reports are possible at all, and why delegating is a decision you make once instead of a process you supervise.

Integrations

Everything below runs inside your VPN. Dandori holds no third-party keys on your behalf.

Task lifecycle

Every unit of work moves through the same path. The point of the path is that a pull request is the last step, not the first.

1. Intake. A request, a ticket or a plan lands in the backlog.
2. Spec. Dandori writes down what it is about to build and what "done" means, and puts that in front of a human when the work is not obvious.
3. Sandbox. A full environment is provisioned: editor, terminal, browser, CI.
4. Build. The agent works in that sandbox with your conventions and your existing components already in context.
5. Verify. The app is launched, the browser is driven on a real desktop, unit and end-to-end tests run, the linter runs and its findings are fixed. See verification depth.
6. Pull request. Opened only once the change has been used, not merely compiled.
7. Review. A human reviews a small, already-verified change.
8. Walkthrough. For complex work, Dandori demonstrates what it built, live, in your running application.

What stops and asks a human

• Deployments to any live environment.
• Breaking changes to a published interface or schema.
• Security-sensitive edits: authentication, permissions, secret handling.
• Anything that would expose a sandbox or its data publicly. See security.
• Work the agent could not verify end to end. It escalates rather than merging on a guess.

Verification depth

Most agent tooling verifies through a headless browser and a test runner. That covers a lot, and it stops precisely where the interesting failures live.

Each Dandori sandbox has a full desktop with real browsers, not a headless shell. The agent operates it the way a person would, which puts a class of work inside the loop that otherwise gets handed back to a human to check by hand.

What it can exercise

• Push notifications, including the permission prompt and the delivered notification itself.
• Video and audio playback, media players, and streaming behaviour under real codecs.
• File uploads and downloads through the actual OS file dialog.
• Runtime inspection: console and network errors, memory snapshots, and leak hunting across a session rather than a single page load.
• Multi-window and cross-origin flows, such as an OAuth handshake that leaves your app and comes back.

These are the features that normally produce the sentence "someone needs to click through this before we ship." Dandori clicks through it and reports what happened.

Across environments

The same depth applies from local development through staging. In production the agent is read-only: it observes, reproduces and diagnoses (logs, traces, memory snapshots, driving the app as a user would) but any mutation, deploy or write stops for human authorization under the same break-glass rule as everything else.

Coordination

This is the section behind the sawtooth week on the home page: why a team using solo agent tools ships for two days and untangles for three.

Each agent in a solo tool starts from zero context. Two engineers pointing two agents at the same codebase produce two independent interpretations of it, and the disagreement does not surface until merge time: as a conflict, as a duplicated component, or as a very large pull request nobody can hold in their head.

Shared components, not shared prompts

When an engineer designs something in Dandori, it lands as a component every other sandbox can see. A second agent about to build in that area gets a real decision instead of a blind guess:

• Use it. The design already exists and fits.
• Build compatible. The design will land first; build against its interface.
• Re-prioritize. This work should wait for the base work to land.

Dandori also tracks how the codebase is actually evolving, so an agent's sense of "how we do things here" comes from the current state of the project rather than from whatever it inferred in its first thousand tokens. Coordination stops being a meeting and becomes a property of the system.

Learning

Corrections are not thrown away. When an engineer corrects an agent, that correction is written into the project's knowledge and, where it generalizes, into the skill library every agent carries forward.

Two consequences worth checking in a demo. Agents stop re-asking questions your team has already answered, which is where a large part of the token cost of naive automation goes. And the knowledge is yours: it lives in your deployment, and it does not train anyone else's model. See security.

Quality and rework

The honest objection to agent volume is slop: code that exists, compiles, and is worthless. Three things keep it from compounding.

Verification gates

A change becomes a pull request only after the sandbox has run the application, exercised the change in a real browser, and run unit and end-to-end tests against it. A change that could not be verified is escalated, not merged.

Pull request size

Because work is scoped from a spec and built against existing components, pull requests stay small enough to review properly. The 4,000-line pull request is a symptom of an agent that had to invent its own context. It is not a fact of agentic development.

The rework index

Dandori measures its own rework and shows it on your dashboard:

• Rework rate. The share of delivered work that gets materially rewritten within a following window, rather than extended.
• Collision rate. How often two units of work touched the same surface in conflicting ways.
• First-time-right. The complement: work written once and not revisited.

Releases and reports

Dandori orchestrates releases, and the output is not a green checkmark. It exercises the new and the business-critical paths the way a human tester would, then sends a written report by email.

What the report contains

• What is in the release. The changes, mapped to the tasks they came from.
• What it found. Including what it could not get working.
• What needs fixing, and what that blocks.
• The risks, and whether it considers the release safe to proceed.
• Screenshots as evidence, attached whether the answer is yes or no. A passing claim with no artifact is the thing this exists to replace.

The backlog is updated before the email arrives, so the follow-up work is already captured and assigned when you read it.

The risk gate

Anything Dandori judges risky does not ship on its own authority. It stops and asks a human, and the authorization is recorded. A report that says "safe to proceed" is a recommendation, not an action already taken.

Cost model

Most teams do not under-automate because agents are bad. They under-automate because per-usage pricing makes the bill unpredictable exactly when productivity rises.

Bring your own keys

Dandori runs against the Claude and Codex subscriptions your team already holds. It does not resell tokens and does not sit between you and your provider's pricing. If your organization has negotiated rates, you keep them.

Dandori's own token usage

Dandori maintains a code-intelligence index over your repositories. This is the only token cost that belongs to Dandori itself, and it is built for incremental update rather than repeated full passes: on the order of cents to a few dollars per day, even on large multi-engineer projects.

How it keeps token spend down

Three things, none of which require you to think about them:

• Model routing. Work goes to the model that fits it. A mechanical edit does not need the model you would use for an architectural decision, and Dandori does not spend as though it did.
• Sub-agents. Work is split so each agent carries only the context its own task needs, instead of one conversation accumulating everything.
• Deterministic tools over inference. Where a tool answers a question better than a model can (browser automation, code intelligence, test runners), Dandori uses the tool. Reading an answer costs a fraction of reasoning toward one.

This compounds with learning: questions your team has already answered are not re-derived from scratch each session.

Fixed cost instead of metered infrastructure

Dandori CI runs at a flat monthly rate rather than billing per minute, and the same principle applies to the per-consumption services around your pipeline. As throughput rises, a metered stack's bill rises with it. A fixed-cost stack does not.

That difference is the whole point: Dandori is built to make high output something you can plan a budget around, not merely something that is technically possible.

Security and data

• Everything runs inside your VPN. Sandboxes have no path to the public internet by default.
• Publishing is break-glass. Exposing anything, whether a preview URL, a service or a dataset, requires explicit human authorization, and the approval is recorded.
• Your code does not train anyone's model. Dandori sends your source nowhere except to the model provider you already chose, under the terms you already hold with them.
• Secrets stay out of agent context. Credentials are materialized into the environment a process needs; they are not part of what an agent reads or writes.
• Everything is attributable. Which agent did what, in which sandbox, against which commit, and who approved anything that required approval.

Updates and versioning

A frontier model ships on a Tuesday. Your agents use it that day.

That works because the parts that move fastest update inside the running sandbox: the agent CLIs and the models they call. There is nothing for us to ship and nothing for you to schedule. Dandori's own platform image rolls on its own cadence, and it never interrupts work in progress: an update becomes available and is applied when an environment next starts, not by force.

Pinning and rollback

• Can we pin a version? Yes. An organization can hold a specific platform version instead of tracking the latest.
• Can we roll back? Yes. Platform versions are immutable images, so moving back is the same operation as moving forward.
• What if an upstream CLI ships a breaking change? The sandbox is the blast radius. A failing agent surfaces as work that did not verify, which escalates to a human instead of merging.

What onboarding needs

• Network. A VPN the sandboxes join, or let Dandori's deployment provide one. No public ingress is required.
• Repositories. GitHub access at the scope you would give a contractor: read, branch, open pull requests. Dandori does not need the ability to bypass your branch protection.
• Keys. The agent subscriptions or API credentials you already have.
• An environment it can run. Whatever it takes to start your app and its tests. If a new engineer can get the app running on their first day, so can Dandori.

That last item is the honest gate on time-to-value. A project no human can run from a clean checkout is a project Dandori has to learn to run first, and the verification story means nothing until it can.

Limits

Where Dandori does not help, stated plainly.

• It does not decide what to build. Priorities, product judgement and architectural intent stay yours. Dandori removes the cost of executing a decision, not the cost of making one.
• It cannot verify what has no observable surface. The desktop widens this considerably (see verification depth), but three things stay outside it: physical hardware it cannot drive, changes whose only real effect is on production data it is deliberately not allowed to mutate, and subjective judgement. It will show you the screenshot; deciding the design is right is still yours.
• It does not fix an unrunnable codebase. See onboarding.
• It is not a solo-developer tool. The value is coordination. One engineer with one agent should keep using Claude Code directly.
• It does not remove review. It makes review cheap by keeping changes small and pre-verified. Someone still reads the code.

FAQ

Shorter answers. The sections above are the long ones.