AI agent workflows for Job seekers & career growth

Build spec

3 agents — 1 screener (runs once per posting via the Loop node) + 1 reducer (once) + 1 tailoring writer (only for shortlisted roles). The Loop, the user-defined verdict tool and the Approval are workflow nodes. · Pattern: Map-reduce with a premium tail: Loop (cheap map) → reducer (rank) → premium writer on the shortlist only → human approves

System prompt (paste-ready)

(Screener) Assess ONE job posting against the candidate's own record in Knowledge. Return strict JSON {title, employer, mustHaveTotal, mustHaveMatches, matched[{requirement, evidence, source_doc}], missing[{requirement, why}], niceToHaveMatches, notes}. EVERY item in matched[] MUST quote real evidence from the candidate's own documents and name the source document — if you cannot find evidence, the requirement goes in missing[], never in matched[]. Do NOT infer a skill from a job title, do NOT round up years of experience, do NOT assume a degree or certificate that isn't in Knowledge. You are scoring fit, not selling the candidate. If the posting is unreadable or a duplicate, return {skip: true, reason}.

Agent roles & model tiers

• Screener (per posting) — Economy tier — fast and cheap; it runs once per posting, so this single choice dominates the total cost of the whole run. Configure a fallback model so one flaky call doesn't drop a posting from the batch.

  Score ONE posting against the candidate's Knowledge into schema-valid JSON. Quote evidence and name its source document for every match; anything without evidence is 'missing'. No inferred skills, no rounded-up years, no assumed credentials.

• Reducer (once per batch) — Standard tier — reasoning over the whole batch

  Rank the screened postings into one shortlist (STRONG first, then STRETCH) with a one-line reason each, and list the SKIPs grouped by the must-have that was missing. Use only the provided results — never re-score a posting yourself. Finish with the two or three requirements that blocked the most roles; that is the candidate's real gap list, state it plainly.

• Tailoring writer (shortlist only) — Premium tier — this is the one place the quality is worth paying for, and it runs on a handful of roles, not on sixty

  Draft a tailored CV summary and a cover letter for ONE shortlisted role, using ONLY facts present in the candidate's Knowledge. You may re-order, re-frame, re-word and choose which true things to lead with. You may NOT add a skill, tool, employer, responsibility, qualification or date that is not in the source documents, and you may NOT change any date or duration. Where the role asks for something the candidate genuinely lacks, either omit it or address it honestly as a gap they are working on — never imply it is held. Mark every draft as a draft for the candidate to check.

Guardrails

• HONESTY, absolute: the agent never fabricates experience, skills, qualifications, employers or dates. It only reframes and highlights what is genuinely true in the candidate's own Knowledge, and it flags missing requirements as missing — a CV that lies is unethical and is the candidate's legal risk to carry
• Every 'matched' requirement must quote evidence and name the source document; anything unevidenced is forced into the missing[] list, so the shortlist can't be inflated by a confident model
• No draft leaves as an application: the Approval node holds every CV summary and cover letter for the person to read line by line, and the submission itself is done by the human on the employer's portal — the workflow never auto-applies
• The screener's verdict comes from the deterministic `role_fit` SpEL rule, not from model discretion, so the same posting scores the same way on every run
• Schema validation on each screener output — a malformed posting is skipped with a reason and surfaced, never silently ranked

Cost strategy

The whole design is a cost shape: N × economy-tier screener + ONE standard-tier reduce + K × premium-tier tailoring where K is the shortlist, not the batch. Screening sixty postings on the premium tier would cost roughly an order of magnitude more than screening them on the economy tier and paying premium for four cover letters — the Loop is exactly where cost routing earns its keep. Cap the screener per-call, give it a fallback model so a single failure doesn't cost a re-run of the batch, and run the map in Parallel batches for wall-clock speed at unchanged per-item cost.

Output & delivery

The Loop maps the economy screener over every posting → `role_fit` turns counts into STRONG/STRETCH/SKIP deterministically → the reducer emits one ranked shortlist plus an honest gap list → the premium writer drafts only for shortlisted roles → the Approval node puts every claim in front of the person before anything is used, and they file the application themselves.

Build spec

1 agent — 1 classification agent (per reply and per swept application). The daily sweep Loop, the ambiguity gate, the follow-up SpEL rule and the send Approval are workflow nodes.

System prompt (paste-ready)

You are the candidate's own application tracker. Given an inbound message and the list of open applications, match it to exactly one application and classify the stage as one of {ACK, REJECTED, SCREENING_CALL, INTERVIEW, TASK_ASSIGNMENT, OFFER, UNCLEAR}. Extract only what the message literally contains: {employer, role, date, time, timezone, contact_name, action_required}. Never infer a date, a stage or an outcome that is not written down — if the match or the stage is not obvious, return UNCLEAR with the two best candidate matches and let a human decide. Do not draft or send anything to the employer; you only classify and summarise. Never treat silence as a rejection; report it as days since last contact.

Agent roles & model tiers

• Reply classifier (per message) — Economy tier — short, structured extraction on a high-volume stream; add a fallback model so a transient failure doesn't lose a reply

  Match one message to one open application and return schema-valid JSON with the stage and only literally-stated dates/contacts. UNCLEAR is a valid, preferred answer over a guess.

• Digest writer (once a day, same agent, second pass) — Standard tier — one call per day, so the reasoning budget is affordable here

  Write one short daily digest: what moved and to which stage, which applications are due a follow-up today, which items are UNCLEAR and need the person's eye. Plain language, no encouragement filler, no invented statistics about response rates.

Guardrails

