Matching model responses to tasks in a Telegram content workflow

When a content workflow sends several tasks to a model, receiving a response is not enough. The program must know which request the response belongs to before it presents a draft for review. Here is how that handoff is structured in my Python-based Telegram content factory, and what the identifier does and does not solve

The workflow

The factory monitors selected Telegram channels through the owner's account. It turns candidate news items into cards in a private group's ideas topic. A person selects a card, chooses the destination channel and platforms, and can add an author comment

The program passes the source, channel-specific writing rules and optional comment to a separate writer bot. The writer researches the topic, prepares a draft and checks facts. The completed draft goes to a separate posts topic for human review. The program does not publish the main post until someone presses the publish button

Match the answer to the request

Each request starts with a JSON header containing request_id, stage and schema_version. The writer's reply ends with [END:<request_id>], using that request's identifier. The receiving program can associate the reply with the task that produced it instead of assuming that the next message belongs to the last task sent

The stage field describes the step, while schema_version gives the sender and receiver a way to identify the request format. The end marker is part of the communication protocol: it is not evidence that the draft is accurate, safe, or approved

The surrounding workflow is described in my walkthrough of the content factory, including where the person selects a topic and reviews the result

Checks worth running

Before relying on a similar handoff, send two distinguishable test tasks and verify that each result is attached to the correct request. Test a missing or mismatched end marker and verify that it is not mistaken for a completed response. Then test the human decision: requesting a rewrite should return a draft for review, and cancellation should not publish it

These are suggested tests, not a claim that every failure mode is automatically handled by the protocol. A matching identifier solves correlation; factual checks, access control, durable state and duplicate-publication prevention are separate engineering problems

This article was created with the help of AI.