Week 2: Prompt Is Not Enough: Designing an AI App as a Workflow System

Build in Public — Week 2 (April 27–May 3)

When people talk about building AI apps, they often start with prompts. I did the same at the beginning. If Lumi needed to understand reminders, then surely the key was to write a good prompt: tell the model how to extract the task, the time, the recurrence, and the user’s intent. That was necessary. But it was not enough.

The more I worked on Lumi, the more I realized that an AI product is not just a prompt wrapped inside a chat interface. A useful AI product is a workflow system. The prompt helps the system understand. The workflow makes the product reliable.

A reminder request is not always simple

Some user requests are easy:

Remind me to call John tomorrow morning.

But real users do not always speak in clean examples. They may say:

Remind me to take medicine every day at 8 AM.

or:

Move tomorrow’s reminder one hour later.

or:

Pause my gym reminder until next Monday.

or:

Delete the reminder about the hospital appointment.

These are different operations. Some create a new task. Some update an existing one. Some pause a recurring reminder. Some require the system to find the right task first. If the app only sends the text to an LLM and asks for an answer, the result may look intelligent but still fail as software. Software must decide what action to take.

I needed a workflow, not just understanding

For Lumi, I started thinking in steps. When the user sends a message, the system needs to ask:

1. What is the user trying to do?
2. Is this a new reminder, an update, a deletion, a query, or something else?
3. Is the request clear enough?
4. Is important information missing?
5. Does it relate to an existing task?
6. Does the user need confirmation?
7. What should be saved?
8. What should be shown back to the user?

This is product design, not only prompt design. The AI part helps with language. But the product still needs business logic. That was familiar to me from enterprise software. In a business system, users do not just enter data. Their actions move through states: draft, submitted, approved, rejected, completed, cancelled. Lumi is much smaller, but the same thinking applies. A reminder has state. A conversation has state. A task may be created, modified, paused, resumed, deleted, or completed.

The chat input is only the front door.

The assistant must know when to act and when to ask

One of the most important product questions was:

When should Lumi act immediately, and when should it ask the user for clarification?

If the user says:

Remind me to call John tomorrow at 9 AM.

the system can usually create the reminder directly. But if the user says:

Remind me to call John tomorrow.

there may be a missing time. Should Lumi choose a default? Should it ask? Should it create a general task? If the user says:

Move the medicine reminder.

the system needs to know which reminder and what new time. This is where many AI demos look good but products become difficult. A demo can assume the best case. A product must handle unclear cases. So Lumi needed simple conversation behavior:

• act when the request is clear
• ask when key information is missing
• let the user confirm or adjust
• keep manual editing available
• never pretend uncertainty is certainty.

That last point matters. In a reminder app, being confidently wrong is not acceptable.

AI output must become structured product data

Another important lesson was that LLM output cannot remain only text. If Lumi simply replies:

Sure, I’ll remind you tomorrow morning.

that sounds nice, but it is not enough. The app needs structured information:

• reminder title
• date
• time
• recurrence
• status
• relationship to conversation history
• whether it should be active.

Only structured data can drive notifications, lists, editing, and future reminders. This is one reason AI products still need traditional software architecture. The model may understand language, but the app must store and execute decisions in a predictable way. In other words:

Natural language is the input. Structured state is the product.

Confirmation is part of trust

At first, it is tempting to make the assistant feel magical: user says something, Lumi creates it instantly. But for task management, too much magic can become risky. If the AI misunderstands the date or recurrence, the user may not notice until the reminder fails. So I started thinking about confirmation and review as part of the product experience. The user should be able to see what was created, open the task, edit it, delete it, and understand what Lumi did.

This is not just UI polish. It is trust design. Users trust a tool more when they can inspect and correct it. That is especially important for AI products.

The workflow also protects the future

In the first version, Lumi focuses on reminders. But I did not want the system design to assume that reminders would be the only possible capability forever. If Lumi later supports other small personal assistant actions, the app will still need a way to understand the user’s intent and route it to the right capability. That does not mean building a huge platform from day one. It means avoiding a design where everything is hardcoded around one prompt. So Week 2 was about finding a balance:

• keep the first product small
• keep the first capability focused
• but design the conversation flow as a workflow, not a one-off prompt.

That made the product easier to extend later without overbuilding too early.

What I learned in week 2

The biggest lesson was simple:

A prompt can understand a sentence. A workflow turns that understanding into a product.

For Lumi, the real work was not only asking an AI model to parse reminders. It was designing what happens before and after that understanding:

• how to classify the request
• when to ask follow-up questions
• how to save the result
• how to let users review it
• how to keep data local where possible
• how to make reminders actually work.

This changed how I thought about the product. Lumi was not a chatbot with reminder features. It was a reminder product with a conversational entry point. That distinction became very important. Because once I saw the product this way, the next steps became clearer. I needed to build screens, states, storage, reminders, editing flows, and tests — not just better prompts. The AI was important. But the system around the AI was what made Lumi usable.