What is AI agency creation?

AI agency creation is a consulting engagement that installs an operating system for AI-assisted delivery inside your organisation. The team works from a ticket board. An engine behind the board routes work, runs expert packs, and files artefacts. You keep the workspace, the folder contract, and the pack library.

How does the workboard start the engine?

A person creates a ticket and moves it to the next column. That status change is the command. The engine assigns a grade, a pack, and a model class, then runs the pack. The delivery team does not open a separate chat console to start normal work.

Do we have to use Notion?

Notion is the default control surface. If the firm already runs ClickUp or Jira, those trackers can be the board. Use one tracker as the source of truth. Do not run two boards in parallel.

Where does the engine run?

You choose at the statement of work. Client-local means the engine runs on machines or a network you own. AWC-hosted means Wazowski Consulting runs a tenant and maintains it. The workboard looks the same in both cases.

Can tickets use local models as well as cloud models?

Yes. Each ticket carries a model class: frontier cloud, specialist cloud, or local. One gateway routes the pack. The board does not change when the backend model changes. Vendor names are agreed in the statement of work, not hardcoded on the page.

What does the firm keep after the sprint?

The workboard, the artefact tree, the git repository, the folder contract, the pack library, the grade taxonomy, and the cadence document. A later retainer is optional operations (hosting, pack updates, break-fix). It is not required to keep the system.

Is this a chatbot we deploy to staff?

No. A chatbot is not the system of record. Tickets, gates, and filed artefacts are. Chat comments on a card are the human thread. They do not replace the board.

Do you install an unsupervised multi-agent runtime?

The default install is the Wazowski Consulting operating method: intake, grade, pack, gate, named review. A parallel-engineering runtime (many workers, merge queue, capacity governor) can be designed as an option. Unsupervised merge to production is out of scope.

Service

AI Agency Creation

AI agency creation is the install of an operating system for AI-assisted delivery inside your firm. The team creates a ticket on a workboard and moves it across columns. That move starts the work, advances it, and files the result. Behind the board: an engine on your machines or on ours, cloud or local models, and a named human gate.

Provider: Wazowski Consulting (AWC), Andrew Wazowski. Planning code AWC-OS1. This page describes the offer. Price is set in a statement of work.

Discuss scope All services

What AI agency creation is

Most firms try AI as a chat window. Work then lives in transcripts. Nobody can say what ran, who accepted it, or what it cost. AI agency creation replaces that with a board, a file tree, and an engine.

You buy a working agency operating system under your brand or inside the existing firm. Intake, routing, expert packs, gates, and cadence. You keep the structure. Wazowski Consulting does not lock you to a vendor runtime.

This is not a fractional chief information security officer (CISO) or chief AI officer (CAIO) retainer. Those remain separate AWC services. This is not a governance, risk, and compliance (GRC) tool tenancy. This is not a chatbot wrapper.

Who this service is for

Founders, chief operating officers, and delivery leads who need more throughput than the named principal can type. Typical buyers already have a tracker (Notion, ClickUp, or Jira) and cannot scale by hiring another layer of managers.

The method fits regulated or evidence-heavy work (security, product, research) where a draft must pass a human before it leaves the firm. It does not fit a request for unsupervised production merge.

What the firm gets

Outcomes, not a feature list. The board is the button. Artefacts live in a tree people can browse. Models are swappable. The engine is reachable when a run breaks.

Principal time stays on judgement: Drafts, evidence collection, and routine packs do not sit on the named expert by default. The expert reviews on a published cadence.
Every commitment is a ticket: Meetings produce cards with acceptance, a due date, and a grade. Chat does not replace the board.
Work is graded before it starts: Full automation, draft-then-gate, human judgement, or human craft. No grade means the principal becomes the default labour. The method forbids that.
Packs, not one-off prompts: Each recurring artefact has a template, a checklist, an example, and a named gate.
Verification is in the path: Review, sources, and an accept step before anything reaches a client or a main branch.
Cost is visible: Model class and people time are tagged per ticket at Done. They are not buried in unpaid founder hours.
You keep the system: Workspace, folder contract, and pack library transfer. A later retainer is operations, not a lock-in.
Capacity has a governor: Concurrent runs are limited on purpose so quality and rate limits hold.

How the team uses the workboard

Default surface: Notion. A person creates a ticket. They move it column to column. Each move is a signal to the engine. Comments on the card are the human thread. Linked pages are the artefacts.

Workboard columns and what the engine does on each move
Column	What the person does	What the engine does
Inbox	Creates the ticket. One sentence is enough.	Opens the card. Flags missing acceptance or grade.
Ready	Confirms scope, or leaves the card for the orchestrator to complete.	Assigns grade, pack, model class, and owner. Checks work-in-progress limits.
In progress	Moves the card here to start processing.	Runs the pack. Writes progress on the card. Files draft artefacts.
Review	Named reviewer accepts, edits, or sends back.	Holds publish until the gate passes. No unsupervised merge.
Done	No further action required.	Freezes the artefact version. Tags cost. Closes the run.
Hold	Parks the card.	Stops workers. Keeps state.
Broken	Sees that work stopped. Ops is notified.	Opens an operator incident. Job logs stay off the user board.

How artefacts are structured

At install, AWC duplicates a workspace template. People see plain names: Workboard, How we work, Requests, Design notes, Library, Plan, Help. They do not see operator folders, prompts, or keys.

The file tree follows the Rational Unified Process (RUP): environment, business modelling, requirements, analysis and design, implementation, test, deployment, configuration, and project management. Architecture notes use the 4+1 views (Kruchten). Time is labelled Inception, Elaboration, Construction, Transition.

