Build
What breaks in week two
Tobiloba Odejinmi · 10 Mar 2026 · 6 min · 1,057 words
Direct answer
Week two is when the cases you did not map arrive, people start working around the employee, and permissions or rate limits that survived the test set fail under a normal week. Nothing about that means the build was a mistake. It means production is the rest of the test set. You fix the map, the gates, and the connections. You do not declare the model dead.
- Unmapped cases are a map problem first.
- Workarounds mean the brief or the write-back is wrong.
- Permissions and limits often fail only at real volume.
- Week two is why the $7,500 week includes 30 days of support.
What usually breaks in week two?
The third shape of the document. The customer who writes in a language you did not sample. The candidate who applied through a side door. The lead with three emails and no ID. The ticket that is actually two requests. You can map well and still miss these. Volume finds them. That is why I do not treat day 7 as the end of testing. I treat it as the start of monitored traffic.
The other cluster is mechanical. A token that expires. A rate limit you never hit on thirty cases. A field the vendor added. A workflow rule in the help desk that fires only on Tuesdays. These are not glamorous. They take work off people only after you fix them. Ignoring them is how a good week becomes a story about how AI does not work here.
Why do edge cases show up after launch?
Because the test set is a sample, and people change behaviour when a new actor is in the queue. They send work they used to sit on. They try to sneak an exception through. They paste a novel into the ticket. The employee is now part of the system, so the system moves.
This is not betrayal. It is information. Write the new case onto the map. Decide if it is in-scope, a hard gate, or a different process. If it is a different process, do not cram it into the first employee. That cram is how a $5,000 workflow becomes an unpaid second week.
How do people work around a new AI employee?
They move the real conversation to email. They mark everything urgent so it skips the employee. They reopen tickets and do the job by hand without recording why. They ask the employee the same thing three times and then complain it is inconsistent. Watch for those patterns. They are usually a bad brief, a slow human queue, or a trigger that is too wide.
The fix is not a stern note about adoption. The fix is making the official path faster than the workaround. Working state plus a decision brief has to be easier than reconstructing the case. If it is not, people are being rational. I will change the payload before I give a pep talk.
What permissions and rate limits fail later?
Read access that worked for tickets but not for the related customer object. Write access that works for notes but not for tags. Calendar scopes that can read and cannot book. Export jobs that run daily and then get turned off because someone thought the employee replaced them. Rate limits on search that only appear when Monday is busy.
I put the service identity and the scopes in the handover for this reason. When week two breaks, you should not be hunting through a personal account. If the only working key is still on my machine, we did not finish days 4 to 6. That is on me to close, not on you to heroically debug.
How do you fix week-two problems without a rebuild?
Change the map, add a gate, tighten the trigger, or fix the connection. Rerun the test set. Ship the change. Most week-two work is that loop. A rebuild is for when the job was wrong: you automated a meeting, or you needed a new source of truth. Be slow to call it a rebuild. Be fast to call it a missing branch.
Keep the reentry path honest while you fix things. If you pause a path, say so in the queue. People can handle a pause. They cannot handle an employee that looks live and drops cases on the floor. I have been in rooms where downtime was treated as a slide. Then a clinic called. Same lesson. Status has to match reality.
When is week two a sign you picked the wrong process?
When the doer and the sponsor still argue about the correct exit on ordinary items. When more than a third of cases need a person and the briefs are not even the problem. When the tools cannot write back and everyone is copying from a dashboard. When nobody will own the human queue. Those are pick failures. The kind week you should have stopped on day 1 or day 3.
If that is where you are, stop the employee and keep the map. The map still has value. The $7,500 is not a sunk-cost reason to keep a bad slice live. I will say that on the support calls. I would rather you spend the next $15,000 on several workflows that are real than defend a first process that was a performance.
Questions people ask
Is week two always rough?
If you tested on a fair sample and watched the queue, it is busy, not chaotic. If you shipped a happy path, it is chaotic. The difference is the test set, not luck.
Should we turn it off when something breaks?
Pause a path if a gate is failing open. Do not turn off the whole employee because one new product line appeared. Narrow the trigger.
Who should be in the week-two huddle?
The doer, the queue owner, and whoever can change access. Same people as day 1. If they vanished after the handover call, that is the first break.
What if escalation jumps above 15 percent?
Look at whether the incoming work changed or a lookup died. A jump is information. It is not automatically a failed launch.
When is week two a sign you picked the wrong process?
When every item needs a meeting, or when two owners still disagree on the correct exit. That was a day-1 problem. Be honest and stop.
Written by
Tobiloba Odejinmi
Head of Engineering at 10mg Health. I have run engineering at Zeeh Africa and sold Insurpass and Shopl. I still write the code. If you have one process that still runs on people copying things, we can look at it in thirty minutes.
