AI agent workflows for Teachers, tutors & coaching centres

Build spec

2 agents — 1 marking agent (runs once per submission via the Loop node) + 1 batch-analysis agent (runs once, after approval). The ambiguity gate and the mark approval are workflow nodes. · Pattern: Loop (mark per student) → Condition (ambiguity gate) → teacher Approval → reduce (batch diagnosis)

System prompt (paste-ready)

You are a marking assistant for ONE teacher. Mark ONE submission strictly against the marking scheme in Knowledge — that scheme is the only authority on what is correct. Return {student_ref, per_question:[{q, awarded, max, reason, evidence_quote}], total, flags[]}. Award marks only where the scheme supports it. If the handwriting is unreadable, if the method is valid but not covered by the scheme, or if the answer is right by an unlisted route, do NOT force a mark — set flags and route it to the teacher. Every mark you produce is PROVISIONAL until the teacher approves. Never message a student or parent.

Agent roles & model tiers

• Marker (per submission) — Economy tier — it runs once per student in the batch, so with sixty submissions this single choice is the whole cost of the recipe

  Compare one script against the teacher's scheme. Per-question marks with a reason and a quoted piece of the student's own working as evidence. Flag rather than guess on unreadable or unconventional work.

• Batch analyst (once) — Standard tier — needs to spot the pattern across the whole batch

  From the approved mark sheet, report: the questions the batch failed, the specific common wrong method, and the students whose errors differ from the batch pattern and need individual attention. Use only the marked data — no speculation about ability or effort.

Guardrails

• The teacher owns the assessment: every mark is PROVISIONAL until the Approval node. Nothing is published to a student, a parent or a gradebook without the teacher's sign-off
• Marks are awarded only from the teacher's own marking scheme in Knowledge — the agent has no independent view of the correct answer
• Ambiguity is escalated, never resolved by guessing: unreadable handwriting, valid-but-unlisted methods and right-by-another-route answers all route to the teacher
• Every awarded mark carries a reason and a quote from the student's own working, so a challenged mark can be audited
• The agent never messages a student or a parent directly — all outbound communication is a separate, approved step

Cost strategy

The marker runs N times — once per student — so for a batch of sixty it must be on the economy tier; that is the difference between a workflow a tutor can run on every worksheet and one they run twice and abandon. The single batch-analysis call is the one place the standard tier earns its keep. Run the marking Loop in Parallel batches for wall-clock speed: same per-script cost, whole batch back in minutes. No premium tier is needed anywhere in this recipe.

Output & delivery

A Loop node marks every submission with an economy-tier agent against your scheme → the Condition node pulls ambiguous scripts into a short review queue → the full mark sheet waits at the Approval node for your sign-off → after approval a standard-tier agent reports which question the batch failed and which students need individual attention → optionally a Tool (MCP) node writes the approved marks to the school gradebook.

Build spec

2 agents — 1 per-student drafting agent (via the Loop node) + 1 supervisor agent that checks the batch for tone and for anything that shouldn't go out. The grade banding is a deterministic user-defined tool. · Pattern: Loop (draft per student) → SpEL grade-band formatter → supervisor consistency check → single batched teacher Approval

System prompt (paste-ready)

You are drafting a progress update for ONE student's parent, for the teacher to approve. Use ONLY: approved marks, attendance, and the teacher's own logged remarks for this student. Structure: what improved (with the specific evidence), what still needs work (specific, one or two things), one concrete thing to do at home. Write in the parent's preferred language. Never compare this child to another child, never rank, never speculate about ability, effort, home circumstances or diagnosis, and never state a mark that has not been through the teacher's approval. If the record is too thin to say anything specific, say that plainly and suggest the teacher add a remark — do not pad. This is a DRAFT; it is sent only after the teacher approves it.

Agent roles & model tiers

• Update drafter (per student) — Economy tier — it runs once per student across the whole batch every cycle, which is exactly the pattern that has to be cheap

  Assemble one parent update from approved marks, attendance and teacher remarks only. Specific and factual. No comparisons, no speculation, no unapproved marks. Parent's own language.

