Skip to main content

​
How to use these recipes

Each recipe is a complete, runnable playbook you can describe in natural language during a build prompt. Read the recipe, copy the prompt, adapt the field names to your data model, and ship. Every recipe includes:
  • The objective the playbook serves
  • The trigger and tool calls
  • The default risk tier and recommended graduation path
  • A natural-language prompt you can paste into the build chat

​
1. Stalled-deal chaser (sales)

Objective. No deal sits in a single stage for more than 14 days without a follow-up attempt. Shape. 
name: Stalled deal chaser
scope: app_wide
trigger:
  type: schedule
  cron: "0 9 * * 1-5"
steps:
  - tool: query_collection
    collection: deals
    filter: "stage NOT IN ('won','lost') AND days_since_stage_changed_at >= 14 AND amount > 5000"
  - tool: query_collection
    collection: contacts
    filter: "id IN {{ step1.deals[*].contact_id }}"
  - tool: draft_for_approval
    underlying: send_email
    template: stalled_deal_followup
    owner: "{{ deal.owner }}"
    payload:
      to: "{{ step2.contact.email }}"
      subject: "Following up on {{ step1.deal.name }}"
guardrails:
  risk_tier: draft_and_approve
  rate_limit_per_user: "10/day"
  rate_limit_per_recipient: "1/2_weeks"
Prompt. 
Add a stalled-deal chaser to the sales app. Watch the
deals collection. Every weekday at 9 AM, find deals over
$5,000 that haven't moved stage in 14 days. For each,
draft a follow-up email to the contact and route it to
the deal owner's Autopilot inbox. Cap at 10 drafts per
owner per day, 1 per recipient per 2 weeks.
Graduation. Stay in draft_and_approve until the action log shows a 90%+ approval rate over 30+ days. Internal-only graduation paths don’t apply (these are external recipients).

​
2. SLA enforcer (operations)

Objective. No customer ticket goes more than 24 hours without first response. Shape. 
name: SLA enforcer
scope: app_wide
trigger:
  type: schedule
  cron: "*/15 * * * *"
steps:
  - tool: query_collection
    collection: tickets
    filter: "status = 'open' AND first_response_at IS NULL AND age_hours >= 24"
  - tool: notify_user
    user_id: "{{ ticket.assignee }}"
    title: "SLA breach: {{ ticket.title }}"
    link: "/tickets/{{ ticket.id }}"
  - tool: draft_for_approval
    underlying: send_email
    template: sla_breach_customer_update
    owner: "{{ ticket.team_lead }}"
    payload:
      to: "{{ ticket.customer_email }}"
guardrails:
  risk_tier: draft_and_approve
  rate_limit_per_user: "20/day"
Prompt. 
Add an SLA enforcer to the support app. Every 15 minutes,
find open tickets older than 24 hours with no first
response. Notify the assignee in-app, and draft a customer
status update for the team lead's Autopilot inbox.
Graduation. The notify_user step is already auto-tier (internal). The customer-facing email stays in draft-and-approve.

​
3. Inventory watchdog (e-commerce)

Objective. No SKU drops below its reorder point without a draft purchase order. Shape. 
name: Inventory watchdog
scope: app_wide
trigger:
  type: data_change
  collection: products
  on: [update]
  where: "changed('quantity_on_hand') AND new.quantity_on_hand <= reorder_point"
steps:
  - tool: query_collection
    collection: suppliers
    filter: "id = {{ trigger.record.preferred_supplier_id }}"
  - tool: draft_for_approval
    underlying: send_email
    template: reorder_request
    owner: "{{ ops_team_lead }}"
    payload:
      to: "{{ step1.supplier.contact_email }}"
      subject: "Reorder request: {{ trigger.record.sku }}"
      context:
        sku: "{{ trigger.record.sku }}"
        quantity: "{{ trigger.record.reorder_quantity }}"
guardrails:
  risk_tier: draft_and_approve
  rate_limit_per_recipient: "1/day"
Prompt. 
Add an inventory watchdog to the warehouse app. Watch the
products collection. When a product's quantity drops to or
below its reorder point, look up its preferred supplier and
draft a reorder request email to ops. Cap at one draft per
supplier per day.
Graduation. Internal-only variants (POs to a procurement queue rather than directly to a supplier) can graduate to auto_with_undo.

​
4. Daily briefing (personal, every role)

Objective. Every user starts the day with a summary of what’s on their plate. Shape. 
name: Daily briefing
scope: personal
trigger:
  type: schedule
  cron: "0 8 * * 1-5"
  timezone: "{{ user.timezone }}"