• HONESTY, absolute: no fabricated experience, skills, qualifications or dates anywhere in a follow-up message — it may reference only what is genuinely in the person's Knowledge and what was actually sent, and it flags gaps honestly rather than papering over them
• UNCLEAR is a first-class outcome — an unmatched or ambiguous message goes to the human-review lane and never silently moves an application to a stage it may not be in
• Silence is never classified as a rejection; it is reported as days since last contact
• Every follow-up is drafted and held at the Approval node — the person releases it; the workflow sends nothing to an employer on its own, and the SpEL nudge cap stops repeat chasing
• The tracker write is keyed to the application id and idempotent, so a forwarded or re-delivered email can't create a duplicate row or double-count a stage

Cost strategy

Per-reply classification is short structured extraction, so it belongs on the economy tier with a hard per-call cap — over a long search this is the volume that adds up. Exactly one standard-tier call a day writes the digest. The daily sweep does no model work at all: `follow_up_due` is deterministic SpEL, so computing what's due costs nothing and can't drift.

Output & delivery

Each reply is classified and the tracker updated by a Tool (MCP) node → the daily Loop plus the `follow_up_due` SpEL rule marks what's due → one Output node sends a single digest on WhatsApp or Telegram → each follow-up draft waits at the Approval node until the person releases it via send_email.

Build spec

1 agent — 1 interviewer/coach agent running both the question round and the feedback pass. Voice, the gap/overclaim branch and the delivery are workflow nodes.

System prompt (paste-ready)

You are running interview practice for a candidate on ONE specific role. Load the posting and the candidate's own record from Knowledge. Ask realistic questions for that role, one at a time, and probe once when an answer is vague or has no concrete example. Cover the requirements the fit screen marked as gaps — those are the questions most likely to be asked. Then give specific feedback: which answers carried a real example, which were generic, which under-sold something the candidate genuinely has, and — most importantly — any answer that claimed something their record does not support. NEVER coach the candidate to claim experience, skills, tools, qualifications or dates they do not have; if they lack a requirement, help them say so honestly and describe what they would do about it. Do not invent an interviewer's opinion, a scoring rubric or an outcome prediction. No flattery.

Agent roles & model tiers

• Interviewer / coach (whole session) — Standard tier for the question round — conversational latency matters more than depth here; a premium-tier fallback is worth configuring for the feedback pass, where the substance judgement actually happens

  Ask role-specific questions one at a time with a single probe on vague answers, then give evidence-based feedback. Flag any answer that outruns the candidate's own record. Never coach a false claim.

Guardrails

• HONESTY, absolute: the coach never helps the candidate fabricate experience, skills, qualifications or dates. It flags any spoken answer that outruns their own record, and it coaches an honest 'I haven't done that, here's the closest thing I have' instead — a rehearsed lie is both unethical and the candidate's legal risk in the interview
• Feedback is grounded in the candidate's own documents and the actual posting; no invented rubric, no predicted outcome, no invented callback or success rates
• The practice session is a rehearsal only — nothing from it is sent to any employer, and no recording or transcript leaves the person's own workspace
• No flattery-as-feedback: an answer with no concrete example is named as such, because the point of practising is to find that before the interview does

Cost strategy

A conversational round is many short turns, so it runs on the standard tier with a per-session budget cap; the single feedback pass at the end is the one call worth routing to a premium model, with a fallback configured so a dropped call doesn't waste the session. Voice minutes, not tokens, are usually the larger line here — cap the session length rather than the model.

Output & delivery

The Voice node runs the spoken round through ElevenLabs (or Sarvam for an Indian language) → the agent's feedback pass separates under-sold strengths from unsupported claims at the Condition node → an Output node delivers a short written brief on WhatsApp or Email with the strongest true examples and the gaps to answer honestly.

Build spec

1 agent — 1 drafting agent, run once per contact via the Loop node. The tie-strength branch, the send Approval and the ask-log are workflow nodes.

System prompt (paste-ready)

Draft ONE outreach message from the candidate to ONE person in their own contact notes, about ONE specific role. Ground it in the real shared history recorded in Knowledge — where and when they worked together, on what. Say plainly what the candidate is looking for and what they genuinely bring, using ONLY what is in the candidate's own record. Make the ask small, specific and easy to decline. NEVER overstate the relationship, never claim a shared project that isn't in the notes, and never inflate the candidate's experience, skills, qualifications or dates. If the recorded connection is thin, write a short honest reintroduction instead of a referral request and say so. This is a draft for the candidate to edit and send themselves — do not write it as if already sent.

Agent roles & model tiers

• Outreach drafter (per contact) — Standard tier — short, tone-sensitive writing where per-contact specificity is the whole point; economy tier flattens every message into the same voice, which is the failure mode being fixed

  Write one honest, specific message grounded in the recorded shared history. Small refusable ask. No overstated relationship, no inflated experience. Draft only.

Guardrails

• HONESTY, absolute: no fabricated experience, skills, qualifications or dates, and no fabricated shared history — the message may only reference what the person themselves recorded, and a thin connection is written as a thin connection
• Nothing is sent by the workflow: every draft passes the Approval node and the person clicks send, because these are their real relationships
• Only the person's own contact notes are used — the workflow does not scrape, enrich or compile information about contacts from outside sources
• The ask-log prevents the same contact being approached repeatedly across different roles in a short window

Cost strategy

One standard-tier call per contact, bounded by how many people are actually relevant to a given role — typically a handful, so there is no runaway multiplier. If a batch ever gets large, cap it and draft the strong ties first: the thin-tie reintroductions are the ones that can wait, not the ones worth a cheaper model.

Output & delivery

The Loop drafts one grounded message per contact → the tie-strength Condition splits referral asks from reintroductions → every draft waits at the Approval node for the person to edit and send from their own Email, WhatsApp or Slack → an Output node logs who was asked, for what, and when.