Build with a structured team of agents, not one — from inside the editor you already use.
Currently building
Assembly's whole premise is that a structured team of agents beats one agent working alone — but that claim is worthless without something to measure it against. The project just gained that control arm: a single "generalist engineer" role that does the entire job a product manager, an architect, an engineer, and a reviewer would otherwise split between them — clarify, design, implement, test, and review its own work, in one pass.
The interesting constraint wasn't building the role, it was keeping the comparison fair. The baseline has to get the same tools, the same repository access, and the same total budget as the team it's up against, or a result showing the team "winning" would really just be showing the baseline was handicapped. It turned out the four specialized roles' tools already add up to exactly what one generalist needs — no extra privilege had to be invented. Budget was trickier: the system enforces a hard per-invocation dollar ceiling on every role, so "same total budget" couldn't just mean summing four roles' numbers into one. The honest fix was to keep the dollar cap where every role has to live, and give the extra room where it actually matters for one agent replacing four — more tool calls, more time.
With that role in place, the next piece is the workflow that runs it end to end, and, separately, an open design call the project is waiting on the owner to make before the sequential engine can handle anything but the happy path.
Updated 2026-08-04 · pytest 346 passed · ruff clean · mypy strict clean · lint-imports clean
One coding agent is a fast pair of hands with no process around it. Assembly gives you the process: a product manager who writes down what "done" means, an architect who plans before anyone types, an engineer, and an independent reviewer who did not see the engineer's reasoning — moving a task from request to reviewed pull request through a workflow you can inspect and change.
The goal is to help people build faster, build better, and build more structured, using the tools and subscription they already have rather than another API key and another bill. Every run leaves behind typed artifacts, a lineage graph, and an event log, so you can see exactly what was decided and why.
Assembly is also its own first user: it is built by an autonomous agent running unattended once a day against a written operating contract. Nobody watches the run. It reads its own progress file, picks the next task, writes tests first, verifies green, commits, pushes, and rewrites its notes for the next run — which starts with no memory of this one.
A workflow is data, not code: which roles are enabled, what each consumes and produces, where the gates are, and what happens when one rejects. Change the shape of the team without touching the engine that runs it.
A role can be barred from seeing another role's reasoning, so a reviewer forms an independent judgement instead of agreeing with a rationale it just read. Independence is declared in the role definition and enforced when context is assembled.
The specification tree was written before the code and is the contract: module specs, interface definitions, milestones, and open questions. When a spec is ambiguous the agent files an open question rather than silently reinterpreting it.
Every type crossing a module boundary is defined in interfaces.md and nowhere else — now 82 Pydantic models across §1–§11, split one file per artifact family with tests mirroring the source tree 1:1.
Spec rules become structure when possible (an approval's scope is a single-member Literal, so blanket approval is unrepresentable), a model_validator when decidable from one instance, and documentation when they need external context the type doesn't carry.
JSON Schema is exported from the models into a committed file, and CI regenerates and diffs it on every push — a type change without a re-export fails the build.
Each cycle is capped at 10 changed files and 400 lines, ships with tests, and cites the requirement ID it implements. Ten small green commits is a good run; one large one is a violation regardless of how much budget was left.
Budget exhaustion is abrupt and can land mid-sentence, so every cycle ends with a checkpoint — green, commit, push, rewrite the progress file, push again. Worst case, one cycle's work is lost and the next run picks up cleanly.
A new role definition lets a single agent run requirements-through-review by itself, with the same tools, repository access, and per-call budget ceiling as any of the four specialized roles it stands in for — the fair baseline every multi-agent comparison needs to mean anything.
The specification has always said tool output must be treated as untrusted, the same as anything else that comes from outside the model. The data type recording a tool call's result just never carried that flag — now it does, and it can't be set to anything else.
When a step finishes normally, the engine now derives the run's lifecycle status from what the workflow itself declares, rather than needing to know any workflow's specific shape. Failures, denials, and escalations are deliberately left for a follow-up decision.
A workflow's steps now declare which lifecycle status a run reaches once each one finishes, so the engine that decides "what's next" can also answer "how do I describe where we are" without hardcoding any one workflow's shape into itself.
An automated check now fails the build if a lower-level module reaches upward into a higher one — the layering the design calls for is no longer just a diagram someone could quietly drift away from as more pieces get built.