Digital Workforce OS
AIOS Client
Go-Live Checklist
12 checks before you ship a client AIOS install — so it doesn't become support chaos after handover.
AIOS Client
The Problem
The first install proves it works.
The second proves whether it scales.
The second proves whether it scales.
AIOS systems usually start clean. Then every client gets a slightly different offer, tone, CRM, calendar, data source, workflow, or human handoff rule. Without a deployment boundary, your reusable system quietly becomes custom support work.
Before launch: separate core from config. After launch: track what changed.
What the checklist catches
Issues that appear after go-live — before the client does.
Core logic mixed with client config
Skill files changed without version notes
No rollback path defined
Test data left in production
Broken permissions after go-live
Unclear human handoff rules
No monitoring owner assigned
Human corrections trapped in someone's head
Improvements stuck in one client install
Support issues with no clear source
The 12 Checks — Part 1
Before you ship
01
Core system defined
What stays the same across every client install — base logic, agent role, escalation, reporting.
02
Client config separated
Offer, tone, CRM, calendar, contacts, follow-up timing — isolated, not buried in core.
03
Skill / worker version saved
Which CLAUDE.md, skill file, or prompt pack is live? Audit for old assumptions and contradictions.
04
Hooks and background processes checked
What runs automatically at session start, prompt submit, or tool use? No hidden work.
05
MCP servers and plugins listed
For each: what it reads, writes, when it runs, whether it touches client data.
06
Clean baseline session run
Does the system work with minimal context, hooks off, no memory observer?
The 12 Checks — Part 2
Before and after go-live
07
Main workflows tested end-to-end
Lead capture, qualification, booking, follow-up, escalation, handoff — with realistic data.
08
Bad data and edge cases tested
Missing fields, wrong config, duplicated leads, broken links, unavailable slots, unclear intent.
09
Human review points defined
Where does the AI stop and ask? Unclear rules, high-value leads, medical/legal claims.
10
Rollback point created
Last-known-good branch, prompt version, config snapshot, current integrations saved.
11
Go-live changelog written
What changed, why, who approved it, what files were touched, what needs monitoring.
12
Post-launch learning loop exists
For 7–30 days: log failures, corrections, context issues, and what the system vs human handled.
Deployment Boundary
The real risk is losing the line between core and custom.
A good AIOS install has a reusable core and a safe client-specific config layer. When that boundary blurs, you're doing custom support work on every client.
Core System — Never edit per client
Base worker behavior and logic
Reusable workflows
Skill and prompt pack version
Escalation and handoff rules
Data and reporting structure
Install and rollback process
Client Config — Safe to change
Offer, services, and tone of voice
Locations, hours, and booking rules
CRM and calendar tools
WhatsApp, email, and contact setup
Follow-up timing and sequences
Client-specific edge cases
Customization is fine. Untracked customization becomes support load.
What's Next
Join AIOS Deployment Lab
A practical community for operators shipping AIOS installs across clients without every deployment becoming support chaos. Get examples, teardowns, and operator feedback.
Go-live checklists
Core vs client config
Deployment maps
Rollback and monitoring
Prompt / skill versioning
Support load reduction
Post-launch learning loops
What breaks after the first client