DEV Community: Ivan

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

Ivan — Sat, 10 Oct 2026 10:57:17 +0000

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

How I connect reusable AI skills to generation code and output checks

Ivan — Fri, 09 Oct 2026 10:20:26 +0000

The failure was in the guidance reaching generation

When I reviewed Launcherry's channels, I found missing platform guidance in parts of the generation workflow and drafts that repeated internal goal labels instead of giving readers a useful next step. I needed to fix how expertise reached generation. Improving the fluency of the copy alone would leave both problems unresolved.

I needed a way to carry researched expertise into the moment the product generated a deliverable. I directed a library of reusable AI skills: one shared core and 16 channel-specific files for planning, writing and asset direction. The library is implemented in local development; public availability depends on the release and channel conditions.

I need evidence that the model receives the guidance; the document alone cannot establish that. Having a model receive it does not establish that the resulting campaign is useful. I treated authoring, integration and evaluation as separate responsibilities, each requiring its own evidence.

Begin with the deliverable a person needs

My starting point was the platform and delivery type. An organic post, a paid ad and a short video script place different demands on the work. The writer needs to understand what the audience encounters, what the format can carry and what next action fits the communication. A platform name appended to generic instructions cannot express all of that.

I researched the requirements of individual channels and turned them into guidance tied to the output. In the Launcherry library, the channel-specific material supports the angle, the writing and the assets. Shared standards provide consistency across those stages. This gives the generation workflow relevant guidance without requiring each file to restate the whole product philosophy.

For another team, I would start with the recurring deliverable that causes the most avoidable rework. Define its audience, purpose and constraints, then inspect actual failures. A skill earns its place when it addresses that repeated work. The evidence should explain why the guidance is needed, rather than simply show that a file exists.

Separate common standards from channel judgment

The shared core provides a place for standards that should remain consistent. The channel files carry the distinctions that make the deliverable appropriate to its destination. This separation is a maintenance choice as much as a writing choice: a common requirement has one home, while a channel-specific correction can remain local to that channel.

I can also use that separation to diagnose disagreements. If every channel produces the same kind of weak next step, I need to examine shared guidance and the surrounding generation workflow. If the problem belongs to a particular delivery format, its specialist guidance becomes a more relevant starting point. The location of a rule should reflect its scope.

I describe these assets as reusable domain skills. Launcherry loads their guidance into its own generation code. That is distinct from claiming that every file is a drop-in package for every coding agent. The wider Agent Skills specification describes a portable packaging approach; compatibility with a particular host still needs to be established.

Connect the skill to the work it is meant to change

In Launcherry, the generation code loads the shared core and channel guidance. The labelled guidance blocks identify the material intended for the model; documentation outside those blocks remains for the people maintaining the library. The connection between file and generation stage is part of the implementation, rather than an assumption about how the system behaves.

I use that boundary to keep the editorial purposes clear. Maintainers need context about a skill, its intended use and how to assess it. The model needs the instructions relevant to the current task. Combining those purposes carelessly can send maintenance notes or evaluation language into the generated result.

I saw this problem in the earlier goal-label leakage. A planning label may be useful internally while making poor campaign copy. I want the skill to help translate intent into reader-facing language. The founder should receive a usable next step for their audience, without having to interpret the generation system’s terminology.

Check the skill and assess its outputs separately

The library has an authoring standard with mechanical checks. Those checks can establish that the expected guidance blocks exist and that the files meet the required structure. They are useful because malformed guidance can fail before any question of writing quality arises.

Output evaluation asks a different question: did the workflow produce an appropriate result for this product and channel? I keep evaluation criteria separate from the generation guidance. That gives review its own role, rather than treating compliance with the writing instructions as proof of success.

A practical evaluation should compare relevant examples, record the failure being investigated and keep the surrounding workflow in view. A result may reflect the skill, the model, the supplied business context or a later validation step. My article on AI output evaluation explains why those distinctions matter when a field can pass validation and still be unusable.

Model-agnostic guidance still needs model-specific evidence

I wrote the guidance without making it dependent on one model vendor. That supports reuse and lets the domain knowledge survive a provider change. It does not establish identical behaviour across models. A new model can interpret a requirement differently or fail a constraint that an earlier model handled.

My acceptance decision therefore belongs to the combination being evaluated: guidance, context, model and generation workflow. A successful run gives evidence about that combination. It should not become a claim that the skill guarantees good output everywhere.

I treat research, integration, evaluation and maintenance as parts of skill engineering. Writing instructions is one part of that work. I build the connections that make expertise usable inside a product, then review what the product actually returns. The Launcherry case shows this library in its product context; the development harness article explains the delivery practice around it.

Originally published at ivanped.ai: Building reusable AI agent skills: From domain expertise. More of my work: ivanped.ai

