Autoloom: governance methods built into the coding agent runtime

The claim is judgment, not capability

The positioning is precise and it is not the usual one for a coding agent.

The subtitle is governance engineering for coding agents, and the readme says Autoloom brings the core governance methods of a separate project into the coding runtime: question whether a change is needed, challenge assumptions before editing, and review delivery against requirements and execution evidence.

The stated benefit is the part a user feels. Spend less time reminding your agent to investigate first, avoid unnecessary complexity, and show what it actually verified.

That last clause is the differentiator. Almost every coding agent can be told to investigate first, and most of them will do it once and then forget, because the instruction is a line in a prompt competing with every other line. Autoloom's claim is that the requirement is enforced at the point where it matters, in the runtime, so it does not need to be remembered or re-prompted.

The project describes itself as AI coding with engineering judgment built into execution, and the Chinese description makes the same point with the phrase about weaving ideas into reality.

The governance methods themselves come from Aegis, an open source AI engineering method pack in its own repository, which is an important piece of context. Autoloom is a runtime that applies methods defined elsewhere, so you can read the method pack without installing anything, and the two are versioned separately.

Four methods, and four points in the workflow

The readme presents the methods as a table, and the table has two columns, the method and its role in the development workflow. The pairing is the interesting part, because each method is tied to a moment rather than being a general principle.

The first is first principles and change necessity, which applies at task initiation. It examines goals, facts, existing capabilities and constraints to establish why a change is needed and whether an adequate solution already exists. So before the agent writes code, it has to establish that the task is worth doing at all, and that the codebase does not already solve it.

The second is anti-entropy and structural complexity checks, applied before changes. It examines duplicated responsibilities, unnecessary layers and maintenance burden, so that any complexity added addresses a concrete problem rather than existing because the agent found it convenient.

The third is counterexample review and causal diagnosis, which fires both before changes and after execution failures. Before, it examines conditions that could invalidate the solution. After a failure, it requires a diagnosis grounded in observations and evidence rather than a plausible guess about what went wrong.

The fourth is implementation conformance and completion review, applied before results are recorded. It compares task requirements, actual execution and verification material, and states what is complete and what remains unverified.

That last one is the method with the most practical value, because the alternative is a confident summary that blurs the line between what was checked and what was assumed. The readme is careful about the limit of all four: whether a method was applied well and a result is reliable still needs to be judged from the code, the execution results and the verification evidence.

A collapsed row before every mutation

The mechanism that makes the governance visible is a small piece of user interface, and it is described in one paragraph that is easy to skim past.

Before an admitted project mutation runs, the conversation can show a collapsed governance impact row describing how the relevant methods changed that concrete action. Its user-facing fields follow the request language, so the row appears in the language the user is writing in, and the complete recorded details remain inspectable.

Three things are happening in that sentence. The row is collapsed, so the governance is present without dominating the conversation, and a user who does not care can ignore it. It is scoped to a concrete action, so it says how the methods changed this particular edit rather than listing the methods in general. And the full record stays behind it, so nothing is lost, which is what makes the collapsed view safe rather than a summary that hides something.

The runtime side of the same idea is described as maintaining prerequisites for key actions, task state and execution evidence, and connecting governance to actual work in order to reduce repeated reminders and manual checks. The phrase guidance loads as needed appears alongside it, which is the practical detail: the method text is not always in the context, it is brought in when a decision point is reached.

For a team that reviews agent output, this is the part that matters. The record is not a chat transcript you have to reconstruct afterwards, it is a per-action record of what was checked before each change.

Project memory, diffs and thresholds you can set

The second half of the feature set is about what the agent remembers and what it is allowed to do.

Recorded project goals, constraints and key decisions stay with the project, and changes to those decisions present a specific diff for your review. So the goals and the constraints are not in a prompt you paste each time, they are attached to the project, and if the agent proposes to change a decision, you see the change rather than a summary of it.

You can also configure a test-first preference and code complexity thresholds to reflect the project's requirements. Those two settings are the concrete expression of the anti-entropy method, and they are the settings that decide whether the checks are advisory or binding in practice.

The difference between a threshold that is configured and a threshold that is mentioned in a prompt is the difference between a rule the runtime can check and a suggestion the model can weigh against the immediate task. That is the whole thesis of the project in one feature, and it is also the part worth evaluating first, because it is where a project either gets real value from the tool or gets ceremony.

The delivery review method also has a documentary dimension, since the project retains execution evidence. That is what lets the completion review compare the requirements against what actually ran, and it is why the readme can say the platform aims to keep the delivered results inspectable.

