AI agent workflows for Freelancers & solo consultants

Build spec

1 agent — 1 estimating agent. The completeness gate, the rate maths (user-defined SpEL tool) and the price approval are workflow nodes — not extra agents. · Pattern: Extract → completeness gate → grounded pricing → human approves → send

System prompt (paste-ready)

You are the quoting assistant for {{freelancer}}, an independent {{discipline}}. From an incoming enquiry, extract {deliverable, scope_summary, quantity, estimated_hours, deadline, rush (true|false), channel}. If scope or deadline is missing, do NOT price: return {complete: false, missing[], one_question} so the workflow asks a single clarification. When complete, look up the applicable rate and package terms in Knowledge, call the user-defined tool quote_total for the amount, and draft an itemised quote {line_items[{desc, qty, rate, amount}], total, validity_days, payment_terms, next_step}. NEVER invent a rate, a discount, a turnaround or an availability date — if it is not in Knowledge, say it needs confirmation. This is always a DRAFT for {{freelancer}} to approve; never phrase it as a confirmed price.

Agent roles & model tiers

• Brief reader / estimator (once per enquiry) — Standard tier — it has to understand a messy, half-written brief

  Turn an unstructured enquiry into a structured job spec, flag anything missing rather than guessing it, and assemble an itemised draft quote using only Knowledge rates and the quote_total tool's returned amount.

Guardrails

• The agent proposes; it never sends. Every price passes the Approval node on your phone before the client sees a number.
• Prices, discounts, turnarounds and availability come only from your Knowledge and the quote_total formula — the model is explicitly barred from inventing any of them; unknown terms come back as 'needs confirmation'.
• The completeness gate blocks pricing on a half-written brief: one clear question goes out instead of a wrong number that you then have to walk back.
• The arithmetic is deterministic — the amount is whatever the SpEL expression returns, so the same inputs always produce the same total and you can audit it by reading one line.

Cost strategy

One standard-tier call per enquiry. There is no batch, so there is no multiplier to manage — but put the completeness check on the economy tier and let only genuinely complete briefs reach the standard-tier pricing pass, because clarification replies are the majority of early traffic and they do not need the bigger model. Set a fallback model so a provider hiccup at 11pm degrades to a slower answer instead of a silent miss, and remember the arithmetic costs nothing at all: it runs in the SpEL tool, not in tokens.

Output & delivery

The agent extracts the spec → the Condition node gates completeness → Knowledge supplies your rates → the `quote_total` SpEL tool computes the amount → you approve or edit at the Approval node → an Output node sends the itemised quote on the original channel, and a Tool (MCP) node files it against the client in your invoicing app.

Build spec

1 agent — 1 drafting agent, invoked once per rung of the ladder. The reply check, the ladder itself and the commercial gate are workflow nodes. · Pattern: Event-started ladder: Loop over a fixed schedule, exits on reply, gated on commercial change

System prompt (paste-ready)

You write follow-ups for {{freelancer}} on an outstanding quote. Given {quote_summary, sent_on, days_elapsed, last_client_message, rung (1|2|3)}, write ONE short message appropriate to that rung: rung 1 a light check-in, rung 2 a specific question that makes replying easy, rung 3 a graceful close that leaves the door open. Reference the actual quote and the client's own last words — never repeat a previous rung's wording. NEVER offer a discount, extend validity, change scope or invent a new deadline: if the situation seems to call for one, return {needs_owner: true, reason} and stop. Keep it under 60 words and sound like a person, not a sequence.

Agent roles & model tiers

• Follow-up writer (once per rung) — Economy tier — short, formulaic drafting; the volume here is rungs × open quotes

  Write one short, rung-appropriate, context-aware nudge referencing the real quote and the client's last message. Escalate to the owner instead of ever offering commercial concessions.

Guardrails

• Hard stop conditions: the ladder is finite (three rungs) and exits immediately on any client reply or on the quote being marked accepted/lost — it can never become a drip campaign.
• The agent may never offer a discount, extend validity or change scope; any such need returns needs_owner and lands in your Approval queue as a decision, not a draft that slipped out.
• Quote status is re-checked via the MCP tool immediately before each send, so a client who paid or declined out-of-band is never chased.
• One touch per rung per quote, keyed to the quote id — a re-run or a duplicate webhook cannot double-message a client.

Cost strategy

This is the one recipe with a real multiplier: rungs × open quotes. That makes the model choice the entire cost story — put the drafting agent on the economy tier, cap its output length, and it stays negligible even with a full pipeline. Nothing here needs reasoning; it needs brevity and context. Add a fallback model so a failed provider call retries rather than silently skipping a rung.

Output & delivery

Each rung: the Condition node re-checks for a reply and the MCP tool re-checks quote status → the economy-tier agent drafts one contextual nudge → a plain nudge sends, anything commercial diverts to your Approval queue → an Output node delivers on the original channel and logs the touch against the quote.

Build spec

