Build a Video Content Agent with Clear Draft and Publication States

Start with one repeatable production unit

Consider a fictional gardening business that wants a short practical tip from each approved lesson. The input is one lesson and a selected brand. The output is one Text Story draft. Publication happens only after the owner reviews the returned file and chooses a connected account.

The agent should keep a record containing the source identifier, approved copy, brand identifier, format and intended output count. These fields describe the actual work. A broad goal such as “grow our audience” cannot substitute for them.

Use the content repurposing workflow to decide which lesson deserves a short video. The agent should carry a chosen idea through production, not manufacture a new lesson merely because a calendar slot is empty.

Give every transition an observable condition

The following state names belong to this illustrative agent design. They are not additional Prolifik API status values.

Never advance from render pending to draft ready because enough time has passed. Retrieve the job. Similarly, a stored publishing request does not establish that the platform accepted and displayed the post.

Keep source content separate from agent instructions

An imported lesson may contain quoted prompts, embedded links or text addressed to a reader. Treat that material as content to summarize, not as instructions to change the agent's permissions or destination.

For the fictional gardening lesson, the useful claim might be “check the soil below the surface before deciding to water.” The agent can turn that into a short message while preserving any plant-specific qualifications. It should not add a universal watering schedule simply because a stronger-sounding instruction makes a tidy video.

Record the accepted text before rendering. Prolifik's customTexts can preserve supplied copy in a content job, using text for non-carousel formats or slides for a carousel. If exact wording matters, passing a general topic and hoping the generator repeats it is the wrong contract.

Persist identifiers outside a temporary media link

Store the job and piece identifiers when the service returns them. A conversation can be interrupted and signed media URLs can expire; the identifier lets the next session retrieve the existing content instead of producing a duplicate.

This conceptual pseudocode shows the boundary:

if no stored job identifier:
    submit the accepted brief once
    store the returned identifier and request identity
else:
    retrieve the existing job

for each returned piece:
    store its script, identifier and actual status
    if ready media exists:
        present that media for review
    if a failure is reported:
        preserve the reason and stop that piece

An implementation still needs durable storage, authentication and real tool calls. The sketch deliberately does not invent an SDK or hide those requirements behind a runnable-looking function.

Distinguish retries from creative revisions

A network interruption creates uncertainty about whether the request arrived. Recover that attempt with its stored identity and the documented idempotency behaviour. A new key should not be the default response to an unfamiliar error.

A render failure is another case. Prolifik exposes a retry for a failed piece's existing script, while regeneration replaces a failed piece with fresh copy and library assets. A reviewer asking for “the same words, rendered successfully” has not asked for a new message.

Creative revision is different again. If the gardening owner changes “water now” to “check the soil first,” update the identified piece and retrieve its replacement render. Invalidate the old review decision so the new wording is not published under approval of the previous file.

The batch MCP guide explains why successful and failed pieces should be tracked separately when the same architecture handles multiple outputs.

Make publication a specific, recoverable action

Before publishing, retrieve the current ready piece and resolve the selected connected destination. Keep the caption and exact scheduled time with the action. The agent should not infer a new social account from a brand name or treat a generation request as permission to post.

publish_content returns a publication record. Store its identifier, then use get_content_publish to retrieve the actual provider state. If scheduling succeeds but posting later fails, the record should still show that failure. A calendar entry alone is insufficient evidence of a public post.

Account connection and other dashboard-only tasks remain outside this tool sequence. Respect the host client's permission controls and the service's scopes. The Prolifik MCP documentation defines the tools the agent can call; it does not promise an always-running worker or unlimited quota. A useful agent finishes the authorized content unit, records the evidence and leaves the next person able to understand exactly where the work stands.