Builder notes

Four patterns that survived production — and the one that did not

These come from systems that run for real users: an AI concierge on live listings, a healthcare analytics copilot, an HR retrieval tool. Four decisions we would make again, and one we would not.

3 systems
Where these patterns were tested
A listings concierge, a healthcare copilot, an HR retrieval tool — all in production, all on real data.
2 lanes
Streaming and intent, separated
They fail independently, so one bad parse never silences the reply.
≥ 0.97
The quality floor that fails the build
A gate that only prints is not a gate.

Two lanes, not one

The first instinct is one model doing everything: keep the conversation human and work out what the user actually wants. In production that instinct costs you twice — the reply gets slower while the understanding gets shallower, because the two jobs pull in opposite directions.

The streaming laneA fast hosted model keeps the exchange human: short latency, conversational register, no schema anxiety.
The intent laneA separate pass reads what the user actually needs — filters, constraints, the real question — and can be slow, strict and testable without touching the reply speed.
Why it survivesThey fail independently. A malformed parse degrades one aspect of the answer instead of breaking the conversation.

Ground the model, then let it retry

On the healthcare copilot, plain-English questions had to become BigQuery queries against regulated pricing data. Two decisions carried it: the model was grounded in canonical schemas, so it only touches tables it is allowed to touch; and a retry handler diagnoses a failed query — correcting a column name, re-planning — and resubmits, without ever showing a stack trace to the person asking.

  • Schema-aware planning: the assistant's reach is a written allowlist, not a good intention
  • Errors are for the machine: the user sees a corrected answer, never a database complaint
  • Suggested prompts and state-aware controls keep a non-technical user inside the safe path

Citations, or it did not happen

The HR retrieval tool answers natural-language candidate questions and attributes every result to its source. That single property changes what the tool is: a search that can be checked is usable inside a hiring process; a search that cannot is a liability nobody wants to defend in a meeting.

  • Every answer carries where it came from
  • Retrieval quality is judged on the source, not on the prose
  • The user stays the one making the decision

Weight is a product decision

The luxury feel on a listings platform is pacing, not payload. First paint is a 76-byte inline placeholder that owes the network nothing; image rungs climb 960w to 1920w; video loads when the browser is idle; data-saver devices get the poster and stop. A 40.5MB hero never loads for someone still deciding whether to scroll — and the feeling people call “premium” is exactly that restraint.

The pattern that died: a gate that only prints

We used to run media quality checks that reported a score. They were useless, and worse than useless: a re-encode could pass review with a visibly degraded file, and the check still printed a number nobody acted on. The fix was to make quality an invariant with teeth — every re-encode must re-pass SSIM ≥ 0.97 through the production filter stack, and the build fails if it does not.

A test that cannot fail is not a proofIf the gate has no failing case, it is decoration. Plant the violating input and watch the build stop.
The exit code is the artifactA gate must print and fail. A green number with a non-zero confidence gap is how a regression ships quietly.

If you are building this in-house

These patterns are not secrets; they are the parts people skip under deadline. If the work is one workflow with a named acceptance test, we can build it with you — or hand you the spec from a one-week diagnostic and step back.

Building an agent and unsure which parts to keep? Write us — describe the workflow and we will reply in writing with an honest read.