Deployment & CI/CD

Deploying an agent is not the same as deploying software. Software ships a binary. An agent ships a binary plus a personality, a set of operational boundaries, a security posture, and a web of inter-agent dependencies. Your CI/CD pipeline must validate all of these, not just the code.

The CC track teaches CI/CD fundamentals: GitHub Actions workflows, build-then-deploy patterns, pre-commit hooks that run type checks and tests before code reaches the repository. The OC track adds deployment patterns for always-on infrastructure: blue-green deployments where the new agent version runs alongside the old one until validation passes, canary releases where a fraction of traffic routes to the new version, and rollback procedures that restore the previous version in under 60 seconds.

1. Build the Validation Gate Your CI pipeline runs in this order: static verification (tsc --noEmit, lint), behavioral tests (vitest), contract tests (schema validation against defined protocols), security scan (check for hardcoded secrets, verify permission boundaries, validate network isolation config). If any gate fails, the deployment stops. No exceptions. No "we'll fix it in the next push." The gate is the gate.
2. Implement Blue-Green Agent Deployment Deploy the new agent version to a staging environment identical to production. Route a mirror of production traffic to staging. Compare outputs: does the new version produce results within acceptable variance of the old version? If yes, swap traffic. If no, investigate the variance before proceeding. The old version stays running until the new version has operated in production for your defined stability window — typically 24 to 48 hours.
3. Define Rollback Procedures Every deployment must have a rollback plan that executes in under 60 seconds. For CC-based agents: revert to the previous commit and re-run the deploy workflow. For OC-based agents: swap traffic back to the blue environment. For agent teams: roll back the lead first (it controls routing), then specialists in reverse dependency order. Document the rollback procedure. Practice it. The first time you execute a rollback should not be during an incident.