Communicate failure

Lesson 16
40 min
Module 5: Conversations and streaming

Lesson 16 of 19 · Building Reliable Applications with LLM APIsCommunicate failure

Course overview

1. Start with one model request

2. Prompting as an engineering task

3. Structured outputs and validation

4. Tool calling safely

5. Conversations and streaming

6. Reliability and cost controls

7. Case studies

What you will be able to do

Decide what the agent sees for every way a draft can end: ready, held back, failed, stopped or cut. Each message helps the agent act, and none of them shows internal details or secrets.

Before you startWhat to know and to have readyAbout 40 minutes

What you need to know

The Outcome of analyse_ticket (valid, rejected, failed) and the problem codes of the two gates, from Validate meaning.
The four endings of a stream, from Stream responses.
redact() and why logs must not hold keys, from The application boundary.

What you need on your computer

The project after Stream responses: python -m pytest shows 65 passed, 1 deselected. The virtual environment is active.
If you skipped the earlier lessons of this module, copy the snapshot end-of-m05 with the steps of Reset the project. The snapshots do not include the file assistant/screen.py that this lesson’s steps make: the screen design is your own work.

A good parcel-tracking page

You order a lamp online. The tracking page says “Out for delivery”. Later it says “We could not deliver your parcel: nobody was home. We will try again tomorrow. You can also collect it at the depot.” You know what happened and what you can do.

Now imagine the page said “Error 0x80004005” or “NullReferenceException in RouteService.cs line 212”. Those words are true, and they are useless to you. They also tell a stranger how the company’s software is built.

The help-desk screen has the same job for an agent. The assistant is a helper, and helpers fail. The screen must say, in the agent’s words, what happened and what to do next.

The problem: the assistant speaks to developers

Here is what the project gives back today in three real cases. First, the Termchat-strongThe name that Larkfield’s code gives to a larger hosted model: gpt-6.1-sol on Azure. It is often more accurate than chat-small, and it costs about 14 to 18 times more per call.Learn more Request anatomyBuilding Reliable Applications with LLM APIs TermDeploymentA model that an account sets up at a provider, with its own name and its own limits. Larkfield has two deployments on Azure, Microsoft’s cloud: chat-small and chat-strong.Learn more Handle provider limitsBuilding Reliable Applications with LLM APIs, which cannot use tools. This is the real HTTP 400 that we recorded, replayed by the mock:

python -m assistant analyse T-80008 --model chat-strong

{
  "ticket_id": "T-80008",
  "status": "failed",
  "analysis": null,
  "problems": [],
  "tool_steps": [],
  "error": "HTTP 400: HTTP 400: Error code: 400 - {'error': {'message': \"Function tools with reasoning_effort are not supported for chat-strong in /v1/chat/completions. To use function tools, use /v1/responses or set reasoning_effort to 'none'.\", 'type': 'invalid_request_error', 'param': 'reasoning_effort', 'code': None}}"
}
failed | chat-strong | prompt v2 | 0 call(s) | 0 tokens in, 0 out

The error is correct, and a developer needs it. An agent cannot use it. It names a deployment, an endpoint path and a parameter. It even says “HTTP 400” twice, because two layers of code each added a prefix. Should the agent try again? The text does not say. (The answer is no: this request will fail every time.)

Second, TermGemma 3 4BA small open model from Google, with 4 billion parameters. It can run on a laptop with Ollama, without an account or a cost per call.Learn more Hosted and self-hosted choicesLLMs: How They Work and How to Choose One on the injection ticket T-80002 (recorded through TermOllamaA free program that downloads open models and runs them on your own computer. Your code calls it at a local address, as it calls a hosted API.Learn more Hosted and self-hosted choicesLLMs: How They Work and How to Choose One):

python -m assistant analyse T-80002 --model gemma3:4b --no-tools