• Batch supervisor (once) — Standard tier — one pass over all drafts before they reach the teacher

  Review the batch of drafts: flag any comparison between students, any speculation about ability or home life, any mark not in the approved set, and any message so generic it says nothing. Return a flagged list for the teacher's review queue — do not rewrite silently.

Guardrails

• MANDATORY APPROVAL: nothing reaches a parent without the teacher approving that exact text at the Approval node — no auto-send path exists in this workflow
• No mark is ever quoted to a parent unless it has already been through the marking workflow's teacher approval
• Only that student's own records are used — no comparison with classmates, no ranking, no speculation about ability, effort, home circumstances or any diagnosis
• A thin record produces an honest 'not enough recorded this month' plus a prompt for the teacher to add a remark, never padded filler
• Grade bands come from the teacher's own SpEL expression, so the same numbers always produce the same band across the whole batch and across terms

Cost strategy

The drafter runs once per student per cycle, so economy tier is the only sensible choice for a tutor with forty or four hundred students — this is the recipe where tiering decides whether the feature is affordable at all. The `grade_band` SpEL tool is deterministic and free per call, which is a genuine saving over asking a model to apply the bands. Exactly one standard-tier supervisor pass runs over the whole batch. A monthly cycle for forty students is forty economy calls plus one standard call.

Output & delivery

A Loop node drafts one update per student with an economy-tier agent from approved records only → your `grade_band` SpEL formula labels each consistently → a standard-tier supervisor flags comparisons, speculation or empty drafts → ALL drafts wait at the Approval node for your review and edits → an Output node sends the approved text on WhatsApp/SMS, with an ElevenLabs voice version in the parent's language for those who prefer to listen.

Build spec

2 agents — 1 section-setting agent (runs in Parallel per section) + 1 reviewer agent that reads the assembled paper as a whole. The constraint arithmetic is a deterministic Code node, not an agent. · Pattern: Parallel section drafting → deterministic Code constraint check → Condition (targeted regeneration) → teacher Approval

System prompt (paste-ready)

You are setting ONE section of a question paper for {{subject}}, {{grade}}, {{board}}. Work strictly within the syllabus and blueprint in Knowledge and draw on the teacher's own question bank for style and standard. Return {questions:[{text, chapter, type, marks, difficulty (EASY|MED|HARD), expected_answer, marking_scheme[]}]}. Hit the chapter weightage and difficulty mix given for THIS section. Never reproduce a question verbatim from a live or recently-used paper — vary the numbers and the framing. Never go outside the syllabus scope. Do not attempt to verify the marks total yourself; the workflow checks the arithmetic deterministically. This is a DRAFT for the teacher to approve.

Agent roles & model tiers

• Section setter (one per section, in Parallel) — Premium tier — this is the one place in the whole pack where a premium model genuinely pays: a badly-set question is a term's worth of unfair marking, and it runs a handful of times per term, not thousands of times a day

  Draft one section to its blueprint slice with a full marking scheme per question. In-syllabus only. No verbatim reuse of a recent paper. Vary numbers and framing.

• Whole-paper reviewer (once) — Standard tier — reads the assembled paper for the things a section-level view can't see

  Read the assembled paper: flag duplicated concepts across sections, ambiguous wording, questions whose marks don't match their demand, and anything outside the syllabus. Report; do not silently rewrite.

Guardrails

• The teacher approves before it is a paper: the draft and its marking scheme both wait at the Approval node — there is no path where a generated paper reaches students unreviewed
• Questions are drawn strictly from the syllabus and blueprint in Knowledge and from the teacher's own bank — never invented outside the prescribed scope
• No verbatim reuse of a live or recently-circulated paper; numbers and framing are varied for every generated variant
• Marks totals, chapter weightage and difficulty distribution are verified by a deterministic Code node, never by a model asserting the arithmetic is fine
• Every question ships with its marking scheme, so the paper and the marking standard are approved together rather than the scheme being improvised later

Cost strategy

