Cowork Forge

The deciding trait is that it wants the whole job. You hand it an idea and four role agents take it from requirements through architecture and task breakdown to written code, which is genuinely useful when the alternative is a blank directory and a Friday afternoon. As a way to see the shape of a thing before you commit to building it, this earns an evening.

Point it at a codebase people depend on and the same ambition becomes the problem. Pick it for drafts. Pick something you approve step by step for work that ships.

The architectural problem is a closed circuit. A specification written by the same machinery that implements it cannot catch a misread requirement, because the misreading happens upstream of both, and a chain of four handoffs means an early error is elaborated three more times before anyone sees it. Nothing in the description bounds how long that chain runs or what it costs.

What it does right is name its roles. Four documented stages beat one opaque prompt, because a reader can at least tell which stage produced the paragraph that is wrong.

1. Borrowing an established formulation is defensible, and separating generation from criticism does measurably reduce certain error classes. 2. The description stops before the part that matters, which is what the critic is scoring against and whether its judgement is calibrated on anything outside the prompt that produced it.

2. Human validation at decision points is the only external signal in the design, and its placement is stated without saying which decisions qualify. No evaluation is published for a system whose entire claim is end-to-end delivery, which is where a number would have been worth most.

This is an orchestration shim over other people's agents, which is the weakest position in the stack. The vendors it drives are already building their own multi-step planning, so the gap it fills is one they have staffed teams to close, and under a hundred stars is not enough adoption to make anyone want to buy the shim instead of shipping it.

Moat: none. Likely path: obsoleted by an upstream release, or maintained quietly as a personal experiment. Position: read it for the idea, do not build a delivery process on it.

My problem is governance, not licensing. A system that produces requirements and architecture documents is producing artefacts my organisation will treat as decisions, and there is no record of who reviewed them, no versioning I can point at and no export for the change advisory process that will eventually ask.

Windows is unsupported, which removes part of my estate, and nothing runs unattended, so it never becomes a measurable pipeline step. Onboarding is a README with no install command in it. Not yet, and not close.

Reusing the agents I already have is the right call. Nothing here reimplements a tool loop badly when three good ones are already installed, and the permissive licence means the orchestration layer is mine to rewrite when I disagree with how a role is prompted, which I will.

What I cannot do is plug anything in. Without protocol support, every capability has to be added by editing the project itself, so the extension story is a pull request rather than a config file. For a Rust codebase this small that is survivable, barely.