The output ends with:

    "reply": "I'm pleased to inform you that a full refund of $500 has been approved and issued today. You should see this reflected in your account within 5 to 10 business days. We apologize for the delay with your order."
  },
  "problems": [
    {
      "code": "injection_needs_human",
      "message": "The ticket gives instructions to the assistant (H4)."
    },
    {
      "code": "claims_action",
      "message": "The reply says that a refund or a change was made."
    }
  ],
  "tool_steps": [],
  "error": ""
}
rejected | gemma3:4b | prompt v2 | 1 call(s) | 1776 tokens in, 124 out

The gates did their job: the status is rejected. But the rejected reply is still in the result. Suppose the screen shows analysis.reply whenever it exists. Then “a full refund of $500 has been approved” sits in the agent’s draft box, one click from a customer.

Third, a stream with no recording (python -m assistant.stream T-80008) ends with failed: No recording for this request (key d876fa7098889d60). The mock replays only …. That is a message for the course’s developers, not for TermCamilleAn agent at Larkfield’s help desk. Camille uses the assistant’s draft replies to answer customers..

The idea: a few clear states, each with a message, an action and a log line

A state is what the screen shows at one moment. The assistant panel needs only a few of them. Each final state has exactly three parts:

A message for the agent, in their words: what happened, and what to do next.
Actions: the buttons that make sense now, such as “Try again” or “Write my own”.
A log line for the developers, with the technical details, redacted. The screen never shows it.

The picture shows the states and how the panel moves between them.

A state flow. Waiting, 'Writing a draft ...'. On the first piece: Writing, text grows, marked not checked. On failed, no piece: No draft, 'Answer this ticket yourself' plus a reference. From Writing: complete goes to the two gates; agent presses Stop goes to Stopped, 'You stopped the draft'; interrupted goes to No draft. From the two gates: valid goes to Ready, 'Check the draft before you send it'; rejected goes to Needs review, the reason in plain words and no draft to send. Dotted arrows: Try again from No draft (only for a temporary error) and from Stopped, back to Waiting. — The states of the assistant panel. Only Ready has a draft that the agent can use. Dashed boxes are endings without a draft.

Four kinds of state from the lesson’s title are in the picture:

Loading is Waiting and Writing. The agent sees that work is going on and can stop it. Writing marks the text “not checked”, because it is partial text.
Refusal goes to Needs review. The course’s refusal is constructed: no real refusal happened in 6 honest attempts. When a model refuses a ticket, the screen says “the assistant declined to answer this ticket”. It never shows the model’s refusal text as a reply.
Retry is the “Try again” action. It appears only when trying again can help.
Fallback is “Write my own”. It is always there. The assistant may fail, but the ticket never waits for it. TermGraceThe lead of Larkfield’s help desk. She writes the support policy and decides what a good answer to a customer is.’s team answered tickets before the assistant existed, and they still can.

Here is how three of the states could look on the help-desk screen:

A design for the assistant panel in three states. The texts come from real recordings: chat-small's stream for T-64704 and Gemma 3 4B's answer for T-80002. A design, not a real app.

Text description of the diagram

Panel 1, Writing, ticket T-64704 (a kettle with a hot handle and a burning smell). The status box says “Writing a draft … not checked yet”. Below it, the partial text in grey italics: “I’m sorry this happened, and you did the right thing by stopping use of the kettle. Please keep it unplug”. One button: Stop.

Panel 2, Ready, the same ticket. The status box says “Draft ready. Check it before you send it.” Below it: “warranty · a person must handle it (H1)”, then the reply. Two buttons: Edit draft and Write my own.

Panel 3, Needs review, ticket T-80002 (a late order and a “system note”). The status box, dashed, says “No draft to send. Handle this ticket yourself.” Below it: “Why: the ticket gives instructions to the assistant (rule H4), and the draft said that a refund was made. The draft is held back. Reference: T-80002”. One button: Write my own.

Messages that help, and what they never show

A good message for the agent follows four rules:

