What happened
DoorDash built an internal conversational support agent for engineers who use its machine-learning platform. The company says the agent can retrieve guidance, inspect live system state, run diagnostic tools and suggest next steps. One example involved a warning that a test model deployment would be scaled down for low traffic: the engineer needed a temporary exemption while its calling service was still being developed. The agent explained the cleanup policy but not the exemption procedure, which a platform engineer then supplied.
DoorDash's harness measures whether the agent fully resolves engineers' questions, rather than relying only on reactions or broad quality scores. For each eligible support case, it identifies material facts behind the eventual resolution and rates the agent's response as Full, Partial or Missed. The headline metric is the full resolution rate: the share of evaluated questions fully resolved. DoorDash notes other systems might instead optimize for verified task completion, diagnostic accuracy, successful handoff or time to resolution.
The harness classifies unresolved responses by the remedy they require: a knowledge gap, where durable information is missing from authoritative documentation; a capability gap, where the agent lacks a tool, data source or workflow; a utilization gap, where an existing capability was not used effectively; or a correctness gap, where documentation is stale, ambiguous or contradicted by the system. DoorDash says the classification is intended to avoid mismatched fixes, such as adding documentation for a failed live lookup or adding a tool when routing failed to select one.
The company describes separate completeness and correctness loops. Support cases can reveal missing facts, which are checked against existing documentation and authoritative evidence before updates are made to the owning document. The independent correctness loop starts from documentation claims and checks them against implementation or configuration evidence. The support agent uses a synchronized snapshot of designated upstream documentation rather than becoming a separate knowledge authority. In the cleanup example, the documentation was updated to explain adding a deployment to an exemption list, recording an owner and reason, and removing the exemption when real traffic starts.
Scheduled workflows handle benchmarking, knowledge maintenance, synchronization and replay. DoorDash says these run as cron-triggered playbooks on Flux, its cloud-based agent platform, combining versioned skills with deterministic scripts. Scripts select eligible inputs, validate structured outputs and evidence, bound retries and timeouts, detect duplicates and no-ops, and return labeled outcomes. Models perform bounded interpretation, such as classifying a gap; free-form prose does not control workflow state. After a change reaches the knowledge snapshot or deployed agent, the harness replays the original case. DoorDash reports that the harness increased full resolution rate by more than 200% in its first couple of months and caught around 100 knowledge-base corrections and patches.
What the archive adds
New Runtime's earlier coverage of DoorDash's real-time dispatch platform described separating orchestration from computation as workloads grow (October 22, 2026 note). A separate note covered DoorDash's reinforcement-learning system for adjusting dispatch objective weights (October 22, 2026 note). This is a new event: the company applies operational engineering to support-agent improvement, rather than dispatch optimization.
Trend signal
This case supports the shift toward harness architecture as a durable boundary for production agents: metrics, deterministic controls, replay, and team-owned rules govern how the system improves, rather than relying on a model choice or prompt alone. The pattern is tracked in Harness architecture outlives model choice.
Why now
DoorDash says its platform and the systems it supports keep changing, so the agent must be maintained alongside them. Its approach treats growing usage as a broader sample of question shapes, failures and human-confirmed resolutions, making ongoing evaluation and knowledge correction part of operating the agent rather than a one-time launch task.
Why it matters
An agent that answers internal engineering questions can create more work if its advice is incomplete, stale or unsupported. DoorDash's design makes that risk legible: measure resolution, identify the type of failure, route it to an appropriate remedy, and test whether the original case now succeeds. The distinction between completeness and correctness is especially useful. More documentation may close a missing-fact gap, but it cannot fix an incorrect claim; likewise, a new tool will not help if the agent fails to invoke one already available.
The broader operational lesson is to keep human expertise in the system without making every improvement a manual gate. DoorDash encodes recurring expert judgments into versioned workflows, deterministic validation and replayable artifacts, while preserving upstream documentation as the knowledge authority. Teams can adapt this pattern to their own support or internal agents, but should treat the reported uplift as company-specific until they establish a comparable baseline and evaluation method.
Limits and uncertainty
DoorDash reports a greater-than-200% increase in full resolution rate over the first couple of months, but does not state the starting rate, denominator, sample size or confidence interval in the announcement. It also does not break out the roughly 100 knowledge-base corrections by type or show how many came from the completeness loop versus independent correctness checks. The company does not provide a controlled comparison isolating the harness from other changes to the agent, documentation or platform. These are company-reported operational results, not independently audited measurements.
Skill to build now
Take a small set of recurring agent-support cases and label the facts needed for a successful resolution. Score each answer as full, partial or missed, then classify failures as knowledge, capability, utilization or correctness gaps. For each fix, preserve the original case as a replay test; update the authoritative document rather than an agent-only copy, and verify the behavior after the agent's knowledge snapshot changes.
Reader takeaway
DoorDash's central move is not simply to automate documentation edits. It connects a measurable support outcome to classified failures, carefully governed knowledge changes and replay of the original case. If you build an internal agent, make improvement a testable operational loop—and keep the source of truth and human judgment in that loop.