Part 1 tore down the DeepSeek design; this part answers one question: how do those mechanisms land in the backend of an AI video/image site?
The nine lessons and the mapping table are my translation, not DeepSeek's original text. The core is authorize before spend, never fork billing on retry, and reconcile before retry.
In one sentence: translating the authorization, ticketing, execution, and recovery mechanisms from part 1 into nine rules and one concept map for an AI video/image product.
Part 2 · Media site
Nine lessons for an AI video/image site
These are my translations into media generation. They are not DeepSeek’s text; DeepSeek is describing a general agent system, not a video product.
- Model a generation request as a ticket, not a chat message. A request needs an immutable job id, an authorization scope and a billing subject. Chat is context, not the state machine.
- Money is a deterministic gate, not a model judgement. Balance, quota, model/resolution/duration allowlists, per-request cost ceiling and pre-moderation are code. The model may answer “is this prompt clear or risky?” It may not set price or permission.
- Separate authority from context. “Change the background to a beach” in the same project is context and can enter the existing job. “Go from 720p to 4K and from 5 to 10 seconds” expands scope and needs a new quote and a new mandate. Chat cannot raise the budget.
- Separate Ticket from Attempt. One job can have many provider attempts. A retry does not fork the order, the bill or the user-visible job id. Each attempt records provider, provider job id, request hash and raw response.
- Record before the side effect; reconcile before retry. Reserve credits, write the outbox row, then submit. If provider state is unknown, query it; do not resubmit. After a restart, reconcile before deciding to settle or release.
- Give every job its own workspace and asset prefix. Temporary files, references, outputs and thumbnails are isolated by job id. A provider URL is not storage; mirror it to your own R2/S3 and verify checksum, dimensions, duration and moderation.
- Expose four states; interrupt only on exceptions. Working, Needs you, Ready, Failed. Do not stream provider polling, retries or chain-of-thought into the main UI; put them in a developer trace.
- Downgrade speculation. DeepSeek’s speculative execution assumes background compute is relatively cheap. Full video rendering is not. Speculate on prompt cleanup, safety pre-check, cost estimate, thumbnails and 480p drafts; do not speculatively render full 1080p/4K by default, and never create a user-visible charge for it.
- Observe a new provider before auto-routing to it. Shadow mode: quote and record “would route”, but do not submit. Compare cost, latency, failure rate and human review quality, then roll out by percentage. That is the prototype’s accept mode applied to provider routing.
A mapping table: from agent concepts to media generation
| DeepSeek concept | Media-site equivalent | Rule to keep |
|---|---|---|
| Source | Web upload, public API, Stripe, moderation callback | Dedupe by source event id; store before processing. |
| Trigger | One generation request / payment callback / moderation result | Immutable; a client retry must hit the same job. |
| Thread | Project, conversation, asset lineage | Provides context; never grants budget. |
| Gate | Auth, credits, catalog, resolution/duration, cost ceiling, pre-moderation | All deterministic; return one actionable error. |
| Assessment | Prompt clarity, reference suitability, policy risk | Advice only; cannot change price, credits or permission. |
| Decision | accept / clarify / reject / defer | clarify asks one concrete question. |
| Mandate | Model, resolution, duration, max cost, fallback list, rights | Immutable; wider scope means a new job and a new quote. |
| Ticket | One billable generation job | Owns user-visible identity and the billing subject. |
| Assignment | One provider attempt | A retry creates a new attempt, not a new ticket. |
| Executor | Provider adapter / GPU worker | Isolated workspace; reports facts, does not write job state directly. |
| Subscription | Project/conversation context | Context only; no expansion of authority. |
| Outbox | Charge, refund, webhook, email, asset publish | Record first, execute after commit; ordered per ticket. |
| Policy | Model catalog + price table + safety rules | Versioned; every quote and mandate records the version. |
| Watchdog | Stuck job, overbudget, loop, provider incident | May stop, downgrade or release; never expand budget. |
Adoption order and anti-patterns
If you have a prototype today, build in this order instead of starting with a “multi-agent team”:
- 01Schema, idempotency keys and an append-only credit ledger.
- 02Quote and deterministic gate. Do not connect a provider before these exist.
- 03One provider, one worker; get submit / poll / cancel working.
- 04Outbox and crash-safe submit; prove that a restart does not double-submit.
- 05Webhook plus polling reconciliation; a duplicate webhook must be a no-op.
- 06Asset mirroring, checksum, dimensions/duration validation and moderation.
- 07Four-state UI and an exception queue. Do not start with a log stream.
- 08Deterministic watchdog; only then consider a model for “is it drifting?”.
- 09A second provider, fallback and shadow routing.
What not to copy
- All eleven concepts. A two-person media site needs job, attempt, ledger and outbox first. Do not start with Correlation, Subscription and the full Policy model.
- The plugin architecture. “Everything is a plugin” is an advantage for a harness substrate, not an MVP requirement for your site.
- Multi-agent role-play. One queue, a pool of workers and an exception panel is usually more reliable than “Router Agent, Planner Agent, Critic Agent”.
- An LLM watchdog. Make stuck jobs, overbudget and repeated errors deterministic first. Use a model only for “it is progressing but in the wrong direction”.
- Speculative full renders. Video marginal cost is too high; speculate only on cheap upstream steps.
- Provider URLs as storage. They expire, rate-limit and disappear. Mirror the bytes.
- Five providers before reconciliation. If one provider’s reconciliation is not working, five will only multiply the accounting errors.
If you remember one sentence: the thing worth copying from DeepSeek is not multi-agent role-play. It is turning “this work may be done” into an auditable mandate, then hanging execution, retry, recovery and notification underneath it. For an AI video/image site, that means quote / gate / ledger first, provider scheduling second; no duplicate charges and no duplicate submissions before autonomy.
Sources
This part translates the teardown in part 1 into a media-generation scenario; it is not DeepSeek's original text, and DeepSeek discusses general agent systems, not video generation. Original links and verification are in part 1.