allanninal.dev/build

Part 4 of 7 · Order status responder series ~7 min read

How a status reply gets written

By this point the responder knows the order and has the live tracking in hand. All that’s left is to say it like a person would. This post is about the only place a model is allowed near the system: the single Bedrock call that turns real tracking facts into one friendly reply with an ETA — and the fences that keep it honest.

Key takeaways

  • One Bedrock Haiku 4.5 call per enquiry writes one reply — no chains, no follow-ups, no back-and-forth.
  • The model is handed the already-fetched tracking facts and told to use only those; it never queries anything itself.
  • If there are no facts to report, there is nothing to write — the order is escalated instead of dressed up.
  • The reply goes back out on the same channel the customer used: SES for email, the provider for SMS, the widget for chat.
  • Every reply is logged with the exact facts it was built from, so any message can be traced back to a real carrier scan.

The only place a model runs

This is the single spot in the whole system where a language model does anything. The matching was plain Python; the tracking lookup was a real API call. By the time we get here, the hard facts already exist: an order, a customer name, a carrier, a normalised status, the last scan and its location, and an ETA where the carrier gave one. None of that is in doubt. What’s left is purely a writing job — turn those facts into one message that sounds like a person from your shop, not a status code.

So the responder makes exactly one Bedrock Haiku 4.5 call. It hands the model the facts and the voice from your settings doc, and asks for one short reply. That’s the entire interaction — no multi-step reasoning, no tool use, no second call to “check” anything. The model is a writer, not a researcher. It cannot reach the carrier, it cannot read the orders, and it cannot decide a status. It can only phrase the facts it was given.

Facts in, words out

The prompt is built in code and is almost entirely facts. It carries the customer’s first name, the order number, the items in plain language, the normalised status, the last scan time and place, and the ETA. The instructions around those facts are short and strict: use only what you’re given, never state a delivery date the carrier didn’t provide, never apologise for a delay that isn’t in the facts, keep it to a few sentences, and match the house voice.

The result is a reply that reads naturally but can’t drift from the truth, because there’s nothing in the prompt to drift toward. A few worked examples:

  • Out for delivery. “Hi Priya — good news, your order 10482 is out for delivery today with DPD and should arrive by this evening. You’ll get a one-hour window from them by text. Anything else I can help with?”
  • In transit with an ETA. “Hi Tom — your order 10590 is on its way with Royal Mail. It was scanned at the Bristol hub last night and is due to arrive Thursday. I’ll keep an eye on it — shout if it’s not with you by then.”
  • Delivered. “Hi Jo — order 10333 shows as delivered yesterday at 2:14pm, left in the porch as you’d asked. If it’s not where you expected, let me know and I’ll dig in.”

Notice what isn’t there. None of them invents a reason for a delay, promises a date the carrier didn’t set, or offers a refund or a reship — the responder has no power to do any of that, so it never says it. When the facts are thin (in transit, no ETA from the carrier), the reply is honest about that too: “it’s moving but the carrier hasn’t given a delivery date yet” rather than a made-up “3–5 days”.

The reply writer: tracking facts and voice into one Bedrock call, validated, then sent on the original channel On the left, two inputs stacked: a box “Tracking facts” (status, last scan, ETA, order, customer) and a box “Voice and rules” from the settings doc. A decision sits between them and the model: “Any facts to report?” If no, an arrow goes down to “Escalate — nothing to write”. If yes, both inputs feed a central box “Bedrock Haiku 4.5 — one call, one reply”. Its output goes to a box “Check: facts only, length, no promises”, then to a box “Send on original channel” which fans out to three small boxes on the right — SES for email, provider for SMS, widget for chat. A separate arrow from the check goes to a cylinder “Audit log — reply plus the facts it used”. A dotted AWS account container surrounds everything except the three channel endpoints. A note reads: the model only writes words from facts it was handed; if there are no facts, the order is escalated, not dressed up. AWS account Tracking facts status, scan, ETA Voice & rules from settings doc Any facts to report? Bedrock Haiku 4.5 one call, one reply yes Escalate no Check facts only, length, no promises Send on original channel audit: reply + facts SES email SMS Web chat The model only writes words from facts it was handed — if there are no facts, the order is escalated, not dressed up.
Fig 4. One Bedrock call turns the real tracking facts and your voice into one reply. A check confirms it stuck to the facts, the reply goes out on the channel the customer used, and the reply plus its facts are logged.

One reply, and a paper trail

Two rules keep the writer honest in practice. The first is the one-reply rule: the responder answers once and stops. It is not a chatbot holding a conversation — it gives the status and an offer to help further, and if the customer writes back with anything beyond “thanks”, that next message is treated as a fresh enquiry and, more often than not, escalated, because a second question usually means the simple lookup didn’t satisfy them. One good answer beats a model improvising its way through a back-and-forth.

The second is the paper trail. Before the reply is sent, a quick check confirms it’s within length, contains no date or promise that wasn’t in the facts, and reads as a status reply rather than a commitment. Then the reply and the exact facts it was built from are written to the audit table. If a customer ever says “your system told me Tuesday”, you can pull the record and see precisely which carrier scan and ETA produced that line — or confirm it never said any such thing. The reply is sent on the same channel it arrived on: a reply via SES for email, back through the SMS provider for a text, and into the open widget session for chat.

Design rules that shaped the reply writer

  • One call, one reply. The model writes a single message and stops; it is not a conversation engine.
  • Facts in, words out. The prompt is the real tracking facts; the model phrases them and nothing else.
  • No facts, no reply. An empty hand means escalate, never improvise.
  • No promises it can’t keep. The responder reports status; it never offers refunds, reships, or dates the carrier didn’t set.
  • Same channel back. Email gets an email, a text gets a text, chat gets chat.
  • Log the facts, not just the reply. Every message can be traced to the carrier scan that produced it.
All posts