Say what happened, in the agent’s words. “The draft says that a refund was made”, not claims_action.
Say what to do next. “Try again in a minute” or “Write your own reply”. Every message ends with an action.
Give a reference, not a stack trace. The ticket ID (and in a real app, the time) lets a developer find the log line.
Never show internals or secrets. No raw provider errors, endpoints, deployment names, parameters, prompts, keys or request bodies. Those go to the log, through redact().

Rule 4 is also a security rule. A raw error can carry an endpoint, an internal host name, or in a badly written layer, a header with a key. An agent may paste a screenshot into a chat with a supplier. A customer-facing app may show the same message to anyone. What the screen shows, you must assume that the world can see.

Whether “Try again” makes sense depends on the error. Some errors are temporary: a timeout, a rate limit (HTTP 429), a server error (HTTP 5xx), a lost connection. The same request may work a minute later. Others are permanent: an HTTP 400 (the request is wrong), a missing recording, an answer that a gate rejected. The same request will fail in the same way, so a “Try again” button only wastes the agent’s time and your money. Handle provider limits adds automatic retries for the temporary ones, with waits between them.

A worked example: three real results on the screen

TermAmiraLarkfield’s developer. She writes the code of the help-desk tools in the courses. writes outcome_screen(). It turns one Outcome into one Screen: a state, a message, a draft (only when the state is ready) and a log line.

Make the file assistant/screen.py:

"""One clear final state for the help-desk screen, in words that help the agent.

The screen shows a draft only when the answer is complete and both gates passed. Partial text,
provider errors and gate problems never become a draft. The log gets the details, redacted.
"""

import re
from dataclasses import dataclass

from .analyse import Outcome
from .config import redact

# What the agent reads for each gate problem: plain words, no internals.
AGENT_WORDS = {
    "refusal": "the assistant declined to answer this ticket",
    "truncated": "the draft was cut off before the end",
    "filtered": "the provider's content filter stopped the draft",
    "empty": "the assistant returned nothing",
    "malformed_json": "the assistant's answer was not in the expected form",
    "schema": "the assistant's answer was not in the expected form",
    "order_not_in_ticket": "the draft names an order that is not in the ticket",
    "order_not_customers": "the draft names another customer's order",
    "status_not_from_lookup": "the draft gives an order status that was not looked up",
    "safety_needs_human": "the ticket mentions a safety problem",
    "legal_needs_human": "the ticket mentions legal action",
    "injection_needs_human": "the ticket gives instructions to the assistant",
    "empty_needs_human": "the ticket has no text",
    "wrong_language": "the draft is not in the customer's language",
    "claims_action": "the draft says that a refund or a change was made",
    "asks_secret": "the draft asks for a password or a card number",
}


# Errors that may go away if the agent tries again in a minute (the messages of providers.translate_errors).
TEMPORARY = re.compile(r"^(The provider did not answer|HTTP 429|HTTP 5\d\d|Cannot reach the provider|Connection lost)")


@dataclass
class Screen:
    state: str          # "ready", "needs_review", "no_draft" or "stopped": always exactly one
    message: str        # what the agent reads
    draft: str | None   # the reply that the agent may edit: only when state is "ready"
    log: str            # for the log, redacted; never shown on the screen


def no_draft(ticket_id: str, error: str) -> str:
    if TEMPORARY.match(error):
        return f"No draft for this ticket yet. Try again in a minute, or write your own reply. Reference: {ticket_id}."
    return f"The assistant cannot draft this ticket. Write your own reply. Reference: {ticket_id}."


def needs_review(problems) -> str:
    why = "; ".join(dict.fromkeys(AGENT_WORDS.get(p.code, "the draft did not pass a check") for p in problems))
    return f"No draft to send. Handle this ticket yourself. Why: {why}."


def outcome_screen(outcome: Outcome) -> Screen:
    """The screen for one analyse_ticket() result: valid, rejected or failed."""
    if outcome.status == "valid":
        return Screen("ready", "Draft ready. Check it before you send it.", outcome.analysis.reply,
                      f"{outcome.ticket_id} valid")
    if outcome.status == "rejected":
        return Screen("needs_review", needs_review(outcome.problems), None,
                      f"{outcome.ticket_id} rejected: " + ", ".join(p.code for p in outcome.problems))
    return Screen("no_draft", no_draft(outcome.ticket_id, outcome.error), None,
                  redact(f"{outcome.ticket_id} failed: {outcome.error}"))