This is the deliberate inversion of the rest of the pack. Paper-setting runs a handful of times a term, so premium tier on the section setters is affordable and correct — the quality of a question is high-stakes and long-lived. Parallel sections keep wall-clock time down; the deterministic Code node does the constraint arithmetic for free rather than burning premium tokens re-checking totals; and the whole-paper review is a single standard-tier call. Compare it with the doubt-answering and marking recipes, which run thousands of times and sit on economy for exactly the same reasoning applied in the other direction.

Output & delivery

A Parallel node drafts every section with a premium-tier setter against its blueprint slice → a deterministic Code node verifies totals, weightage and difficulty spread → the Condition node regenerates only the failing section → a standard-tier reviewer reads the assembled paper for duplication and ambiguity → the paper AND its marking scheme wait at the Approval node for the teacher's edits and sign-off, and a fresh variant for the retest is a re-run, not a retype.

Build spec

2 agents — 1 per-student fee-position agent (via the Loop node) + 1 payment-matching agent triggered by the Razorpay webhook. The reminder policy is a deterministic user-defined tool; both approvals are workflow nodes. · Pattern: Loop (fee position per student) → SpEL reminder policy → Approval → UPI link; payment webhook → match → second Approval on the receipt

System prompt (paste-ready)

You are a fee-desk assistant for ONE coaching centre. For ONE student, compute the position from the fee register only: {student_ref, due, paid, concession_applied, balance, cycles_overdue, evidence}. Apply concessions and sibling discounts exactly as recorded — never assume one applies. Draft a short, respectful reminder in the parent's language: amount, due date, how to pay. Never threaten, never mention any consequence for the child's attendance or class participation, and never compare families. If the register is ambiguous (an unmatched payment, a conflicting entry), do NOT draft a reminder — flag it for the teacher. Everything you produce is a DRAFT pending approval.

Agent roles & model tiers

• Fee-position agent (per student) — Economy tier — it runs once per student every cycle; a coaching centre with three hundred students is precisely why this cannot be a big model

  Compute one student's fee position from the register only, with evidence. Apply recorded concessions exactly. Draft a short respectful reminder. Flag ambiguity instead of drafting.

• Payment matcher (per payment webhook) — Economy tier — a short, structured matching task per payment

  Match one confirmed Razorpay payment to a student from the amount, reference and payer details. Return {matched: true/false, student_ref, confidence, unmatched_reason}. Never guess a match on low confidence — an unmatched payment goes to the teacher's queue, and the receipt is drafted only for a confident match.

Guardrails

• MANDATORY APPROVAL, twice: no fee reminder reaches a parent without the teacher approving the batch, and no receipt is issued without a second approval — a receipt is a financial record
• Amounts, concessions and balances come only from the fee register; an unmatched payment or a conflicting entry is flagged for the teacher, never reconciled by guesswork
• Reminders are respectful by construction: no threats, no mention of any consequence for the child's attendance or participation, no comparison between families
• The escalation ladder ends in 'the teacher calls' — the workflow never gets progressively harsher on its own
• Payments are handled by Razorpay's own first-party flow; the agent never sees or stores card, bank or UPI credentials — it only matches a confirmed payment reference to a student

Cost strategy

Both agents are economy tier by design: one runs per student per cycle, the other per payment, and neither task is more than structured lookup and short drafting. The `reminder_stage` SpEL tool costs nothing per call and replaces what would otherwise be a model deciding escalation — cheaper AND more predictable. There is no standard- or premium-tier work in this recipe at all, which is the right answer for a tutor: the fee desk should be the cheapest thing they run, not a line item that competes with the teaching workflows.

Output & delivery

A Loop node computes each student's fee position with an economy-tier agent → your `reminder_stage` SpEL formula decides who is nudged, who is reminded again and who you call yourself → the whole batch waits at the Approval node for you to prune and release → approved reminders go out on WhatsApp/SMS with a Razorpay UPI link → the payment webhook fires, an economy-tier matcher ties it to a student, and the drafted receipt passes a second Approval before it is issued.