Watch & compare
Queues and backpressure
Different ways to see the same idea. Play one cut at a time, then return to the guide to try it yourself.
Why we recommend Queued ≠ complete
Use Astra as the chapter entry: it follows F from blocked submission through admission, execution and completion in the guide’s documentation-check/search-tool setting. Baseline offers a spare producer–worker view and now visibly continues service at the end, while Sol adds the complementary refusal-and-resubmission policy with acknowledgement-controlled delivery credit. Astra’s larger queue cells and explicit Done 6/6 ending make admission versus completion easiest to verify on a phone.
Revised original · 26 sec
Backpressure — bounded queue
Queues buffer work, while backpressure limits incoming work when consumers cannot keep up.
Read the video sequence
- 0–9s: Worker A runs while B, C and D fill the bounded queue. A FULL signal travels to the producer.
- 10–14s: The producer pauses with E waiting outside the full queue; the worker continues.
- 15.5–19s: Taking B frees a slot. The producer resumes and admits E.
- 21–26s: C leaves the queue and completes. D then leaves and is still running as the scene fades, with E waiting and three jobs completed. This is continued service, not completion of the whole batch.
About this cut
Production: Original prototype; model not recorded.
Revision: gpt-6-astra comparative review.
Generic finite producer/worker example; five jobs, three waiting slots and one worker.
Ends with work in progress; no delivery, durability, rate or deadline guarantee.
Original model was not recorded; this correction does not establish authorship.
Audio analysed, not listened to.
Recommended · Astra · 30 sec
Queued ≠ complete
A full queue can delay an agent tool submission; a free place admits the job, but admission is not successful tool completion.
Read the video sequence
- A documentation-check agent submits search job A. It passes through the queue, runs on the single tool worker, and completes normally.
- Search job B runs slowly. C, D and E fill all three waiting places while B continues.
- The full-queue signal pauses the agent with job F held outside the queue. F has not been admitted; existing tool work continues.
- After B completes, removing C frees a place. The agent resumes and submits F. F is now queued, while C is running; admission has not completed F.
- F stays queued while earlier search jobs finish. Only after D and E have run does F leave its waiting place for the tool worker.
- F runs and its progress bar fills. Its state changes to complete only after execution finishes. The queue is empty and all six jobs have outcomes. This finite example is not a delivery or timing guarantee.
About this cut
Production: gpt-6-astra.
Illustrative finite batch with one worker and three waiting places; job durations are not benchmarks.
FULL and SPACE visualize local admission feedback, not RabbitMQ protocol messages or acknowledgements.
Bounding waiting items does not guarantee bounded memory, request rate, deadlines, permissions, durability or exactly-once effects.
Audio was checked by waveform, spectrum, cue timing and encoded peak analysis; it was not physically listened to.
This is an author-reviewed alternative, not a comparative recommendation.
Alternative · Sol · 30 sec
Bound the backlog
Bound waiting agent work at intake as well as active deliveries; acknowledge completion before the next delivery, and resume admission when a waiting slot is free.
Read the video sequence
- Normal work: task A enters an empty queue, runs on one agent, finishes, and sends an acknowledgement back. The example uses illustrative limits of one active task and three waiting tasks. Active execution falls to zero on completion; acknowledgement releases delivery credit separately.
- A burst arrives while task B runs slowly. Tasks C, D and E fill the three waiting slots. The runner still executes only one task, but its execution limit has not prevented the waiting queue from filling.
- The full intake gate refuses task F and returns it to the caller. F remains deferred outside the queue, and the caller pauses new intake. The queued tasks remain visible while B continues running.
- B completes, active execution falls to zero, and its acknowledgement returns to release delivery credit. C then leaves the first queue slot for the runner. Waiting work falls from three tasks to two, so the application intake gate reopens.
- The caller deliberately resubmits F once. F occupies the free slot, the queue returns to three waiting tasks, and intake closes again while C runs. Work stays bounded even though demand remains. The stage fades to the opening title. Runtime code must enforce the limits; persistent prompts do not enforce permissions.
About this cut
Production: gpt-6.1-sol.
Revision: gpt-6-astra comparative review.
Illustrative runtime policy: one active task and three waiting tasks are not performance measurements or recommended defaults.
The application admission gate is separate from RabbitMQ prefetch; enforce waiting capacity atomically in runtime code.
One producer and successful reliable delivery are assumed; failures, durable deferral, redelivery, deadlines and concurrent admission races are omitted.
Persistent prompts do not enforce queue bounds or tool permissions, and these limits do not guarantee output quality or completion time.
Audio was analysed for peak, cue energy and synchronization; it was not physically listened to.
These animations use sound effects rather than narration. The written guide explains the mechanism and its limits. Model names describe how a cut was made, not a quality ranking.
What the review found
- Normal before overload: Astra completes A at 4.6s and Sol at 5.5s before showing a slower B. Baseline spends roughly 3–15s on its first slow job, making the mechanism sparse but giving readers less evidence of normal service before the stall.
- Full means different upstream policies: baseline holds E at its paused producer around 9.8–14.6s; Astra holds F around 11.6–15s. Sol refuses F at 17.25s, returns it by 18.45s and deliberately resubmits it at 24s. Sol is a useful policy alternative, not the guide’s exact await-put sequence.
- Capacity is freed by removal: baseline dequeues B at 15s and later admits E; Astra dequeues C at 15s and admits F at 17.2s. Sol separates B’s completion at 21s, the returning acknowledgement, C’s dequeue at 22.2s and F’s admission at 25.3s. Its extra mechanism needs the guide’s distinction between delivery credit and ready backlog.
- Execution and acknowledgement now agree: Sol shows ACTIVE 0/1 at A’s 5.5s and B’s 21s completion while the acknowledgement is still returning. This repairs the original DONE/ACTIVE 1 contradiction without conflating completion with release of delivery credit; baseline and Astra do not attempt to teach acknowledgement transport.
- Endings support different claims: revised baseline dispatches D at 23.8s and shows it running at 24.8s with E still waiting. Sol shows C running and D/E/F waiting at 27.5s, demonstrating bounded continued demand. Astra dispatches F at 25s and completes it at 27s, then shows an empty queue and Done 6/6—the strongest closure for the finite-batch exercise.
- Phone review at 350px: Astra’s 10.8–12.5s full-queue scene and 25.7–27.5s ending have the clearest task states and counters. Baseline’s 9.8s capacity pills are smaller but its sparse drawing is easy to follow. Sol’s 17.6–25.5s gate, feedback path, acknowledgement and phase labels demand more attention; all three remain readable, with Astra’s final drain compressed and Sol’s slow-B interval comparatively long.