Test end to end: laptop, container, live URL

The book closes every deployment step with a done when list: conditions a command can prove, not a feeling that it works. ¹ This page runs those conditions in order, at each of the three places the agent now lives, and then adds the two checks that matter for behaviour rather than plumbing. Do not skip a stage; each one proves something the next one assumes.

Stage 1: the harness on your laptop

Boot it, then ask it two questions from another shell. The companion ships a smoke test that POSTs one message to a running harness; it is the whole end-to-end check in twenty lines, and it needs OPENAI_API_KEY in your .env so the agent can actually answer. ²

uv run uvicorn chat_agent.main:app --reload --port 8000

# scripts/smoke.py, the companion's smoke test: POST one message to a running harness
from __future__ import annotations

import json
import sys
import urllib.request

URL = "http://localhost:8000/runs"
BODY = {"message": "Hi, I cannot log in to account acct_1001.", "session_id": "smoke"}


def main() -> int:
    req = urllib.request.Request(
        URL,
        data=json.dumps(BODY).encode("utf-8"),
        headers={"Content-Type": "application/json"},
        method="POST",
    )
    try:
        with urllib.request.urlopen(req, timeout=60) as resp:
            print(resp.read().decode("utf-8"))
        return 0
    except Exception as exc:  # noqa: BLE001
        print(f"smoke failed: {exc}", file=sys.stderr)
        return 1


if __name__ == "__main__":
    raise SystemExit(main())

Change BODY to one of your own proven inputs from from plan to worker, then:

curl http://localhost:8000/health
uv run python scripts/smoke.py

Done when: the harness starts with no errors; /health returns {"status": "ok", ...}; /docs shows the two endpoints; the smoke test prints a reply and exits 0. ¹ If /runs answers 503, the key is not in .env; that is the harness working as designed, not a bug. ²

Stage 2: the same harness inside the container

Build the image and run it with your .env handed in at run time, then repeat exactly the two checks from stage 1 against the container. ¹

docker build -t chat-agent .
docker run --rm -p 8000:8000 --env-file .env chat-agent

Done when: the image builds with no errors; /health returns ok from inside the container; the smoke test passes against it; and after you change one source line and rebuild, the build is fast because the dependency layer stays cached. ¹

Stage 3: the deployed URL

Deploy as on the previous page. With the CLI, standard output is always the deployment URL, so capture it: ³

vercel > deployment-url.txt

Point the smoke test at that URL (URL = "https://<your-deployment>/runs") and run it again. The book's done-when for the cloud step is written to be run from somewhere that is not your laptop: opening https://<that-url>/health from your phone returns {"status": "ok", ...}. ¹

Then wait. Functions not receiving any traffic for 5 minutes in production, and 30 seconds in preview, automatically scale down, and the container gets a SIGTERM with a 30 seconds grace period. ⁴ The book's third condition is that after a quiet spell the app scales to zero and the next request wakes a copy within a few seconds, a scale-to-zero cold start. ¹ So the check is: leave it alone past the window, call /health once more, and expect a slower first answer followed by ok. A session started before the scale-down is gone afterwards, which is the laptop-versus-production difference the previous page's note warned about; it is expected here, not a failure.

Done when: /health answers ok over HTTPS from a device that is not your laptop; the smoke test passes against the live URL; and one cold start has been observed and recovered from. ¹

Stage 4: behaviour, against the live endpoint

Plumbing passing is not the agent passing. Run the golden set from evals before shipping against the deployed /runs, not the laptop; the book's reason for FastAPI's generated schema is precisely that the eval suite can hit the harness's endpoints with checked requests. ¹ Grade at least the final output and the tool calls with their arguments, as a pass rate across several runs, per difficulty tag; a change ships only when the failing case passes and nothing else regressed. ⁵

Stage 5: the gates, on purpose

Prove the harness stops when it should, before anyone else can reach the URL:

1. Send an input the input guardrail must block, and confirm the turn stops and no tool runs. That is the tripwire from the build page firing in production.
2. Send an input that reaches the approval-gated tool, and confirm the run pauses with an interruption instead of acting.
3. Send an input the agent cannot finish, and confirm max_turns ends the run instead of the loop running on.

Each of those is a condition from loop and harness made real: a limit, a deny, an ask.

The checklist

Everything above the last two rows is the book's own done-when list; the last two are the same discipline applied to behaviour. Keep this table in the project's progress file so the next run of your coding agent starts from what is already proven.

When the table is full, you have a basic worker behind a URL. If you want a second pair of eyes on it, the 15-minute call on the audit page is the place; bring the deployment URL and your step table.

Continue to give it a record, which is where the book continues past this room, or to the worked example to see the whole room on one small agent.