Built on DeepSeek Harness, with a stated upstream policy

The foundation is worth understanding because it defines what you are actually running.

Autoloom is built on DeepSeek's official open source DeepSeek Harness, at release dsh-v0.1.1-rc.2, pinned to a specific source commit, and it retains the Cordis plugin mechanism from that project. Cordis is the plugin system, so keeping it means the extension story is the upstream one rather than something reinvented.

The upstream policy is stated rather than implied. The project says it will continue following official upstream releases and learning from worthwhile improvements, and that changes which fit Autoloom and solve real problems will be adopted after adaptation and verification, with selected later reliability fixes already included.

Then comes the boundary, and it is an important one. The maintainers also say they keep their own product direction: bring engineering judgment into automated development, ground the process in evidence, make results inspectable and reduce the supervision burden. Autoloom has its own version numbers and its own release cadence.

So this is a fork in the practical sense, tracking upstream but not merging blindly. That has a cost, and the readme is honest about it in a way that is worth noting: the client retains the third party licences and copyright notices of the projects it builds on, and the project thanks DeepSeek Harness and Cordis.

The practical consequence for an evaluator is that the upstream version and the Autoloom version are two different numbers and you need to know both. A release note that says it is based on a given harness version tells you what the agent runtime is doing, and the Autoloom version tells you what the governance layer is doing.

The repository publishes the site, not the client

There is a detail in the repository that will save you time if you clone it expecting to build the desktop application.

The package manifest at the root is named for the public site, is marked private and has a version of zero. It is the website build, with a VitePress dependency and a Vue dependency, and its scripts are for the site: a dev script, a build script, a build from a fixture, and a verification script. The test script runs the Node test runner over the test files, and the check script runs the tests, then builds the site from a fixture, then verifies it.

That combination is a small lesson in how to make a documentation site trustworthy. Building from a fixture and then verifying the output means the site can be checked in continuous integration without needing a real release, and the verification step is a separate script rather than a comment in the build.

The rest of the tree is the documentation and the release metadata: a docs directory, a metadata directory, a website directory, a scripts directory, a tests directory, and a Chinese changelog alongside the English one, a data and privacy document in two languages, a security policy in two languages, a licence file, and a Chinese readme. There is also a pnpm workspace with a lock file.

The client itself is distributed as a download, with a badge for the latest release including betas, and the readme's links point at the releases page for the beta build, the website for the overview, the documentation and the issue tracker for feedback.

Beta status, one platform, and what to check

Three things to verify before you rely on this.

The first is the maturity. The release history is three beta builds in two days, v0.1.0-beta.4 on 2026-10-18, beta.5 and beta.6 on 2026-10-19, and the last push was on the same day. That is a project in active development where the version number tells you very little, and it means the interface and the method set will change.

The second is the platform. The release badge advertises Windows x64 only. A desktop client that is Windows-only is a real constraint for a team on macOS or Linux, and there is nothing in the readme about other platforms.

The third is the licence. The repository records a custom licence that GitHub cannot classify, and there is a licence file at the root, so read that file rather than assuming an open source licence, particularly since the client bundles third party code from DeepSeek Harness and Cordis whose own terms are retained.

Beyond those, the honest reading of the readme is that the ambition is stated in the same terms as the limits. The goal is to be a trustworthy, fully automated AI software development platform, where ideas progress through requirements, design, implementation, verification and continued iteration, with more of that work autonomous while key decisions, supporting evidence and delivered results stay inspectable. The readme also names the open question it is working on, the balance between cost, speed and quality, measured as the total cost of reliably delivering a requirement, counting model calls, waiting time, human supervision and rework caused by defects.

That framing is useful for an evaluation, because it tells you what to measure. If you try Autoloom, the number to watch is not how fast it produces code but how much of your supervision time it removes while leaving the evidence intact.

Editorial conclusion

Autoloom suits a team that has already tried prompt engineering and found that a coding agent still needs to be told to investigate before it changes things, because the governance here is wired into the runtime rather than left to the prompt. It is a poor fit if you want a fast general purpose assistant, since the checks add work, and a poor fit on anything but Windows x64, which is the only platform badge the readme advertises. Before you adopt it, read the Aegis method pack, since that is where the substance is and Autoloom is the runtime that applies it, and run it against a small task in a repository where you can check whether the evidence it records matches what actually happened.

Frequently asked questions

Official sources

1. GanyuanRan/Autoloom on GitHub
2. Issues
3. README
4. Releases