How I verified prompt-cache reads in a generation-repair workflow

Ivan — Thu, 08 Oct 2026 15:46:51 +0000

The cache was receiving writes without delivering reuse

I found the caching problem in Launcherry's production usage records: repeated generation calls wrote prompt tokens to cache but read nothing back within the run. The Google Search copy bank and analysis records showed the same pattern. I needed to verify what later calls reused through the application, rather than rely on the fact that caching was configured.

I treated that as an operating question that needed evidence. The relevant outcome was whether later calls actually reused suitable context. A cache setting, a successful response or a lower estimate in a spreadsheet could not establish that behaviour.

The September 17 verification records the investigation and correction. In each of two later generation-repair calls, 3,879 of 3,932 input tokens were read from cache. That is 98.65%, rounded to 99%. The result describes prompt-token reuse in those measured calls, not a product-wide reuse rate or a 99% cost saving.

Ask what is being reused and what is changing

Generation and repair have a useful relationship for this investigation. They concern the same underlying work, while a repair asks for a specific correction. Some context can remain relevant across those calls; other parts need to change. The request design has to preserve the distinction.

I examined the behaviour through the application’s own adapter and the production provider path. The recorded probe compared requests that held relevant conditions steady with requests that changed them. That helped establish which changes interfered with reuse, rather than treating every cache miss as the same problem.

My starting point is the request the product actually sends. Two prompts that seem similar to a human can differ in ways that matter to the provider’s cache. The model, request configuration and surrounding adapter behaviour belong in the investigation alongside the written instructions.

Provider conditions also differ. OpenRouter’s prompt-caching documentation distinguishes cached-token reads from cache writes and describes provider-specific behaviour. I use that documentation to frame a check, then rely on the application’s measured response to establish its result.

Keep the correction bounded by product requirements

I directed a correction to the generation request design so repeated repair work could reuse its shared context. The work retained the generation requirements and validation responsibilities. Reuse needed to support the product’s existing job, rather than become a reason to weaken its checks.

The implementation was accompanied by regression cases covering the relevant request behaviour and the relationship between draft and repair. Those checks provide repeatable evidence about how the application constructs its work. A live rerun then provided the evidence about cache reads.

I keep those checks separate. A unit test can establish the application’s request structure under its test conditions. It cannot prove that a remote provider returned a cache hit. Conversely, one provider hit cannot establish that all the surrounding application paths remain correct. The investigation needed both kinds of evidence.

Read the measured result without inflating it

The recorded rerun includes preparation calls before the two successful repair reads. Those earlier calls wrote cache entries. Repairs 2 and 3 then each read 3,879 of 3,932 input tokens from cache and wrote no new cache tokens. The numerator and denominator belong to each of those calls.

I calculate the ratio by dividing 3,879 by 3,932 and multiplying by 100. The resulting 98.65% can be rounded to 99% for a compact outcome label, provided the sample stays visible. Reporting the denominator makes the label inspectable.

It would be misleading to apply that ratio to the whole generation run. The earlier cache writes are part of the run, and the recorded ratio concerns input tokens rather than every billed token. A broader claim would require broader measurement.

I also avoid equating reuse with latency improvement. The cache evidence establishes reads. A latency claim needs timing measurements under relevant conditions. The same discipline applies to claims about throughput, margins or customer savings.

Connect caching to economics without confusing the measures

AI usage is an operating cost in Launcherry. Caching can affect that cost, but total economics also depend on the provider’s rates, output generation, the number of calls and the amount of repair required. A highly reused input can still accompany an unhelpful result or an expensive sequence.

My acceptance decision therefore keeps quality and economics connected but separately measured. Output evaluation assesses the deliverable. Production usage establishes the cost and cache behaviour observed in that environment. The workflow architecture determines which work happens and how often.

For a product team considering optimisation, I would begin with a complete user outcome and its actual usage records. Locate repeated work, identify reusable context and measure the effect of a bounded change. Preserve the original quality requirements so a cheaper run cannot pass simply by doing less useful work.

Require observed reuse before claiming an optimisation

This investigation changed how I describe the result. I can point to a specific diagnosis, a request-design correction, regression coverage and live cache-read evidence. I cannot use those two calls to establish a universal saving, and I do not need that larger claim to explain the value of the work.

I want to be able to trace an operating assumption into application behaviour, test it and correct it. It connects AI workflow construction to the cost of delivering the product, while keeping the evidence understandable.

The Launcherry case study carries the compact outcome. This article preserves the scope behind it. For another system, I would ask the same concrete question before calling caching successful: which later calls read cached context, how much did they read and what did the complete run cost to produce an acceptable result?

Originally published at ivanped.ai: Prompt caching in practice: Diagnosing writes without reuse. More of my work: ivanped.ai