Git holds the files. The tracker Library is a projection of signed work. The engine writes both. People do not copy from chat into the Library.

Where the engine lives

The engine is the project that runs: repository, orchestrator, packs, connectors, model gateway, logs. It is not the daily user interface.

Client-local

The engine runs on premises, in your virtual private cloud, or on a machine you own. Your team uses the workboard. AWC maintains the engine through agreed access (jump host, VPN, or a seated session).

AWC-hosted

Wazowski Consulting runs a tenant. Your team stays on the workboard by default. AWC operators add packs, change states and workflows, and respond when a run is Broken. Buyer ops access is optional after handover.

Both modes present the same board and the same artefact tree. Hosting is a placement choice, not a different product.

How large language models are chosen

Every ticket has a model class. The engine sends the pack through one gateway. The workboard does not change when the backend model does.

Frontier cloud: client-facing finals, hard architecture, or legal-adjacent drafts that still pass a human gate.
Specialist cloud: mapping, long synthesis, and drafts where a hosted model is enough.
Local: sensitive corpora, cost control, offline work, and routing. Open-weight models on the engine host.

Local is not a lesser default. Routing and bulk extract often belong there. Judgement-grade finals often belong on frontier, with a human gate. Keys stay in a vault. They never enter the agent session or the wiki.

How the method works

Default method: the operating system Wazowski Consulting already uses on its own delivery. Public names only: orchestrator, workboard, expert packs, named principal.

Intake to a scope card: acceptance, artefacts, due date, automation grade.
Route the card: full automation, draft-then-gate, human judgement, or human craft.
Produce against a pack (prompt, template, checklist, example). No freeform prompt per client.
Gate: checklist, sources, named spot audit.
Batch review by the named principal on a published cadence, not continuous chat.
File into the buyer tracker and git. Tag cost.
Escalate only on exception (incident, board risk, architecture veto).

Quality rules on every install: no client-facing draft without a human in the loop; no control or legal narrative without a source or a “not legal advice” mark where required; no claim that exceeds live tooling.

Optional runtime for parallel engineering work

Some buyers want many coding or mixed workers in parallel, persistent work state across restarts, and a merge queue. That is a runtime option, not the default page claim.

In that design: a persistent coordinator holds workspace context; each repository is a managed project; workers keep identity while sessions stay short; work state lives in git-backed trees; batches move as one convoy; recipes have checkpoints; a merge queue verifies before integrate; blockers escalate by severity; concurrent workers are capped.

Grades, packs, and human gates still apply. Wazowski Consulting does not claim a named third-party orchestrator in production for clients on this page. We can design against that class of system when the statement of work says so.

Engagement

Shape: a fixed-scope sprint (elaboration plus the first construction slice), then an optional operate retainer. Commercial form: fixed statement of work or master services agreement plus statement of work. Duration and price are unpublished here. They are set per buyer.

In scope

Workboard (Notion, or ClickUp / Jira if that is home)
Artefact tree from a template
Engine: client-local or AWC-hosted
Operator access: packs, states, workflows, Broken response
Model gateway: frontier cloud through local
RUP folder contract on git and the tracker
Grade taxonomy and pack library (agreed set)
Orchestrator rules and work-in-progress limits

Out of scope

Staffing a human agency or forming a legal entity
Building the buyer product (sold as implementation)
CISO or CAIO opinion as the hero deliverable
GRC tool tenancy
Training learning-management system
Requiring the team to live in an IDE to get work done
Unrestricted model keys inside the agent
Unsupervised production merge

Who already runs this method

Wazowski Consulting runs this operating system on its own delivery: intake to a card, grade, pack, gate, named review, cost tag. The public site does not name internal agents. The install for a buyer is the same method, with their tracker as the control surface.

Frequently asked questions

What is AI agency creation?: AI agency creation is a consulting engagement that installs an operating system for AI-assisted delivery inside your organisation. The team works from a ticket board. An engine behind the board routes work, runs expert packs, and files artefacts. You keep the workspace, the folder contract, and the pack library.
How does the workboard start the engine?: A person creates a ticket and moves it to the next column. That status change is the command. The engine assigns a grade, a pack, and a model class, then runs the pack. The delivery team does not open a separate chat console to start normal work.
Do we have to use Notion?: Notion is the default control surface. If the firm already runs ClickUp or Jira, those trackers can be the board. Use one tracker as the source of truth. Do not run two boards in parallel.
Where does the engine run?: You choose at the statement of work. Client-local means the engine runs on machines or a network you own. AWC-hosted means Wazowski Consulting runs a tenant and maintains it. The workboard looks the same in both cases.
Can tickets use local models as well as cloud models?: Yes. Each ticket carries a model class: frontier cloud, specialist cloud, or local. One gateway routes the pack. The board does not change when the backend model changes. Vendor names are agreed in the statement of work, not hardcoded on the page.
What does the firm keep after the sprint?: The workboard, the artefact tree, the git repository, the folder contract, the pack library, the grade taxonomy, and the cadence document. A later retainer is optional operations (hosting, pack updates, break-fix). It is not required to keep the system.
Is this a chatbot we deploy to staff?: No. A chatbot is not the system of record. Tickets, gates, and filed artefacts are. Chat comments on a card are the human thread. They do not replace the board.
Do you install an unsupervised multi-agent runtime?: The default install is the Wazowski Consulting operating method: intake, grade, pack, gate, named review. A parallel-engineering runtime (many workers, merge queue, capacity governor) can be designed as an option. Unsupervised merge to production is out of scope.

Discuss scope

If the firm needs a board the team can move, a tree they can browse, and an engine AWC can repair when a run breaks, start with a scope conversation. Email contact@wazowski.consulting or use the contact page.

Contact Wazowski Consulting →