Discover the Real Workflow

In plain words

Your college placement process looks neat on the notice board, but the real work happens in WhatsApp groups and a coordinator's private Excel sheet. Building software from the neat version fails. So before designing an agent, go and reconstruct the actual steps people follow, and mark for each step whether you observed it, read it in a record, were told it, or simply guessed it.

How it flows

A tiny example

steps = []
for s in observe_the_work():
    steps.append({
        "actor": s.actor,
        "action": s.action,
        "kind": evidence_kind(s),  # direct, artifact, reported, inference
    })
strong = [s for s in steps if s["kind"] in ("direct", "artifact")]
print(len(strong) / len(steps))

Notice that every step carries a 'kind' field, so a guess can never quietly pass as an observed fact.

What you will learn

• Why you should study the work people actually do before building an agent for it.
• How to write down a workflow as steps, with actor, trigger, friction and evidence.
• How to rank your evidence so a guess never gets treated as a fact.
• Where agents usually break: handoffs, hidden state, approvals and exceptions.

The problem, simply

Think about your college placement cell. On paper the process is clean: company sends a mail, the cell posts a notice, students register on the portal, the cell shares the shortlist.

Now think about what really happens. The notice also goes on a WhatsApp group. Sneha maintains a personal Excel sheet because the portal cannot handle re-registrations. Rahul messages the coordinator directly when his name is missing. One senior manually merges two lists at 1 AM before the drive.

If you build an "AI placement assistant" from the notice board version, it will work for the demo and collapse in the first real drive. All the pain was in the parts nobody wrote down.

Same thing happens in companies. Requirements are not sitting in a meeting room waiting to be collected. They are spread across actions, workarounds, records and disagreements. Your job is to go and reconstruct them.

The idea

Start from what happens now, not from what people want

The natural first question is "what feature do you want?" Resist it. Ask instead: show me exactly what you did last Tuesday when this happened.

For each step of the current workflow, write down seven things:

• Actor — who does it. "Support engineer on night shift."
• Trigger — what starts it. "A refund complaint lands in the queue."
• Action — what they actually do. "Opens the ticket, then searches two dashboards."
• Input — what they need. "Order ID and the UPI payment record."
• Output — what comes out. "Refund decision and the team that owns it."
• Friction — what hurts. "Switching between three tools every time."
• Authority — who is allowed to approve. "Team lead signs off any refund above ₹5000."
• Evidence — how you know. "Screen recording, the ticket log."

IMPRemember: the workflow is bigger than the screen. It includes waiting, copy-paste, WhatsApp side chats, approvals, error recovery, and the steps people stopped noticing years ago.

Not all evidence is equal

Here is the trick that saves you later. Every claim you write down should carry a label saying how strongly you know it.

Use four levels, strongest first:

1. Direct behaviour — you observed it, or a system log or trace shows it.
2. Artifact — a ticket, a form, a runbook, a finished output file.
3. Reported behaviour — a person told you what they usually do.
4. Inference — your team concluded that this probably happens.

All four are useful. Only the first two actually prove current behaviour. The other two are still guesses wearing a shirt and tie. Label them, and your confidence stops quietly inflating over three months.

Tip

Tip: Track your direct-evidence ratio — how many steps are backed by levels 1 and 2. If it is 2 out of 12, you have a story, not a workflow.

Look hard at four places

• Friction — repeated effort, waiting, re-typing the same thing, recovering from a mistake.
• Hidden state — facts that live in someone's head, a WhatsApp thread, or a personal notes file.
• Authority — the one person or system allowed to make a change that actually matters.
• Exceptions — the case where the normal flow stops being normal.

AI features usually fail exactly at handoffs and exceptions, because only the happy path was ever designed.

Do not average away disagreement

Suppose Priya and Karthik both process vendor invoices. Priya checks the GST number first, then the amount. Karthik does the reverse and skips the GST check for repeat vendors.

Your instinct is to write one "standard" flow. Do not. Keep both variants until you know why they differ: different roles, different risk levels, old process versus new process, an expert taking a safe shortcut, or a real policy disagreement.

An averaged workflow describes nobody. Build an agent for it and both Priya and Karthik will say "this is not how we work."

Build it

This small program stores workflow steps with evidence, checks the ordering, and prints a report with the direct-evidence ratio.

# workflow_evidence.py - model a real workflow with evidence strength
STRENGTH = {"direct": 1, "artifact": 2, "reported": 3, "inference": 4}
DIRECT = {"direct", "artifact"}  # only these prove current behaviour

