Class workflow

Take the pre-class read before anyone talks. Bank it where the room can see it and check it later, a show of hands or index cards, tallied on the board. Cold call two or three students to state their pick in one line, no justification yet. The point is to capture the room before discussion moves it, so the re-vote later means something.

Bell has one build line and has to commit it to one proposal. Option A is the dispute-handling feature for the call-center agent, wanted by his own floor, with a clean local payback. Option B is the compliance-checking agent for the product-launch pipeline, owned by no single department, with a return he cannot book to his own P&L.

Push students into the case's own evidence, not general AI opinion. The math is on the page and nothing hides in the arithmetic. What the case withholds is a criterion, not a number. Cold call the skeptics on both sides. If the room splits clean, let it sit, do not referee it.

Lay out what the case does not argue: Option B's engine, the part that reads a document and checks it against a set of rules, is the same capability underwriting, collections, and customer care each need. Only the rules change per division. The engine is the expensive part and it is already built, so redeploying it costs a fraction of the first build, while Option A's dispute agent redeploys nowhere. The numbers behind that, how small a fraction and across how many divisions, are yours to supply, and they are the reason to keep them off the page.

Re-run the same vote right away, same method as the open. Put the new count next to the old one so the room sees what moved. This is Lesson 1: reusability beats local ROI once the same need shows up in every division, and the reason those parallel needs went unseen is that nobody made the first build discoverable.

Do not stop at “so build B.” Ask the next question: now that Bell holds a reusable engine, does he point it at all forty backlogged requests at once? He has one team. Point back at the build queue, at the running cost that scales with volume, at the teams on the other end who have to absorb each rollout. The answer is Lesson 3: you scale deliberately, one project to five or ten before enterprise-wide, or you drown the teams, the infrastructure, and the budget. The reusable engine makes scaling possible, it does not make doing it all at once wise.

Point back at the two agents the room started with. The autonomous front-line agent is the fast path, taking the routine work end to end. The rep, with the assist agent, is the slow path for the exceptions. Option A was really a question about that boundary: whether to let the fast path swallow the provisional-credit decision, or keep the human gate on the money that moves. That is Lesson 2, orchestration, and it has been sitting in the case the whole time. You do not have to teach it fresh, just name it where it already sits.

Say them plainly, in the order the room reached them: reusability and discoverability, then deliberate scaling, then the orchestration that was under the whole thing. What ties them together is that a leader's job here is not one decision but three, which builds to fund, coordinated how, scaled how fast. Close on that so the handoff to the fireside does not need a bridge.

I am not planning her segment here, just marking the boundary.