Part 1 of 3 — The Foundation Series on AI Optimization
This is not about vibe coding
When most people hear “prompt engineering,” they think of typing clever things into ChatGPT to get a better answer. That is not what this article is about.
This is about the prompts that live inside your products — inside your AI agents, your chatbots, your retrieval pipelines, your customer support systems. The prompts your users never see, but experience in every response they get.
Written once by the developers at the time of development. Then tailored every time with dynamic questions given by user.
When your AI agent gives a vague answer, loses context, formats things wrong, or hallucinates — 9 times out of 10, a poorly written prompt is the root cause.
A better prompt gives a better result. Every time. Consistently.
Lets know where this prompt sits in your application (AI agent or just a chat bot simply uses LLM).
Role of a Prompt in AI Agent:
Lets say we have a chat bot TED for a travel company. TED is responsible for giving tour schedules, information, price to the customer by answering their questions typed in Natural Language.
Some realtime questions:
- Do you have any international trips of 7 days?
- I want to travel within India for 3 days — a weekend plus one day.
- What is the tariff for the Rajasthan Heritage Tour?
- Are there any upcoming tours to Ladakh in August?
- I have a booking — can I change my travel date?
When user types in the prompt, a sequence of process will happen in backend. Lets understand that from the below InfoGraphics.
In Step #2, the prompt will be given to the LLM and the result will be received. If you send the prompt as plain, the LLM does not know how you are going to use the result or what LLM is doing for the application even though you have provided the tasks or some information about the application.
The LLMs are not particularly designed to provide answer in a structured way BY DEFAULT. You need to ask the LLM in such a way that the answer can be used by the next backend process.
In the above inforgraphic, if the return format is not mentioned, the LLM can only reply the answer in a text. Interpreting it could be a big string manipulation or the result might not be fully useful to the application.
For example, if the intent could be one of the name of the tasks that should eb executed after this step.
Example tasks could be,
“Intent”: “search_tours” → query tours DB by filters
“Intent”: “get_tariff” → fetch pricing for a specific tour
“Intent”: “check_availability” → check seats & departure dates
“Intent”: “booking_change” → modify an existing booking
“Intent”: “cancellation” → cancel a booking
“Intent”: “new_booking” → initiate a booking flow
“Intent”: “general_enquiry” → no DB call needed, Ted answers directly
“Intent”: “escalate” → hand off to human agent
So what is the best way to TALK TO THE LLM?
The 5 parts of a good prompt
Every well-crafted prompt for a product use case has five components.
You do not always need all five. But knowing all five means you know exactly which one is missing when something goes wrong.
Lets go through this with our example.
Putting it all together
Here is a complete prompt built piece by piece using all five parts:
ROLE:
You are TED, a friendly and knowledgeable travel assistant for Wanderlust Journeys — a premium tour company specializing in curated group travel across India and international destinations. You are warm, enthusiastic about travel, and always specific. You only recommend tours that Wanderlust Journeys actually operates. You never guess on availability or pricing — if unsure, you offer to check and confirm.
TASK:
Your job is to help users find, evaluate, and enquire about Wanderlust Journeys tour packages. When a user asks about a trip, do the following:
Understand their preferences — duration, destination type, budget if shared. Recommend 1–2 specific tours from the catalogue that match their needs.
Share key details: duration, highlights, departure dates, and starting tariff. Ask if they would like to proceed with an enquiry or booking.
For existing bookings: assist with date changes, cancellations, or information — always check user profile first.
Business rules: Date changes allowed up to 21 days before departure. No refunds within 7 days of travel. All prices are per person, twin sharing.
CONTEXT: [Injected dynamically per session]
User name: {user_name}
Past bookings: {booking_history}
Membership tier: {membership_tier}
Available tours: {tour_catalogue}
Conversation so far: {conversation_history}
EXAMPLES:
User: “Do you have any international trips of 7 days?”
TED:
{ “Intent”: “search_tours”,
“confidence”: “high”,
“response”: “Yes! Two great 7-day packages right now — Thailand Highlights from Rs.65,000/person and Sri Lanka Heritage from Rs.55,000/person. Want me to walk you through what is included?”
}
User: “What is the price for the Ladakh trip?”
TED:
{ “Intent”: “get_tariff”, “confidence”: “high”,
“response”: “Our Ladakh High Altitude Explorer is
Rs.58,999/person (twin sharing) — flights from Delhi,
all stays, meals, permits, and a local guide for 8 days.
Only 6 seats left for July 12th. Shall I hold one?” }
User: “I was charged twice and need a refund.”
TED:
{ “Intent”: “escalate”,
“confidence”: “high”,
“response”: “I completely understand your concern.
Connecting you to our billing team right now —
please hold.”
}
FORMAT:
Respond in JSON only. Do not include any text outside the JSON block.
{
“Intent”: “search_tours | get_tariff |
check_availability | new_booking |
booking_change | cancellation |
general_enquiry | escalate”,
“confidence”: “high | medium | low”,
“response”: “your reply to the user”
}
The problem that comes next
Writing a great prompt once is achievable. Writing great prompts for a system with 10 modules, each handling a different task, each needing different examples and formats — and then keeping them all updated as your product evolves — is a different problem entirely.
Doing this manually does not scale. You end up with a folder full of prompt files, version numbers, and no systematic way to know if changing one thing made things better or worse.
There is a better way. And it starts with thinking about your AI system not as a collection of prompts — but as a program.
That is what Part 2 is about.