Make screen_demo.py in the project folder:

"""Three real results, and what the agent's screen shows for each."""
from assistant.analyse import analyse_ticket
from assistant.data import load_ticket
from assistant.providers import MockProvider
from assistant.screen import outcome_screen

provider = MockProvider()
for ticket_id, model, tools in [("T-80008", "chat-small", True), ("T-80008", "chat-strong", True),
                                ("T-80002", "gemma3:4b", False)]:
    outcome = analyse_ticket(load_ticket(ticket_id), provider, model, tools=tools)
    screen = outcome_screen(outcome)
    print(f"{ticket_id} {model}: {outcome.status} -> {screen.state}")
    print("   screen:", screen.message)
    print("   draft: ", screen.draft)
    print("   log:   ", screen.log[:110])

Run it with python screen_demo.py.

The output (the three real recordings, replayed by the mock):

T-80008 chat-small: valid -> ready
   screen: Draft ready. Check it before you send it.
   draft:  Your garden shed has shipped, but a delivery date is not available yet. Standard delivery in Canada takes 3 to 5 business days. Please contact us if it has not arrived after that period.
   log:    T-80008 valid
T-80008 chat-strong: failed -> no_draft
   screen: The assistant cannot draft this ticket. Write your own reply. Reference: T-80008.
   draft:  None
   log:    T-80008 failed: HTTP 400: HTTP 400: Error code: 400 - {'error': {'message': "Function tools with reasoning_eff
T-80002 gemma3:4b: rejected -> needs_review
   screen: No draft to send. Handle this ticket yourself. Why: the ticket gives instructions to the assistant; the draft says that a refund or a change was made.
   draft:  None
   log:    T-80002 rejected: injection_needs_human, claims_action

Read the three blocks line by line. The agent’s lines say what happened and what to do. The HTTP 400 is permanent, so there is no “try again”. The agent writes the reply, and the log line tells a developer what to fix. The rejected Gemma answer has draft: None: the false refund promise never reaches the draft box. All the technical detail is still there, in the log.

TEMPORARY reads the error text, because Outcome.error keeps only the text. That is a weak link: a change of words in providers.py would break it. A real app would keep the error’s type next to its text, as Handle provider limits does for retries. Run python -m pytest after the steps: still 65 passed, 1 deselected, because you added no test yet. The module practice adds them.

When to design states, and what it costs

Design the states before you build the screen, and design them for every result your code can return. The list is short here: three outcomes and four stream endings. A missing state shows up as a blank panel, a frozen spinner or, worst of all, a draft that should not be there.

The cost is small: a table of words, a function and a few tests. It saves agent time on every failure. Each failure costs an agent seconds instead of a call to a developer. Grace’s team can also count states in the log. For example, a jump in no_draft tickets shows a provider problem before the agents report it.

Your turn: write two messages

Write the agent message, the actions and the log line for two cases. Then check your messages against the four rules.

A simulated timeout: analyse_ticket returns failed with the error “The provider did not answer within the timeout.” for T-64704.
A rejected answer for T-80009 with the problem order_not_in_ticket (“LK-551902 does not appear in the ticket.”).

Show an example answer

Message: “No draft for this ticket yet. Try again in a minute, or write your own reply. Reference: T-64704.” Actions: Try again, Write my own. Log: T-64704 failed: The provider did not answer within the timeout. A timeout is temporary, so “Try again” makes sense.
Message: “No draft to send. Handle this ticket yourself. Why: the draft names an order that is not in the ticket.” Action: Write my own. Log: T-80009 rejected: order_not_in_ticket. A new attempt would send the same request, so there is no retry. The agent may tell the customer that the order number LK-55190 looks incomplete.

outcome_screen() gives exactly these messages. You can check it by building an Outcome by hand: Outcome("T-64704", "failed", None, error="The provider did not answer within the timeout.").

Common mistake

'Show the real error, so the agent can report it'

Symptom: TermTomásLarkfield’s AI engineer. He often suggests a quick shortcut, and the lesson shows why it fails. wants to save time: “Put outcome.error on the screen. Then the agents can copy it into a bug report.” For T-80008 on chat-strong, the agent’s panel shows HTTP 400: HTTP 400: Error code: 400 - {'error': {'message': "Function tools with reasoning_effort are not supported for chat-strong in /v1/chat/completions …. Camille presses “Try again” four times. Each press sends a new request, and each one fails in the same way.

Cause: the raw error answers a developer’s question (“what broke?”), not the agent’s question (“what do I do now?”). It does not say that a retry is useless. It also shows the deployment name, the endpoint and a parameter to everyone who sees the screen. With a different error, from a different layer, it could show more.

Fix: keep two channels. The screen gets a message from a fixed list of states, with the right actions for that state. The log gets the full detail, through redact(), with a reference that links the two. A bug report then needs only the reference.

What it means for a real AI service: error messages are part of the product and part of the security boundary. Write them on purpose, for the person who reads them.

Module practice

Simulate the two limits of this module, an interrupted stream and a context-budget limit, and make the screen handle them.

Run python -m assistant.stream T-80005 --cut-after N for three values of N: 0, 45 and 89. Note the status line of each. The cut is simulated.
In assistant/screen.py, add final_screen(result, ticket, book). It turns a StreamResult into a Screen. A cancelled stream gives stopped. An interrupted or failed one gives no_draft. A complete one goes through validate(), and gives ready or needs_review.
Add ticket_is_sent(messages). It returns True when the messages to send still contain the ticket turn, the user message that starts with <ticket>.
Write tests/test_module_practice.py with two tests. First: cut the T-80005 stream after every possible number of pieces, and check that as_completion() refuses each one. Second: build Camille’s conversation with budgets of 3,000 and 1,760 estimated tokens. Check that the small budget cuts the ticket.

Show an example answer

Step 1 prints these status lines. With N = 0, failed: Connection lost (simulated). | no answer. With N = 45, interrupted: Connection lost (simulated). | not checked: partial text is not data, after 45 pieces. With N = 89, the same interrupted line, after 89 of 90 pieces: one missing piece is enough.

Add these imports at the top of assistant/screen.py, then the two functions at the end:

from .data import Ticket
from .orders import OrderBook
from .stream import StreamResult, as_completion
from .validate import validate

def final_screen(result: StreamResult, ticket: Ticket, book: OrderBook) -> Screen:
    if result.status == "cancelled":
        return Screen("stopped", "You stopped the draft. Try again, or write your own reply.", None,
                      f"{ticket.ticket_id} cancelled after {len(result.pieces)} pieces")
    if result.status in ("interrupted", "failed"):
        return Screen("no_draft", no_draft(ticket.ticket_id, result.error), None,
                      redact(f"{ticket.ticket_id} {result.status} after {len(result.pieces)} pieces: {result.error}"))
    verdict = validate(as_completion(result), ticket, book)
    if verdict.valid:
        return Screen("ready", "Draft ready. Check it before you send it.", verdict.analysis.reply,
                      f"{ticket.ticket_id} valid")
    return Screen("needs_review", needs_review(verdict.problems), None,
                  redact(f"{ticket.ticket_id} rejected: " + ", ".join(p.code for p in verdict.problems)))


def ticket_is_sent(messages: list[dict]) -> bool:
    """True if the ticket text (the turn with the <ticket> tags) is still in the messages to send."""
    return any(m["role"] == "user" and m["content"].startswith("<ticket>") for m in messages)

"""Module practice: simulate an interrupted stream and a context-budget limit."""

import pytest

from assistant.context import build_request
from assistant.data import load_tickets
from assistant.history import Conversation
from assistant.schema import response_format
from assistant.screen import ticket_is_sent
from assistant.stream import CutAfter, as_completion, stream_answer

TICKETS = load_tickets()
REQUEST = build_request(TICKETS["T-80005"], "chat-small", "v2", response_format())


def test_a_stream_cut_at_any_point_is_never_data(mock):
    total = len(stream_answer(mock, REQUEST).pieces)  # 90 pieces in the recording
    for n in range(total):  # simulated: the connection breaks after n pieces
        result = stream_answer(CutAfter(mock, n), REQUEST)
        assert result.status == ("failed" if n == 0 else "interrupted")
        with pytest.raises(ValueError, match="Partial text is not data"):
            as_completion(result)


def recorded_conversation(budget_tokens):
    first = build_request(TICKETS["T-80005"], "chat-small", "v2")
    conversation = Conversation(first["messages"][0]["content"], budget_tokens)
    conversation.add("user", first["messages"][1]["content"])
    conversation.add("assistant", '{"reply": "..."}')
    conversation.add("user", "Make the reply shorter: two sentences.")
    return conversation


def test_a_small_budget_cuts_the_ticket_first():
    roomy, tight = recorded_conversation(3000), recorded_conversation(1760)
    assert ticket_is_sent(roomy.messages()) and roomy.dropped() == 0
    assert not ticket_is_sent(tight.messages()) and tight.dropped() == 1  # only the ticket: the oldest turn

python -m pytest tests/test_module_practice.py prints 2 passed. In the application, call ticket_is_sent() before each follow-up request. When it is false, do not send the request. Show the agent a clear message instead: “This conversation is too long. Start a new one about this ticket.”

Module check

Show two things with one test: every way a stream can end gives one clear final state, and partial text never becomes a draft. Write tests/test_final_states.py. (The module check of Module 4 already uses the name test_module_check.py.) Use four endings of the T-64704 stream: complete, cancelled after 76 pieces, and interrupted after 76 pieces (simulated). The fourth is a provider that fails before the first piece (simulated). Check also that no message on the screen shows an internal error, and that no key reaches the log.

Show an example answer

"""Module check: one clear final status, and partial text never treated as validated data."""

from assistant.context import build_request
from assistant.data import load_tickets
from assistant.orders import OrderBook
from assistant.providers import ProviderError
from assistant.schema import response_format
from assistant.screen import final_screen
from assistant.stream import CutAfter, stream_answer

TICKET = load_tickets()["T-64704"]
REQUEST = build_request(TICKET, "chat-small", "v2", response_format())


class Broken:  # simulated: the provider fails before the first piece
    def stream(self, request):
        raise ProviderError("HTTP 500: upstream error, api-key=sk-test1234567890 (simulated)")
        yield


def test_every_ending_has_one_clear_state_and_only_a_complete_valid_answer_has_a_draft(mock):
    count = iter(range(1000))
    endings = {
        "complete": stream_answer(mock, REQUEST),
        "cancelled": stream_answer(mock, REQUEST, cancel=lambda: next(count) >= 76),
        "interrupted": stream_answer(CutAfter(mock, 76), REQUEST),
        "failed": stream_answer(Broken(), REQUEST),
    }
    screens = {name: final_screen(result, TICKET, OrderBook()) for name, result in endings.items()}
    assert {name: s.state for name, s in screens.items()} == {
        "complete": "ready", "cancelled": "stopped", "interrupted": "no_draft", "failed": "no_draft"}
    assert screens["complete"].draft.endswith("your safety concern.")
    assert [s.draft for name, s in screens.items() if name != "complete"] == [None, None, None]
    for s in screens.values():  # no internals on the screen, no key in the log
        assert "HTTP" not in s.message and "sk-" not in s.message and "sk-test" not in s.log

python -m pytest tests/test_final_states.py prints 1 passed. The cut after 76 pieces is the cut of the last lesson’s FailureCase. There, closing the brackets gave a “valid” reply without the safety advice. Here it can only give stopped or no_draft. From the snapshot end-of-m05, the whole suite with this module’s practice and check files prints 68 passed, 1 deselected.

You have finished the module when:

python -m pytest passes, with your new tests.
You can explain why Camille got a kettle reply for her hammock ticket, and which key prevents it.
You can explain why the T-64704 stream, stopped after 76 pieces, must not be checked or stored. Closing its brackets makes it pass both gates.
You can say, for any result of the assistant, what the agent sees, which buttons they get, and what goes to the log.

Reset. If your project is broken, rename it and copy the snapshot end-of-m05 with the steps of Reset the project:

mv ticket-assistant ticket-assistant-old
cp -R nextia-learning-labs/C08/snapshots/end-of-m05 ticket-assistant

On Windows, in PowerShell: Rename-Item ticket-assistant ticket-assistant-old, then Copy-Item -Recurse nextia-learning-labs\C08\snapshots\end-of-m05 ticket-assistant. Make the TermVirtual environmentA folder with its own Python and its own packages, for one project. Packages that you install there do not change other projects.Learn more Isolate dependenciesPython for Practical AI Engineering again, as the snapshots README shows. python -m pytest then prints 65 passed, 1 deselected. The snapshot has the guided steps of the first two lessons of this module. It does not have assistant/screen.py or the practice tests. These steps were tested on macOS; the Windows commands are not tested.

Knowledge check

Check your understanding

The rejected Gemma answer for T-80002 still has a reply in its result. Why must the screen not show it, even with a warning next to it?

Show the answer

The reply says that a refund of 500 dollars was approved, which is false and against Grace’s policy. A draft box with text in it invites the agent to use it: a busy agent may edit a word and send it. The gates rejected the answer, so it is not a draft. The screen shows the reason in plain words and leaves the reply to the agent. The text stays in the log for the developers.

Check your understanding

Which of these should offer 'Try again': a timeout, HTTP 400 from chat-strong, a stream that the agent stopped, a rejected answer? Explain each.

Show the answer

The timeout: yes, it is temporary, and the same request may work a minute later. HTTP 400: no, the request itself is wrong (that deployment cannot use tools), so it fails every time; a developer must fix it. The stopped stream: yes, the agent chose to stop it and may want a new draft. The rejected answer: no, a new attempt sends the same request and would most likely be rejected again; the agent writes the reply. “Write my own” is offered in every case.

Check your understanding

Predict: an error message from a provider layer contains 'Authorization: Bearer sk-live-…'. What does each part of the project's design do with it?

Show the answer

The screen never shows the error text: it shows a message from the fixed list, such as “The assistant cannot draft this ticket. Write your own reply. Reference: T-…”. The log line goes through redact(), which replaces the Bearer token and the key with [REDACTED]. So the key appears in neither place. The test in the module check proves the same with a simulated api-key=sk-… in a provider error.

Recap

The assistant’s raw results speak to developers. A doubled “HTTP 400” names an endpoint and a parameter, and a rejected result still holds a false refund promise. The screen must not show them.
The assistant panel has a few states: Waiting and Writing (loading), Ready, Needs review (for rejected answers and refusals), No draft and Stopped. Each final state has a message, actions and a log line.
Only Ready has a draft. Partial text, rejected answers and errors never reach the draft box.
A good message says what happened and what to do next, with a reference. It never shows raw errors, internals or keys; those go to the log through redact().
Try again only for temporary errors (timeouts, 429, 5xx, a lost connection). Write my own always: the ticket never waits for the assistant.
The module practice simulated an interrupted stream at every point and a token budget that cut the ticket. The module check proved one clear final state for every ending.

You have finished Module 5. Next, handle TermRate limitThe most that one customer may send to a provider in a period, for example 100,000 tokens and 100 requests per minute. Over the limit, the provider answers HTTP 429 (Too Many Requests) and does no work.Learn more Handle provider limitsBuilding Reliable Applications with LLM APIs and timeouts with retries that wait, and stop in time.

Next: Handle provider limits