Writing a prompt flow your team can maintain

The problem with the clever prompt

An NBFC in Pune lends small business loans across Maharashtra and Gujarat. Its collections team wanted help drafting reminder messages for borrowers who had missed an EMI. A capable analyst wrote one long prompt: three pages of instructions covering tone, language, the borrower's history, which products allowed a part payment, what could never be said, and how to format the message for WhatsApp. It worked well in the demo.

Two months later the analyst moved to another team. A new rule arrived from compliance: no message may mention the borrower's guarantor. Nobody knew where in the three pages to add it, or whether an older line contradicted it. Someone added the rule at the end. The model followed it most of the time. Most of the time is not good enough for a regulated lender.

The lesson is ordinary software sense applied to prompts. Small parts, clear names, one job each, and tests that run before anything changes in production.

Split the work into steps

A prompt flow is a chain of small steps, where each step takes an input, does one thing and passes a result on. In the collections example, the long prompt becomes something like this.

Step 1: Gather the facts

Pull the borrower's record from the loan system: name, preferred language, product, days past due, amount due, last payment date and any open dispute. This step uses no model at all. It is a data lookup, and it should fail loudly if a field is missing.

Step 2: Decide what kind of message is allowed

Apply the business rules: if a dispute is open, no reminder goes out; if the borrower is past ninety days, the case goes to a person; if the product allows part payment, the message may mention it. Write these as a decision tree in the flow, where they are checked every time. Rules that can be written as conditions should be conditions.

Step 3: Draft the message

Now the model does the part it is good at: writing a polite, clear reminder in Marathi, Gujarati, Hindi or English, using only the facts from step 1 and the permissions from step 2. This prompt is short because the hard decisions have already been made.

Step 4: Check the draft

A second, separate check reads the draft against a list of things that must never appear: the guarantor, threats, legal language the compliance team has not approved, any amount that differs from the record. If the check fails, the draft goes to a person with the reason.

Step 5: Route for approval

The draft lands in the collections officer's queue. The officer reads it, edits if needed, and sends. The agent never sends on its own in this flow.

When compliance adds the guarantor rule, it goes in one obvious place: the check in step 4, and perhaps a line in step 3. Anyone on the team can find it.

Write instructions a colleague can read

Prompts are documents that people will maintain. Treat them that way.

• Say what the step is for in the first line. "Draft a payment reminder for one borrower using only the facts below."
• Use the same names everywhere. If the field is called amount_due in the data, call it amount due in the prompt, not outstanding, balance and dues in three places.
• Put rules in lists, one rule per line. A rule buried in a paragraph is easy to miss and hard to remove.
• Give one or two real examples. A good message and a message that broke a rule, with a note on why. Remove personal details from examples first.
• Avoid personality. "You are a world famous debt counsellor" adds nothing. State the tone you want in plain words: polite, brief, no pressure, no jargon.

Keep reusable pieces in one place

Several agents in the same company usually share instructions: the brand's tone, the list of languages, the rules about personal data, the sign off. Keep these as reusable logic blocks that every prompt draws on. When the sign off changes, you change it once.

The same applies to lookups. If three agents need the borrower record, build one block that fetches it and reuse it. On AksharAI this is what reusable logic blocks and prompt chaining are for, but the principle holds on any platform.

Test before you change anything

Every flow needs a small set of test cases that you run after each edit. For the collections agent that might be twenty borrower records, chosen to cover the awkward cases.

• A borrower with an open dispute (expect no message)
• One past ninety days (expect a hand off to a person)
• A product with part payment allowed, and one without
• A borrower who prefers Gujarati, one who prefers Marathi
• A record with a missing phone number

For each case, write down what a correct result looks like. After any change to a prompt or rule, run all twenty and compare. This takes minutes, and it catches the change that fixed one case and broke three others.

Also watch the token count. A flow that sends the whole loan history to the model for every reminder is slower and costs more than one that sends the six fields it needs. Trim inputs to what each step actually uses.

Version and log everything

Keep a short change note each time a prompt or rule changes: what changed, why, who approved it, and the test results. When a borrower complains about a message sent in March, you need to know which version of the flow wrote it. Logs of every input, draft, check result and approval should be kept for as long as your record keeping rules require, and access to them limited to the people who need it.

Limits to plan for

Splitting a flow into steps does not make the model perfect. The drafting step can still produce an awkward phrase in Marathi, or misread a field. The check step catches many errors but not all, which is why a person approves the message. Expect to adjust prompts regularly in the first few weeks as real cases show you gaps.

Small steps also add some delay, because each one is a separate call. For a reminder queue that is reviewed through the day, a few extra seconds do not matter. For a live chat, you may need to combine steps or run some in parallel.

Checklist

• Each step does one job and has a one line purpose
• Business rules written as conditions in the flow
• Prompts use the same field names as the data
• Shared instructions sit in reusable blocks
• Twenty or so test cases with expected results
• A change note for every edit, with test results
• A person approves anything that leaves the building

You can build and test a flow like this in the Logic and workflows builder, step by step, with your own test cases.