Narration is not work.
Explaining a plan does not satisfy a task that required an artifact, a test, or a real-world effect.
The Washu ProjectA BakaNeko story and research record
Inside Washu / Working System 07
Most agent systems ask a model to do the work and then take its word for it. Workshop was built because I got tired of opening a “finished” result and finding a narrated plan, a skipped hard part, or a model reviewing its own homework.
It hires a crew, gives each worker a bounded job, records what they actually do, and refuses to call the work complete until the evidence survives review.

THE WORKING PREMISE
The Workshop can use local Washu models or hosted model families such as Claude, Codex, Gemini, and Grok. That variety is useful, but the model roster is not the interesting part. The interesting part is deciding who may do what, who is qualified to review it, what proof is required, and where a person must still make the call.
A model can be brilliant and still be wrong about what it actually did. Workshop treats that as an operating condition, not an edge case.
01 / BUILD THE CREW
A project can run as a Lone Wolf with one model family, a smaller pairing, or a mixed team drawn from several families. The assignment board matches roles to capability tiers, model variants, effort levels, subscriptions, and the live bench.
Workers are then generated for the combination actually needed. Their names persist. So do their roles, boundaries, trust, and history.



02 / GIVE ROLES TEETH
Advisor, architect, implementer, researcher, QA, reviewer, technical writer, visual reviewer, publisher. Each role carries a real operating contract. It can define what the worker may read, what it may change, what it must inspect, and what it is forbidden to approve.
Every worker inherits the role’s common instruction, then gets an identity and any individual refinements the job needs. That gives the shop consistency without turning every worker into the same voice wearing a different label.




03 / REQUIRE PROOF
The production line is intentionally fussy. Research has to produce sources. A specification has to describe the build and its file structure. Implementation happens in isolation. Browsers, screenshots, console output, QA, independent acceptance, documentation, and publication each have their own station.
If a worker only explains what it would do, Workshop has a simple answer: that is narration, not work.
Sources, URLs, claims, and open questions.
A blueprint plus a machine-readable manifest.
Visual material checked before it reaches the build.
Work occurs in an isolated project tree.
Browser, screenshots, console, layout, and motion.
Behavior tested against what the specification required.
A reviewer who did not build it renders the verdict.
What shipped and what remains wrong stay visible.
Only accepted work is promoted into the granted path.
Explaining a plan does not satisfy a task that required an artifact, a test, or a real-world effect.
The reviewer cannot be the author or simply the same underlying model wearing another name.
A project may finish with known defects, but those defects remain first-class and named.
Repeated failure escalates to a different perspective and an upstream question instead of another identical attempt.
04 / KEEP AUTHORITY
Workshop can run in guided mode or carry a project farther on its own. Either way, actions pass through bounded permission envelopes, live leases, budgets, and a hash-chained record of decisions, refusals, borrowing, approvals, and publication.
That is the difference between an agent having access and an agent having authority. Access says a tool exists. Authority says this worker may use this capability, for this job, inside this boundary, before this permission expires.
“The interesting question is not how many agents I can put on a screen. It is where authority sits when one of them says the work is done.”

Stated plainly
Workshop can catch missing files, bad behavior, unsupported claims, visual defects, collapsed builds, and reviewers grading their own homework. It cannot guarantee that a team will converge or that the result will be beautiful. Local models have ceilings. Hosted models have different ceilings. Some failures still require Paul.
The promise is narrower and, I think, more useful: the evidence stays attached to the work, defects do not quietly dress themselves up as success, and a human can see how the decision was reached.
If curiosity wins
The current page is meant to make the Workshop understandable without requiring anyone to read a platform specification first. If there is enough interest, I will keep opening it up with project walkthroughs, governance details, architecture notes, failure cases, and video from a real build moving across the shop floor.
For now, it shows the part that matters most: how I am trying to make multi-model AI work more like a responsible production organization and less like a very confident group chat.