JOB IN.
CREW OUT.
Don't build an agent. Give the factory a job. Watch it hire, equip, and retire a crew.
FOLLOW THE WORK ORDER DOWN THE LINE
ANY DOOR.
ONE FACTORY.
A request arrives from somewhere people already work. No new agent to design. Just a job to get done.
A customer was charged twice. Refund the extra $240.
The same work order can enter from any door. The factory's rules don't change.
THE JOB
PICKS ITS ROUTE.
The factory reads what the job needs. Investigate? Get a human decision? Change something? Verify it? Different job, different recipe.
The factory never adds an approval step just for decoration. Low-risk research takes a shorter route.
HIRE FOR
ONE SHIFT.
The factory assembles temporary AI workers for this job. Each gets approved facts, reviewed memories, tools, and access limits. Not a permanent AI employee.
Built for this exact work order. No extra roles.
Notice: A human approver is not assembled here. They stay a person, at their own checkpoint on the line.
Knowledge = approved sources. Memory = reviewed lessons. Tools = equipment. Access = what each worker is actually allowed to do.
CLOCK IN.
DO THE JOB.
The workers follow the route. Some investigate together. A human makes decisions that belong to a human. Each tool checks what a worker may do before anything changes.
What if a worker skips the human decision or uses a tool it shouldn't?
The attempted action is denied and recorded.
The factory enforces the rules. The worker doesn't get to decide which rules are optional.
DON'T ASK
THE WORKER.
Ask for proof. A separate checker looks at sources, approvals, and what actually changed. "I did it" is not evidence.
A denied shortcut belongs on the receipt too. Failed and blocked attempts are part of the evidence.
NEXT SHIFT.
SMARTER START.
The crew disappears. The useful lesson doesn't have to. First, someone checks it. Then the factory gives the next crew a better briefing.
The first crew had to find both transaction IDs to explain the duplicate charge.
One lesson is supported by evidence. One is just a guess. Tap either card to test the sorting machine.
New temporary workers start with a reviewed lesson in their memory kit.
Learning can improve the next execution. It never quietly changes permission or gives a worker more authority.
THE CREW LEAVES.
THE FACTORY LEARNS.
That is the operating model. Describe the job. Assemble a bounded crew. Check the work. Carry the right lessons forward.
THE FACTORY BLUEPRINT
For the people who want to know what the machinery really needs. Tap a topic. No technical knowledge needed for the story above.
01. The work order is the specification
The factory receives an outcome, source, requester, target scope, constraints and allowed business effects. It determines work type and risk before deciding who participates. A crew is an output of planning, not a roster of permanently deployed agents.
Some jobs need parallel investigations; some need multiple independent checks. A read-only research task doesn't need a payment tool or a Finance approval window.
02. How the factory picks the crew
A typed work plan selects phases and roles based on the job's shape, policies, available tools, risk and evidence requirements. Workers are created with identities bound to the admitted work, tenant, scope, attempt and allowed actions. A specialist doesn't receive generic access to the organization.
Different routes may use parallel workers, sequential steps, human checkpoints or independent inspectors. The roles need not share one fixed template.
03. Knowledge is not memory
Knowledge is source material with ownership, versions, provenance and permissions. Memory is a previously observed lesson or preference with its own source, scope and verification status. Neither becomes universally trusted because an agent says so.
Context assembly draws on only the relevant, permitted items. Retrieval can help a worker find material; it does not grant access to material owned by another team. Lessons that fail review stay out of the next shift.
04. Company rules become enforceable rules
Company-wide and team-level policies must be codified and versioned, not buried solely in prompts or operating procedure documents. Some guidance is advisory; effect-bearing rules are checked deterministically at the action boundary.
For example, a refund policy can state the approving role, exact amount ceiling, scope and required evidence. A child scope may tighten that rule but cannot override the parent's denial. Updating a parent rule invalidates stale permissions or approvals for future actions.
05. Access is checked when the tool runs
Read permission is not payment permission. A worker may know a refund amount but still be unable to execute one. At every effectful action, the runtime should check tenant and scope, tool identity and version, action type, target, parameters, budget, approvals and current policy.
Credentials stay behind a broker or controlled tool boundary rather than being freely handed to the worker. A change of app, CLI or user interface must not bypass that enforcement point.
06. Humans don't get assembled as agents
A human approval checkpoint is an actual named responsibility. Approval is bound to the precise proposed action: who approves, what tool and target, the arguments and amount, the allowed scope and the current policy version. Changing the action or policy can require a fresh approval.
Low-risk work may be permitted to complete without that checkpoint. Higher-impact work can stop and wait. A simulation of a signature is not a real approval.
07. Inspection asks for evidence
The worker who writes or acts should not be its own final judge. Independent checks compare observed system state, acceptance criteria and durable artifacts. Logs alone do not establish that a business outcome is correct.
Receipts can reference source versions, parameter-bound approvals, action results, before/after states and denied attempts. The IDs shown in this film are illustrative, not actual transactions.
08. Learning improves future shifts, not authority
Work may surface a useful discovery. Before it becomes reusable memory or published knowledge, qualified verification, source lineage, classification, scope and owner review matter. The factory can then give the next crew a better starting context.
That promotion does not expand a worker's permissions, grant new tools or weaken policy. Bad material may already have propagated to caches or downstream systems, so containment and reconciliation must be designed rather than assumed to be instant.
09. What must exist underneath
To operate this model in a real enterprise, you need work intake and planning; identity and scope registry; policy authoring and deterministic evaluation; a tools catalog and credential boundary; knowledge and memory stores with provenance; context assembly; human approval services; execution coordination and retries; budget and effect admission; independent evaluation; audit and evidence retention; and operational monitoring.
The user-facing door can be Microsoft 365, Atlassian, a coding agent or a custom application. The common governed runtime is what makes those doors consistent.
10. What's built versus what's an experiment
Wicked Studio / Wicked Crew demonstrate important coding-workflow capabilities: intent-driven execution, scoped steering, phase gates, independent checking, agent-harness integration and evidence. Wicked AI Platform is a separate experiment, built on the side, that explores the wider enterprise picture: cross-domain authority, enterprise work scopes, policy and action admission, governed knowledge and organization-wide integration. It is an experiment, not a product.
This page is a design illustration, not a demonstration of a fully deployed end-to-end enterprise runtime. The work receipts and transactions are simulated. The distinction matters.