1 agent — 1 reminder-drafting agent. The paid-check, the UPI link, the ageing branch and the escalation gate are workflow nodes. · Pattern: Due-date trigger → live balance re-check → grounded draft + UPI link → ageing branch → owner approves escalations

System prompt (paste-ready)

You draft payment reminders for {{freelancer}}. Given {client, invoice_no, amount_due, currency, due_date, days_overdue, relationship_length, prior_reminders}, write ONE short reminder whose tone matches the ageing: recently due is a friendly nudge that assumes it was missed, long overdue is direct but never threatening. State the invoice number and exact outstanding amount as given — never recalculate, never round, never add a fee. Reference the attached payment link as the easiest way to settle. You may NOT threaten legal action, announce a late fee, stop work, offer a payment plan or promise a refund: if any of those seem warranted, return {escalate: true, recommendation, reason} and write nothing. Terms come only from the payment terms in Knowledge.

Agent roles & model tiers

• Reminder writer (once per due invoice) — Economy tier — short, high-frequency, tone-matched drafting

  Write one short reminder toned to the ageing, quoting the invoice number and exact amount verbatim, pointing at the payment link. Escalate rather than ever inventing a fee, a plan or a threat.

Guardrails

• Live balance is re-read via the MCP tool immediately before drafting — an invoice settled out-of-band is never chased.
• Amounts and invoice numbers are quoted verbatim from the accounting app; the agent is barred from recalculating, rounding, or adding any charge.
• Late fees, work-stop notices, payment plans, legal language and refunds are all impossible for the agent to send — they return escalate:true and wait for your Approval. Refunds in particular never leave the approval queue on their own.
• One reminder per invoice per rung, keyed to invoice id, so a duplicate webhook from the accounting app cannot double-chase a client.
• The payment link is generated for the exact outstanding amount from the accounting record — the agent does not supply the figure.

Cost strategy

Volume equals your open invoices, which for a solo practice is small and predictable. Economy tier is correct here — this is short tone-matched drafting, not reasoning. The genuinely valuable spend is elsewhere: the MCP balance re-check before every send costs nothing in tokens and prevents the one failure mode (chasing a paid invoice) that would make you switch the whole thing off.

Output & delivery

Webhook fires on due date → MCP tool confirms the balance is really outstanding → the economy-tier agent drafts a tone-matched reminder → a Razorpay UPI link for the exact amount is attached → the Condition node bands the ageing → routine reminders send on WhatsApp/Email while fees, plans, work-stops and refunds queue for your Approval → the touch is logged against the invoice.

Build spec

1 agent — 1 classifier agent per message, plus an optional once-a-day digest pass reusing the same agent. The prioritisation is a SpEL tool, not an agent. · Pattern: Fan-in from many channels → classify → deterministic priority rule → route → daily digest

System prompt (paste-ready)

You triage inbound messages for {{freelancer}}, an independent {{discipline}}. Classify ONE message into strict JSON {type (NEW_ENQUIRY|EXISTING_CLIENT|SUPPLIER|RECRUITER|SPAM), summary (max 2 lines), stated_budget (number|null), timeline (string|null), asks[], channel}. Extract budget ONLY if the sender stated one — never estimate or infer a figure, use null. Do not reply to the sender, do not quote a price, do not promise availability or a delivery date, and do not accept work. Your output is a triage record for {{freelancer}} to act on.

Agent roles & model tiers

• Message classifier (once per inbound message) — Economy tier — this is the highest-volume, lowest-judgement step in the whole pack; its model choice dominates total spend

  Classify and two-line-summarise one message into strict JSON. null for anything not explicitly stated. Never reply, never price, never commit.

• Digest writer (once a day) — Standard tier — one call, ranks and narrates the day's queue

  Given the day's triage records, produce one ranked digest: HOT first with the specific next action, then WARM, then a one-line count of everything filtered. Use only the records provided.

Guardrails

• The triage agent never replies with anything substantive — the acknowledgement is a fixed Output node that promises nothing about price, availability or delivery.
• Budget is recorded only when the sender stated it; the agent may not infer a figure, because an inferred budget silently changes your priority rule's answer.
• Prioritisation is a deterministic SpEL expression, not a model judgement — same inputs, same band, every time, and auditable by reading one line.
• Existing-client messages are routed, never auto-answered, so a support question from a paying client always reaches you.
• Spam is dropped silently rather than replied to, so an automated acknowledgement never confirms your number is live.

Cost strategy

This is your highest-volume workflow, so it is also the one where model tier matters most: every inbound message hits the classifier. Economy tier with a hard output cap, and a fallback model for provider blips, keeps a busy week from becoming a surprise bill. The one standard-tier call per day is the digest — that is the right place for the reasoning budget, because it runs once regardless of how noisy the day was.

Output & delivery

Five channels fan into one workflow → the economy-tier classifier emits a strict-JSON triage record → the `lead_priority` SpEL tool bands it against your own thresholds → the Condition node alerts you on HOT, queues WARM, routes existing clients to support and drops spam → a fixed, non-committal acknowledgement goes out → a single standard-tier digest lands once a day on Slack or Email.