Designing the Handoff Between Quadrants

A customer asks Sarah's chat widget a question it can't answer live. The widget escalates it. Overnight, a research agent looks into it and drafts a reply. By morning, that reply has to get back to the same customer through the same chat thread, and somewhere in that handoff a structured form (a ticket ID, an account tier, a queue status) has to become something a research agent can act on, and then the research agent's freeform output has to become something the chat widget can hand back to a person without sounding like a different system took over mid-conversation. Nobody designed that translation on purpose, and it breaks anyway.

Lesson 05 left Sarah with four layers, each correctly placed, each individually sound: Layer A is a clean CALM flow, Layer C is a properly-scoped research loop. It would be easy to conclude the hard part is over: four good decisions, four good quadrants, done. It isn't over, and the gap between "four good layers" and "one good system" is this lesson's entire subject.

Layer A escalates a ticket it can't resolve. Layer C picks up that escalation, researches overnight, and writes a reply that has to get back to the customer through Layer A the next morning. Layer B's nightly extraction feeds the priority ranking Layer C works from. None of these layers exist in isolation. They hand work to each other constantly, and each quadrant carries different assumptions about where state lives, how fast a response has to come back, and who is trusted to act without a human checking first. A handoff is the place those assumptions meet, and if nobody designs that meeting point on purpose, production designs it badly, on its own schedule.

Why a good Layer A and a good Layer C don't add up to a good system

Here's the misconception this lesson exists to correct: once each layer is individually well-built, people assume the hybrid is solid. It isn't, because the layers don't speak the same language. CALM's state lives in typed slots (issue_category, urgency, customer_id), validated, queryable, predictable. A Claw-style agent's state is a freeform context blob it accumulates as it reasons. Nothing converts one into the other automatically. Somebody has to serialize the slot state into a task a research agent can act on, and somebody has to deserialize whatever comes back into something Layer A can hand to a customer without alarming them.

Where state actually lives, per quadrant

The state question is really four questions, one per quadrant, and they don't share an answer:

The state model is the most consequential decision underneath any of these layers: it determines what the layer can remember, what it can be audited on, what a downstream layer can trust it to have preserved. Pick it before picking anything else, because a handoff between two layers is really a handoff between two different answers to "where does this fact live."

The boundary, drawn as Sarah would actually have to ship it

Sarah's system is this course's own running illustration, not a documented production deployment — the schema, tool denylist, and rollout stages below are a worked design, the shape a real handoff needs, not a case study with its own incident report. Treat it as a template to adapt, not a receipt to cite. Here is the handoff Sarah's system needs, annotated well enough that an engineer could build it directly rather than infer it from a diagram:

Three things about that boundary are worth naming explicitly, because each one is a design decision Sarah made on purpose rather than a default she inherited. First, the job table is a typed contract, not a raw dump of the conversation:

CREATE TABLE layer_c_jobs (
    id            uuid PRIMARY KEY DEFAULT gen_random_uuid(),
    goal          text NOT NULL,
    slot_snapshot jsonb NOT NULL,
    budget_usd    numeric(6,2) NOT NULL DEFAULT 0.50,
    max_turns     int NOT NULL DEFAULT 15,
    status        text NOT NULL DEFAULT 'queued',
    reviewed_by   text
);

Layer C receives a bounded task, not the whole customer relationship. Second, Layer C's tool denylist is explicit: no shell, no email, no external HTTP, no credentials. The research pool can look things up; it cannot act on the outside world. Third, and this is the part easiest to skip under deadline pressure: Layer C's output is a draft written to a review queue, never a reply sent directly to the customer. Sarah is the trust boundary between the stochastic layer and the person on the other end of the ticket, and she is the only one; nothing else in the diagram substitutes for that review.

That third point is also the answer to the latency problem the state-model table doesn't cover on its own. Layer A promises the customer a response in seconds. Layer C takes hours, sometimes overnight. If that gap isn't made visible ("we'll follow up within 24 hours" stated plainly to the customer), it gets violated silently instead, and the customer experiences it as the system going quiet rather than as a deliberate handoff to a slower, more careful layer.

Handoffs don't ship at full trust on day one

The boundary above assumes Sarah trusts Layer C's output enough to route it through Layer A at all. That trust isn't assumed into existence. It's built in stages, and the stage you start at matters more than almost any other decision in this lesson.

Sarah's own rollout: Stage 1 for the first month, every draft approved by hand. Stage 2 in month two, once the sample reviews show the drafts are reliably good. Stage 3, for her, is "never, probably," because a wrong reply reaching a customer is a worse failure than the ongoing cost of keeping her in the loop. That's not caution for its own sake; it's the same trust-boundary decision from the diagram above, stated as a rollout plan instead of an architecture diagram. The anti-pattern is starting at Stage 3 because a demo worked once. A demo isn't a track record, and skipping the stages is exactly how a boundary that was never designed ends up designing itself, badly, in front of a customer.

The four layers from Lesson 05 are the pieces. This lesson was about the seams between them, the part that doesn't show up when you're admiring how clean any one quadrant looks on its own. Next: why the Headless + Stochastic quadrant specifically, the one Layer C lives in, carries risk the other three don't, and what that risk actually costs.