steps:
  - tool: query_collection
    collection: deals
    filter: "owner = {{ user.id }} AND close_date_within = '7_days'"
    sort: "amount desc"
    limit: 5
  - tool: query_collection
    collection: tasks
    filter: "assignee = {{ user.id }} AND status != 'done' AND due_date <= today + 1"
  - tool: draft_for_approval
    underlying: notify_user
    template: daily_briefing
    owner: "{{ user.id }}"
    payload:
      title: "Your day at a glance"
      sections:
        - "Top deals closing this week"
        - "Tasks due today and tomorrow"
guardrails:
  risk_tier: draft_and_approve
  rate_limit_per_user: "1/day"
Prompt. 
Add a personal daily briefing for each user. At 8 AM in
their timezone on weekdays, summarize: top 5 deals closing
this week (by amount), tasks due today and tomorrow. Land
the draft in the user's Autopilot inbox. One per day max.
Graduation. A daily briefing is a strong candidate for auto_with_undo after a trial period. It’s personal, internal, and reversible (notification can be dismissed).

​
5. Anomaly detector (finance / payouts)

Objective. Any payout that’s an outlier compared to history gets a human eye before it processes. Shape. 
name: Payout anomaly detector
scope: app_wide
trigger:
  type: data_change
  collection: payouts
  on: [create]
  where: "amount > 50000 OR amount > 5 * customer.avg_payout_last_90_days"
steps:
  - tool: query_collection
    collection: customers
    filter: "id = {{ trigger.record.customer_id }}"
  - tool: ask_human
    user_id: "{{ finance_lead }}"
    question: "Approve payout of {{ trigger.record.amount }} to {{ step1.customer.name }}? (5x normal)"
    options: [approve, hold_for_review, deny]
    timeout: "4h"
guardrails:
  risk_tier: draft_and_approve
Prompt. 
Add a payout anomaly detector to the finance app. When a
new payout is created above $50,000 or 5x the customer's
90-day average, ask the finance lead in Autopilot to
approve, hold, or deny. Default to hold if no answer in 4 hours.
Graduation. This stays in human-in-the-loop forever. Anomaly detection is exactly the case where you don’t graduate.

​
6. Digest publisher (org-wide)

Objective. The leadership team gets a weekly summary of pipeline, SLA, and ops health without anyone having to assemble it. Shape. 
name: Weekly leadership digest
scope: app_wide
trigger:
  type: schedule
  cron: "0 16 * * 5"   # Friday 4 PM
steps:
  - tool: query_collection
    collection: deals
    filter: "stage_changed_at > now - 7_days"
  - tool: query_collection
    collection: tickets
    filter: "created_at > now - 7_days OR resolved_at > now - 7_days"
  - tool: query_collection
    collection: AgentAction
    filter: "created_at > now - 7_days"
  - tool: draft_for_approval
    underlying: send_slack
    template: leadership_digest
    owner: "{{ chief_of_staff }}"
    payload:
      channel: "#leadership"
      blocks: "{{ rendered }}"
guardrails:
  risk_tier: draft_and_approve
  rate_limit_per_user: "1/week"
Prompt. 
Every Friday at 4 PM, draft a weekly leadership digest
combining pipeline movement, ticket throughput, and agent
activity from the past 7 days. Route the draft to the chief
of staff's Autopilot inbox. On approval, post to #leadership.
Graduation. Once the chief of staff has approved 4+ weeks unchanged, this is a strong candidate for auto_with_undo to Slack.

​
Adapting recipes to your data

Field names like deal.owner, ticket.assignee, and customer.avg_payout_last_90_days are placeholders. When you describe the playbook in a build prompt, Gainable’s build agents read your actual schema and rewire the references. If a recipe references a field your schema doesn’t have (e.g. avg_payout_last_90_days), the autopilot phase will offer to add it as a derived field during the build. You can accept, edit, or skip.

​
Patterns you’ll see across recipes

  • query_collection first, then draft_for_approval. Almost every recipe reads relevant context before drafting. The action log captures both, so reasoning is auditable.
  • Personal scope binds timezone to the user. Personal recipes use {{ user.timezone }} so 8 AM means 8 AM where the user lives.
  • Rate limits are not optional. Every recipe has at least one. They’re the difference between “the agent helps” and “the agent floods.”
  • Graduation paths are explicit. Each recipe states whether and when graduation is appropriate.

​
Best practices

Pick the recipe that solves the loudest problem your team has today. Get it through approval, edit, and graduation. Then add the next one.
Replace placeholder field names with yours. Adjust thresholds to your data’s volume. The shape stays the same; the values are yours.
Simulate on last 30 days before going live. Recipes that look reasonable in a doc can produce surprising volume against real data.
Approval rate, skip reasons, and rate-limited counts tell you whether the playbook is tuned correctly. Tune in week one. Graduate in month one.

​
Learn more

Playbooks

The shape every recipe follows

Tools

What each step in a recipe calls

Risk tiers

How recipes graduate

Connect outbound

Where Slack, email, and Stripe payouts connect