How I design AI generation stages to carry context and handle failure

#ai #webdev #programming

A founder should not have to integrate the answers

I design Launcherry's product workflow around a founder who knows the product but still needs to decide how to promote it. Positioning shapes the audience, the audience shapes the message, and the channel shapes the deliverable. If separate AI outputs ignore those dependencies, the founder has to reconcile the answers. That integration work is the problem I want the workflow to address.

Launcherry addresses that problem by carrying business context from a product URL or brief into marketing analysis and campaign preparation. I designed its AI workflow orchestration around connected stages with defined inputs, outputs and checks. The aim is a campaign the founder can review, with the reasoning and constraints of the earlier work still informing it.

There are two workflows in this project. One generates product outputs inside Launcherry. The other directs AI implementation around the build. This article concerns the product workflow; the development harness describes how I organise the work that changes it.

Distinguish business facts from generated recommendations

I start the product workflow with a URL or brief. That input gives the workflow a business to reason about. It also introduces a boundary: information supplied or retrieved about the business has a different status from an AI recommendation about what the founder should do next.

I treat that distinction as an architectural requirement. Campaign preparation needs relevant facts about the product, while analysis can propose positioning, audiences or channels. A persuasive draft cannot establish the truth of its own claims. Fact grounding belongs in the workflow that produces the draft and in the checks around it.

Consider a general example: an analysis recommends leading with a service’s quick turnaround. That recommendation does not establish a specific delivery guarantee. The later copy needs support for any promise it makes. This is an illustrative decision boundary, rather than a claim about a particular Launcherry customer or campaign.

The question I ask at each handoff is what the next stage is entitled to treat as known. That makes the relationship between research and writing more explicit, and gives review a basis for identifying unsupported additions.

Give each generation stage a specific responsibility

In the current development implementation, generation is staged, with fact grounding and bounded repair. Business analysis informs campaign preparation; channel requirements shape the deliverable; checks determine whether an output can proceed. Each stage exists because it has a particular job to do.

I use those stage responsibilities to locate failures. A campaign can have a weak angle, unsuitable writing or incomplete asset direction. Treating the whole output as one undifferentiated answer makes it harder to understand where guidance or implementation needs to change. Clear stage responsibilities make the investigation more focused.

The channel skill library fits this structure. Its guidance addresses planning, writing and assets, with shared standards across channels. The stages consume the relevant expertise as part of generation. Channel-specific material is connected to the work, rather than left as documentation beside it.

I do not assume that adding stages improves a workflow. Every handoff adds a possible place for context to drift, and every model call contributes to operating cost and waiting time. A stage needs to justify itself through a distinct responsibility and evidence about the result.

Design the failure route alongside the success route

A workflow also needs a response when output misses a requirement. Launcherry’s generation implementation includes checks and bounded repair. The purpose is to correct a specific failure within a controlled process, while keeping the product requirements intact.

Ad-copy length provides a useful example. I rejected cutting generated text to satisfy a platform limit. That could turn a complete thought into a technically acceptable fragment. I directed changes to generation and validation so the workflow could address overlong copy while preserving the requirements.

I assess a repair against both constraints and meaning. A shorter response that loses the useful message has not resolved the product problem. An eloquent response that still exceeds the field limit has not resolved it either. The acceptance decision needs evidence about both.

For another product, I would establish a stopping condition early: what failure can be repaired, how the result will be assessed and what happens when repair does not establish an acceptable output. That is a design recommendation. The exact route must fit the product’s risks and the behaviour its implementation can support.

Let the founder make the consequential decision

The implemented Launcherry journey connects product input, analysis, campaign review and export. Approval makes a campaign ready for export. Download and supported platform delivery remain separate choices, and Launcherry cannot automatically activate paid media.

I give the generation workflow a clear destination: prepare work for a founder to assess. A successful model response does not authorise delivery. A campaign that passes technical checks still needs a decision about whether its message, audience and intent are right for the business.

I also account for availability conditions. A delivery module in the code does not establish that every founder can use that provider. The interface and server conditions determine which options are available. I explain the user journey and those distinctions in designing human approval before delivery.

Measure the complete workflow and preserve the scope of the evidence

I assess generated output against the product requirements, using regression coverage and real-model evaluation. Production cost, latency and caching need their own observations. An evaluation bridge can support iteration on the real generation pipeline without reproducing the economics or timing of the production provider.

For this project, newer skills and workflow improvements continue in local development. The public product and the current local implementation are related, but they are not interchangeable evidence. I preserve that distinction when describing the workflow and deciding what is ready to release.

My practical starting point for AI workflow architecture is a single user outcome. Trace the information it needs, the transformations involved, the checks at the handoffs and the decision that permits action. That gives the architecture a purpose beyond connecting tools. The Launcherry case study shows how I brought that approach into a working product.

Originally published at ivanped.ai: AI workflow orchestration: From analysis to campaign. More of my work: ivanped.ai