Long-Running AI Work Needs Checkpoints, Not Just a Bigger Prompt

A model can spend more time on a task and still leave an application with a difficult question: what, exactly, is safe to use?

Google announced Gemini 4 Carbon on October 28, emphasizing long tasks and cyberdefense, with a staged initial rollout. That makes this a good moment to revisit the application design around extended AI work. Official announcement.

This tutorial is a design you can start building with a text route available to your RelayRouter account. It is not a Carbon access guide or a claim that Carbon is available through the gateway.

1. Turn a broad request into a reviewable unit

“Prepare the product launch” mixes research, writing, asset production, and publication. If an agent stops halfway through, the application cannot infer which pieces are complete from a confident final sentence.

Narrow the first task to a product-page draft from approved facts. For a synthetic ceramic cup, those facts might be 300 mL, ivory, and hand-wash only. The useful output is a proposed draft and a checklist that another person can inspect. No one needs to publish anything during this first experiment.

Give the task a durable identifier. Keep the original brief, an input revision, and the latest approved artifact together. A model's conversational memory should not be the only place where your workflow state exists.

2. Separate a proposal from completed work

Use distinct states such as requested, draft_ready, review_needed, and approved. Decide which events are allowed to change them. A model can propose that a draft is ready; an application check or reviewer should establish whether the transition is valid.

For example, a checklist might ask whether the capacity is preserved, whether care instructions are accurate, and whether unsupported claims were introduced. A generated checklist is still a proposal. It is not evidence that those checks ran.

The downloadable Python example deliberately produces only that proposal. Its response contract has two fields:

{
  "task": "Review the ceramic cup draft",
  "checks": [
    "Confirm the stated capacity is 300 mL.",
    "Keep the hand-wash-only instruction.",
    "Remove claims not supported by the approved brief."
  ]
}

This is an illustrative expected shape, not a recorded model response. The local validator checks the exact field names, text types, three-item list, and field lengths. A human still needs to judge whether the proposed checks are useful.

3. Make the first API connection

Create an API key and select a documented text route in the current RelayRouter console. Copy its Base URL and model identifier rather than guessing an ID from a headline. Keep the key on the server.

Set these variables locally, then run the included request_checklist.py:

export RELAYROUTER_BASE_URL='COPY_HTTPS_BASE_URL_FROM_CONSOLE'
export RELAYROUTER_API_KEY='YOUR_SERVER_SIDE_KEY'
export RELAYROUTER_MODEL='AVAILABLE_TEXT_MODEL_ID'
python request_checklist.py

The script uses Python's standard library. It appends /chat/completions to the Base URL, sends one non-streaming text request, checks normal completion, and parses the result. Use a route that documents support for that request shape. A world simulation or a provider-hosted agent is a different product surface.

The key request instructions are intentionally modest:

payload = {
    "model": model,
    "stream": False,
    "messages": [
        {
            "role": "system",
            "content": "Propose a review checklist. Return only JSON with exactly task (a short string) and checks (exactly three short strings). These are proposed checks, not completed work. Do not claim to have executed tests or changed files."
        },
        {
            "role": "user",
            "content": "Synthetic brief: draft a product page for an unbranded ceramic cup. Approved facts: 300 mL, ivory, hand-wash only. Suggest checks for factual fidelity, instructions, and review readiness."
        }
    ]
}

The complete example has response validation and error handling. This excerpt only shows the payload. Neither version executes tools, edits a repository, or publishes a page.

4. Save evidence at the boundary

After a successful response, record the task identifier, input revision, requested model, available response metadata, and the artifact awaiting review. Keep status separate from prose. If a reviewer rejects the draft, preserve the reason and the version they reviewed.

For a coding task, evidence might include a patch, the exact tests actually run, and their results. For a content task, it might include approved source facts and corrections. Do not let a model-written claim that tests passed replace actual test output.

Use the smallest record that makes a failure understandable. Avoid storing credentials or unrestricted customer text in general logs. Decide the appropriate retention policy for the actual application data.

5. Design resumption before adding more steps

Suppose the request times out. The client knows it stopped waiting; it does not necessarily know whether upstream computation ended. Avoid silently starting the entire workflow again, especially after side effects.

The application should inspect its last confirmed checkpoint and decide whether it can safely retry a pure generation step. Actions such as sending a message or updating an invoice need stronger reconciliation and duplicate-prevention rules. Those are application responsibilities, not consequences of choosing a larger model.

The practical value of RelayRouter is the API connection for supported routes while your own workflow defines completion. Start with one available route, one proposed artifact, and one reviewer. Build a record of progress that will still make sense after the conversation ends.