def step(order, actor, action, friction, evidence, kind):
    """One workflow step. 'kind' says how strongly we know it."""
    if kind not in STRENGTH:
        raise ValueError("unknown evidence kind: " + kind)
    return {"order": order, "actor": actor, "action": action,
            "friction": friction, "evidence": evidence, "kind": kind}

def check_order(steps):
    """Orders must start at 1 and have no gaps or repeats."""
    seen = sorted(s["order"] for s in steps)
    return seen == list(range(1, len(steps) + 1))

def direct_ratio(steps):
    strong = sum(1 for s in steps if s["kind"] in DIRECT)
    return strong / len(steps)

workflow = [
    step(1, "Student", "Sees drive notice on portal", "Also posted on WhatsApp",
         "screenshot of portal", "artifact"),
    step(2, "Student", "Registers for the drive", "Form times out at peak",
         "server log of failed posts", "direct"),
    step(3, "Coordinator", "Merges portal list with own Excel sheet",
         "Manual, done late at night", "she told me in the interview", "reported"),
    step(4, "Team lead", "Approves the final shortlist", "Single approver, blocks everyone",
         "we assume this is policy", "inference"),
    step(5, "Coordinator", "Mails shortlist to company", "Copy-paste of 200 names",
         "copy of the sent mail", "artifact"),
]

if not check_order(workflow):
    raise SystemExit("step order is broken")

print("STEP  KIND        ACTOR         FRICTION")
for s in sorted(workflow, key=lambda x: x["order"]):
    print("%-5d %-11s %-13s %s" % (s["order"], s["kind"], s["actor"], s["friction"]))

print("\nSteps: %d" % len(workflow))
print("Direct-evidence ratio: %.2f" % direct_ratio(workflow))

weak = [s["order"] for s in workflow if s["kind"] not in DIRECT]
print("Steps still needing proof: %s" % weak)

Look at the last two lines of the output. The ratio is 0.60, which means 40% of this workflow is still someone's memory or your guess. The weak list tells you exactly which steps to go and observe before you promise anything to a client.

Where you will see this

• A support team asking for an AI bot, where the real work is three agents copying order IDs between two dashboards.
• Coding agents like Claude Code or Cursor, which only feel useful once they match how a developer actually reads, edits and reruns tests.
• Swiggy or Zomato style order-issue assistants, where the exception cases (partial delivery, wrong item) are the whole job.
• A bank or fintech refund flow, where the approval limit is the real design constraint, not the chat interface.
• Internal HR and IT helpdesk agents, where half the knowledge lives in old email threads nobody indexed.

Common mistakes

• Asking for features instead of watching the work. People describe the process they think they follow, and leave out the workarounds that are the actual problem.
• Treating an interview as proof. What a person reports is level 3 evidence. Build on it if you must, but mark it, or in month three everyone will believe it was observed.
• Designing only the happy path. Handoffs and exceptions are where agents break, and they are also where most of the human effort goes.
• Merging two users into one "average" flow. You lose the role, risk and policy differences that made the flows different, and the result fits neither person.
• Ignoring hidden state. If a step depends on something in a coordinator's head or a WhatsApp group, your agent has no way to read it, and it will silently produce wrong output.

If they ask in an interview

Q: How do you gather requirements for an AI feature?

A: I do not start with a feature list. I reconstruct the current workflow step by step, recording actor, trigger, action, friction, authority and evidence for each step. Then I look specifically at handoffs, hidden state, approvals and exceptions, because that is where an agent usually fails.

Q: A user tells you the process works in five steps. Do you believe them?

A: I write it down, but I mark it as reported behaviour, not observed. Then I try to confirm it with a log, a ticket or a screen recording. Usually the real flow has extra waiting, copy-paste and side-channel steps the person stopped noticing.

Q: Two users do the same task differently. What do you do?

A: I keep both variants instead of averaging them. Then I find out whether the difference is role, risk level, old versus new process, expertise, or a genuine policy disagreement. An averaged workflow often describes nobody and misleads the design.

Try these

• Take one process in your college — assignment submission, hostel leave, library issue — and write out every step with actor, trigger, friction and evidence. Aim for at least eight steps.
• Reconstruct one workflow purely from records, without talking to anyone. Use chat history, mails or form submissions. Note what you could not learn this way.
• Now interview one person who does that work. Mark every new claim as reported, and list which ones you could still verify with a record.
• Extend the program above with an exception branch — say the payment record is missing — keeping the main order intact and noting where the branch starts.

Words, simply

Quick recap

• Build the picture of what happens now before you design what should happen; the workarounds are the requirement.
• Label every claim by evidence strength, and keep the weak ones visible instead of promoting them to facts.
• Friction, hidden state, authority and exceptions are where agents fail, and disagreement between users is data, not noise.