Spec an agent for a workflow I describe, including its limits.

Interviewer's question: "Spec an agent for a workflow I describe, including its limits." Since no workflow was named, here is the one I'll spec: an agent called CoverList that finds and confirms a substitute teacher the moment a teacher calls in sick, for Quarry Hollow Schools. Corwin Blackfriar is the district's staffing coordinator. Elowen Trask is a substitute teacher.

How to answer this, stage by stage

Nobody is grading whether the workflow you pick is clever. They're grading whether the limits you name are the ones that actually matter.

Let's learn

CoverList finds and confirms a substitute teacher automatically when a teacher calls in sick, instead of a coordinator dialing down a paper list by hand.

Before CoverList, Corwin Blackfriar manually called about four people per absence, twenty five to forty minutes each, and some mornings juggled six absences at once across the district's eleven schools, before doing anything else that day.

Four things happening at once, before six in the morning, before a single class has started.

With CoverList spec'd, an ordinary absence gets a certified, cleared sub confirmed by text in about ninety seconds, with a one-tap yes.

Here's the turn: the danger was never that CoverList might be slow to find someone. It's that "finding someone" and "finding the right person for a protected classroom" look identical to a matching algorithm, and are not remotely the same risk.

At its worst: an uncertified sub ends up alone with a self-contained special-education classroom because they were "available" and vaguely qualified-adjacent, a real safety and legal exposure for the district, not just a scheduling embarrassment.

What I would leave alone: ordinary elementary and general secondary coverage, the bulk of daily absences, is exactly where automatic matching is safe and valuable. Slowing that down with extra review would just rebuild the morning Corwin is trying to get back.

The lesson: the limits of an agent aren't the boring part of the spec written last. They're the part that decides whether it's safe to ship at all.

Now here is the same thing as a story

The short version above is what you'd say defending this spec to the district's superintendent. Read this one for how the limit actually got locked in.

Corwin Blackfriar has staffed substitute coverage for Quarry Hollow Schools for nine years, and he can tell within a sentence whether a sub on the list is right for a rowdy sixth-grade room or a quiet library shift.

CoverList started as a two-week shadow pilot: it would propose a match, but Corwin still had to approve every single one before it went out, so nothing happened automatically yet.

Two of the three branches route to Corwin on purpose, even before a single mistake ever happened.

There was no single dramatic failure. It was slower than that, the kind of thing you only notice by reading every log entry, which is exactly what the shadow pilot forced Corwin to do.

In the second week, a regular teacher in a self-contained special-education classroom called in sick. Elowen Trask, a general-education permanent sub who had substituted in that same school building for two years, showed up in CoverList's list of available, certified subs. She was available. She was certified, generally. She had simply never worked in that specific self-contained classroom, and didn't hold the additional clearance it required.

The third step only existed because the pilot was still shadowing every match, not sending any of them automatically.

Because the pilot required Corwin's approval on every single match, he caught it before anything went out: "She's great, but she's never been cleared for that room specifically." He rerouted it to a sub who was actually cleared, and nobody outside his own review ever knew there'd been a near miss at all.

Before that week, the working plan had been to let the matching model get smarter over time and trust it to learn which placements needed extra care, the same way a human coordinator eventually would. Corwin's catch made it clear that "eventually" wasn't good enough for a room where the stakes were a child's safety, not a scheduling inconvenience.

The decision the team locked in that week: hard-code the exclusion rather than wait for the model to earn it. Special-education and self-contained classrooms never auto-confirm, full stop, no matter how available or generally qualified a sub looks. Clearance gets checked fresh every morning, not pulled from a cached record from the week before.

Replayed with the anchor rule in place from day one of a full launch: the same near-miss match never reaches auto-confirm at all. It routes straight to Corwin the instant the system sees "self-contained classroom," the same way it did in the shadow pilot, except now it's a rule, not a lucky side effect of Corwin reviewing everything by hand.

I believed, going into the pilot, that the matching model just needed enough good examples to eventually learn which placements were sensitive. It took one two-year veteran sub, correctly matched on every dimension except the one that actually mattered, to see that some limits can't be learned. They have to be built in before the first real morning.

SPARK, in one screenNot a feature list for a scheduling app. SPARK is what tells you which one decision the whole design has to survive.

Two things deliberately left out, and a reason for each, not just a shorter feature list.

Week two is the only week that decided whether week four was allowed to happen at all.

The recap, one line per letter: situation is Corwin's 5:45am paper-list calls, payoff is he stops dialing for ordinary coverage, anchor is the hard exclusion on protected classrooms and fresh clearance checks, risk is a stale clearance or a missed decline, and keep out is special pay and multi-school scheduling staying manual.

And if you want to be sure it really works, try it somewhere elseSame five letters, an in-home aide visit scheduler instead of a school district. A different protected case, the same shape of anchor.

Marchbanks Home Health runs an agent that schedules in-home aide visits and can rebook an aide automatically when one calls in sick, matching a replacement to a client's care plan.

Mapped onto SPARK: situation is a scheduling coordinator currently calling down a list of on-call aides by phone, similar to Corwin's mornings but for home visits instead of classrooms. Payoff is the coordinator stops manually calling for routine, established clients and only steps in for the harder cases. Anchor: auto-confirm a replacement aide only for a client the aide has already visited before, with matching care needs; never auto-confirm a first-time visit to a new client, no matter how qualified the aide looks on paper. Risk: an aide who looks fully qualified but has never met a client with a specific medical need, like a feeding tube or a mobility transfer technique, could miss something a familiar aide would catch automatically. Keep out: multi-client same-day route optimization stays manual on day one, since an automated reshuffle across several elderly clients' schedules is exactly the kind of chain reaction too easy to get subtly wrong.

Swap the trigger and it still runs.
Speed: an interviewer caps you at thirty seconds. Say "auto-confirm ordinary coverage with fresh clearance checks, hard-exclude protected classrooms, always," and stop.
Cost: if checking clearance fresh every morning is too expensive computationally at scale, cache it for general classrooms only, never for the excluded ones, since that's where the cost of being wrong is highest.
The model gets better, for real: even if CoverList's matching accuracy climbs close to perfect, the hard exclusion on protected classrooms shouldn't loosen, because the cost of the rare miss there was never about the model's average accuracy in the first place.

Where people run it wrong.
They treat limits as something to add after the core feature works, instead of the thing that decides whether the core feature is safe to ship.
They trust a matching model to eventually learn which cases are sensitive, instead of hard-coding the exclusion from day one.
They cache a credential check for speed, not realizing the one time it matters most is exactly when it's gone stale overnight.

How to use it live. When someone asks you to spec an agent and name its limits, ask yourself one thing out loud: which single wrong match here would be genuinely dangerous, not just annoying, and does the spec hard-exclude that case rather than just hoping the model gets it right.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0