SuperAPI AI Directory
Partner with us中文AI newsFavorites
All toolsAI agentsdos-kernel

dos-kernel

DOS (Dispatch Operating System) is a Python tool for verifying the work results of AI agents. It does not take the agent's self-reported completion at face value, but instead cross-checks claims against "real-world witnesses" such as git history. Running dos verify PLAN PHASE gives a verdict based on commit records: if there is commit support, it returns SHIPPED (exit code 0); if no results have landed, it returns NOT_SHIPPED (exit code 1), thereby preventing false "completed" claims in CI or scheduling loops. It also provides commands such as commit-audit, liveness, and arbitrate, which can identify mutual write conflicts, idling, and false claims when multiple agents share a repository, and supports zero-configuration use or deep configuration via dos.toml.

Open website

About this tool

DOS (Dispatch Operating System) is a Python tool for managing clusters of AI agents, with the core goal of promptly detecting when agents misreport what they have delivered. It does not trust the agents' narratives, but instead reads "real-world" evidence that agents cannot forge—first and foremost git history, followed by the file tree, clocks, CI status, the test environment's own state, and so on.

[Purpose] When a coding agent reports results to you after completing work, the narrative is usually accurate, but occasionally there are cases of "all work is complete!" that are optimistic yet have no actual output. With a single agent, you can reread the output yourself to spot the lie, but when running twenty agents at once, such manual checking is not sustainable. DOS acts as a "referee," reading only what actually happened (commits, files, clocks) and giving verdicts that cannot be swayed by narratives.

[Main capabilities]

  • dos verify PLAN PHASE: answers from commit history whether a phase was truly delivered. Supported by commits → SHIPPED, exit code 0; no results landed → NOT_SHIPPED, exit code 1. The agent's own claims do not participate in the verdict at all.
  • dos commit-audit: audits commit by commit, sorting verdicts into CLEARED (the diff matches the claim, so repeated review can be skipped), RESIDUAL (claims that git cannot support, requiring 100% manual handling), and parts with no claim. Officially, in its own repository's most recent 200 commits, it cleared 170 of 171 verifiable claims. CLEARED only means the form of the change matches the claim; it does not mean the code is correct.
  • Cluster management: for multiple agents pointing at the same repository, identify who is stepping on each other, who is idling, and which "completion" is real.
  • dos arbitrate / lane leases: file tree sharding and admission control to prevent two agents from silently overwriting each other's files.
  • Verdict logs and export: dos export can export verdict logs to observability stacks (Datadog / Honeycomb / Grafana), dos notify pushes items requiring manual handling to Slack, dos reward controls training data available for fine-tuning, and dos attest generates signed receipts that third parties can verify.

[Usage] DOS is a Python package, installed into the existing git repository where the agents workMedium. There is no need to clone or replicate the DOS source code (unless you want to develop DOS itself). The only runtime dependency is PyYAML. Version v0.30.0, 5,600+ tests, CI covers Python 3.11–3.13 on Linux plus one Windows 3.13 smoke run, under the MIT license.

  • Initialization: dos init prints the configuration and hook entries it writes; deleting these generated entries undoes the setup. If no runtime is detected, it states this clearly and lists the available options, without guessing.
  • Zero configuration: run dos verify PLAN PHASE directly on an ordinary git repository, with no plan, registry, or dos.toml needed, answering solely from commit history.
  • Configuration: dos init writes dos.toml (lane, path, and release syntax as data); after adding plan documents, dos plan displays each phase's declarations side by side with the oracle's verdict.
  • Extension: you can declare custom blocking reasons, gate verdicts, output renderers, admission predicates, model judges, custom plan dialects, or a complete host driver, all as workspace policies, without forking.
  • Integration methods: CLI, MCP (agent self-check), hooks (host blocks undesirable actions), CI steps, or a scheduling loop. In CI, you can replace the line that trusts the agent's "completion" with dos verify PLAN PHASE, and branch on the exit code (0 delivered / 1 not delivered), without parsing output.
  • Demo: uvx --from dos-kernel dos quickstart runs the full demo temporarily, leaving no trace.

[Applicable scenarios]

  • Use exit codes in CI or a scheduling loop to gate an agent's "completion" claims.
  • Conflict and idling detection when multiple agents work in parallel in the same repository.
  • Review queue triage when commits pile up faster than humans can read them.
  • Scenarios that need to prove outcomes with real evidence rather than model confidence.

[Limitations]

  • The verdict scope is only "what happened"; it does not judge code quality, which remains the responsibility of tests and review.
  • The admission part (arbitrate, lane leases) is currently limited to a single local filesystem: the WAL is stored on one disk, and workers across machines have no shared serialization point. For cross-host clusters, dos arbitrate should be treated as advisoryoperations (not a hard mutual exclusion lock) until a remote lease driver is released.
  • The verification part (verify, commit-audit, liveness) reads git history, so it can be freely used across machines.
  • No official information is provided about fees, pricing, or specific platform support.
  • The arXiv preprint is still in preparation and does not yet have an arXiv ID.

Related tools

Browse category