WorkBot live, an architecture document, a recorded 10-minute demonstration and the numbers.
What you'll build today
Over 39 days you have taken WorkBot from a scaffold on Day 1 to a production AI product. It answers in a web chat and on messaging channels, reads documents and spreadsheets, and acts on other systems through integrations. When a model fails, a fallback model answers instead. Evals gate the changes that touch prompts, tools and models, traces record every model call, and Terraform and one pipeline deploy it, isolated for a customer that needs it.
Today you release it the way every release has gone. The merged commit goes through the pipeline into an isolated environment and passes every smoke gate there. Then you bring the architecture document up to the release, with each number and where it came from, and you record the product doing its work. You learn to treat a release as a routine, and to present a system with its evidence.
By the end of the day, WorkBot is live, documented, recorded and measured, and the course is complete.
By the end of the day you can
Release WorkBot: deployed, documented and measured
Show every capability the program trains running, with its evidence
Final Release
Features shipped today
WorkBot: Released with its architecture document, a recorded demonstration and its numbers
The last day is a release. Deploy the final version, write the architecture document, record the demonstration and collect the numbers.
Deliverables
WorkBot, deployed by the Day 35 pipeline into an isolated environment (Day 36), with the eval scoreboard (Day 25), tracing and runbooks live
An architecture document (3-5 pages): system diagram, agent design, data and integration layers, deployment, decisions and tradeoffs, what you would change
A recorded 10-minute demonstration. It shows a user on 2 channels, a document and a spreadsheet handled, and an integration acting on a real system. It also shows a provider failover, a security control holding, and a change shipped through the pipeline during the recording
The numbers: eval scores by provider, cost per conversation, p95 latency, deployment time from a clean account, and pull requests merged per hour in the Day 22 fleet run
Step by step
1
Release through the pipeline
The final release should be the least eventful one, because it runs the same way as every release before it. The only new thing is where it lands, which is the isolated namespace you built for a customer on Day 36.
Study first
Learn to see the release as a routine, not an event. It uses the same images, the same Terraform, and the same release script and gates as every release before it. DevOps Research and Assessment (DORA) explains why in its page on deployment automation. One process and one set of packages for every environment mean production runs a process already tested many times.
Build
1
Build the merged commit's two images, then create a clean cluster and apply the cluster's platform from Day 35, infra/kubernetes. Release into the isolated tenant's namespace from Day 36 with infra/release.sh.
2
Read the gate's result before you call it released. The gate is the eval smoke suite, the small set of scored tests from Day 25, which the release script runs.
Done when
Every smoke gate passes in the isolated environment, and its health check names the merged commit.
In the reference run's release into Harbor Dental's isolated namespace, the gates scored chat 0.96, extract 0.92, triage 0.88 and security 1.00, and health showed the merged commit.Technical notes
Run the smoke suite as the customer its eval sets were written for. The triage cases name the teams of Fieldstone Supply, the first customer, while Harbor Dental's teams are a front desk and billing. So in the reference run the first attempt failed its gate, because the suite rejected every answer as an invalid team. The release's smoke suite now runs as Fieldstone, with the release's other settings, and eval sets per customer are the next step.
A customer's configuration changes the bill as well as the answers. Harbor Dental's configuration puts chat on the large model first. In the reference run, the chat suite then cost $0.25 for 20 answers, against $0.013 on the small route.
2
The architecture document
A release is easier to trust when one document explains the system and backs every number with a source. The architecture document has grown since Day 20, so today it catches up with the deployment and operations work of the last weeks.
Study first
Learn what a reader of an architecture document needs: the system, the agents, the data, the deployment, the decisions with their costs, the numbers, and what would change. The arc42 template gives these parts standard names, from context and deployment to decisions and risks.
Read Michael Nygard's post on documenting architecture decisions. Each decision lists all its consequences, not only the good ones, which is what "decisions with their costs" means.
Build
1
Bring docs/architecture.md, which you started on Day 20, up to the release. Add deployment and operations from Days 34 to 39, the numbers with their sources, and what would change next.
Done when
Every number has a source in the repository, and every gap is named.
The table gives the reference run's numbers, as its architecture document states them. The agent fleet is Day 22's run of 50 backlog tasks by agents in parallel.
The demonstration shows the product doing real work, one scene at a time. A short recording cannot show everything, so for anything it leaves out you name where it is proven instead of staging it.
Study first
Read the World Wide Web Consortium's guidance on video-only recordings, which need text that describes what happens, in order. A screen recording without sound is video-only, and a caption per scene is that text.
Build
1
Record the product at work, with a caption per scene. In the reference run, the scenes were a policy question answered with its source, a prompt injection refused, and a scanned invoice read and filed. Then came a spreadsheet question answered in SQL, the eval scoreboard, and the jobs page.
2
Check the recording against the curriculum's list, and for each item it does not show, name where that item is proven. In the reference run, provider failover is the Day 36 game day, and a second channel is Day 32's signed webhooks. A change shipped through the pipeline is the release above.
Done when
Each scene shows one thing the product does, and nothing is staged.
In the reference run's recording, the assistant refuses a refund it may not approve, cites the policy, and offers to send it to the person who can.
The reference run's recording runs 72 seconds: demo.mp4.
