What an AI Prototype Needs Before Production

An AI demo can answer a useful question: does this model or prompt help with this task? Moving that demo into an operational workflow raises a different set of questions about validation, state, delivery, and ownership.

This is the architecture checklist I would use to review that transition.

Real systems have to answer harder questions:

• Where does data come from?
• What gets validated before AI sees it?
• What state must be preserved between steps?
• What happens when the model is wrong?
• Who reviews, overrides, or approves the output?
• How does the result enter a real workflow?

Without those layers, the prototype is doing something interesting, but it is not yet dependable.

The model and the surrounding workflow

Consider a workflow that receives a request, asks a model to summarize it, and routes it to a person for review. The model is one component in that architecture.

The surrounding workflow needs:

• ingestion
• validation
• routing
• persistence
• retry and recovery behavior
• output shaping
• delivery into a human or downstream system

If those pieces are weak, the system will feel fragile even if the model itself is strong.

Testing the model's response is useful, but it leaves those other behaviors unproven.

Six layers to review

These are six areas I would make explicit before deciding whether a prototype is ready for a particular use case. The required controls depend on the consequences of an error and the workflow's constraints.

1. Deterministic rules

Not every decision should be delegated to an LLM.

Jurisdiction checks, conflict rules, lifecycle constraints, authentication, and safety gates are often better handled deterministically.

If a system has no clear policy boundary, the model ends up carrying product logic it should never own.

2. State management

If a request passes through several steps, a stateless response box is not enough to describe its progress.

The system may need to remember:

• prior user actions
• pending tasks
• review status
• lifecycle stage
• retry context

Without state, the system cannot behave consistently over time.

3. Human handoff

When a person must approve or act on the result, the design needs a review path. AI can prepare, summarize, classify, or route the work; the interface should make the reviewer's responsibility clear.

Specify what the reviewer sees, what they can change, and where rejected or uncertain results go next.

4. Delivery path

What artifact actually leaves the system?

Common answers are:

• a qualified lead in a CRM
• a callback request
• a generated launch plan
• a structured transcript and summary
• a push notification

Define the destination and what counts as successful delivery. Generating an artifact and delivering it are separate events.

5. Observability

A supportable workflow should make questions like these answerable:

• Which step is failing?
• What inputs triggered this output?
• Which jobs are stuck?
• How often are humans overriding the AI?

Choose logs and metrics that help diagnose those problems without collecting more sensitive content than the task requires.

6. Workflow ownership

Name the person or team responsible for the workflow and for responding when it stops working.

A system should be shaped by the workflow it is supposed to improve:

• intake
• qualification
• planning
• notification
• summarization
• delivery

That owner should be able to explain the useful result, the acceptable failure behavior, and when the system should ask for help.

A better question to ask

Instead of asking:

"How can we put AI into this product?"

I think the better question is:

"Where does automation help this workflow close faster, safer, or with less coordination cost?"

That reframes the system around operational usefulness.

Sometimes the answer involves an LLM. Sometimes it involves rules, queues, lifecycle guards, and human review. The architecture should follow those needs.

Questions for a technical review

To review the engineering judgment behind an AI project, I would ask:

• Can this person design boundaries, not just prompts?
• Do they understand state, reliability, and delivery paths?
• Can they use AI without letting it destabilize the system?
• Can they turn a rough concept into software that operates under constraints?

An experiment can be valuable evidence if its question and limits are clear. A production claim needs additional evidence about how the system behaves in use.

Closing thought

A prototype demonstrates a capability under particular conditions. Moving it toward production means defining the surrounding workflow, testing its failure paths, and making its operating responsibilities explicit. A more capable model does not remove those requirements.