Build AI agents that do the work.

One agent collects prices, listings and job posts from several services on a schedule, cleans the mess into one table and pings you only when something actually changed.

You describe a source once: its URL, how pages are paginated and which fields you need. The agent fetches the page, lets the model extract fields into a fixed schema, deduplicates by a stable key, saves a snapshot and writes a diff against the previous run.

Build a scraping and monitoring agent.

Data: table "sources" (name, url, pagination_pattern, selector_hint, fields jsonb, interval_minutes, active). Table "runs" (source_id, status, items_found, error, started_at, finished_at). Table "items" (source_id, raw_key unique per source, title, price numeric, currency, url, published_at, payload jsonb, first_seen_at, last_seen_at). Table "item_changes" (item_id, field, old_value, new_value, created_at).

Server: an edge function that takes a source id, fetches the page with a normal user agent, strips scripts, styles and navigation, trims the text to the listing area, then asks the model to extract rows into a strict JSON schema with temperature zero and null for missing values. Upsert rows into items on raw_key and insert item_changes whenever a tracked field differs. Log every attempt into runs, retry twice with backoff on network errors and respect a per source rate limit. Follow pagination up to a configurable page limit.

Automation: a scheduled job that picks active sources whose interval has elapsed, runs them one by one, then sends a digest email or webhook containing only item_changes created since the previous digest.

UI: sources page with add and edit form, health badge from the last run, run history with error text, items table with search and filters, a change feed and a CSV export button.

Rules: only public pages, honour robots.txt, keep all keys and model calls on the server, enable row level security so each user sees only their own sources and items.

The first agent most teams need: it reads your help center and answers customers at three in the morning without inventing policies.

Upload docs, split them into chunks, store embeddings, and answer only with retrieved passages plus a source link. When nothing matches, the agent escalates to a human instead of guessing.

Build a documentation support agent.

Data: a table "documents" (title, url, content) and a table "chunks" (document_id, content, embedding vector). A table "escalations" (question, email, created_at, status).

Server: one edge function that embeds the user question, retrieves the six closest chunks, and streams an answer that uses only those chunks. Every answer must end with the source links it used. If similarity is below the threshold, return a short "I do not have this in the docs" answer and insert a row into escalations.

UI: a chat page with streaming responses, message history in the browser, source links rendered as chips under each answer, and an escalation form that appears when the agent cannot answer.

Enable row level security on all tables, keep model calls on the server, and show a clear error state when the request fails.

Replace the contact form nobody fills in with an agent that asks four questions and books the meeting itself.

The agent runs a short structured interview, scores the lead against your criteria, writes the result into the database and sends a summary to sales.

Build a lead qualification agent widget.

Behaviour: the agent asks at most five questions, one at a time, to learn company size, budget range, timeline and the problem being solved. It never asks two questions in one message and never asks for data it already has.

After the interview, produce a structured result with fields: score, tier, summary, next_step. Keep the schema flat and unconstrained, state the ranges in the prompt text, and clamp values in code.

Storage: insert into a "leads" table with contact details, transcript, score, tier and created_at. Send a notification email with the summary.

UI: a floating chat bubble on the landing page, mobile friendly, with a typing indicator and a final card showing the booked next step.

A multi-step agent that searches, reads, compares and returns a sourced brief instead of a confident paragraph.

Define three tools: search, fetch page, and save finding. Let the agent loop until it has enough evidence, then render the tool timeline in the UI so users can audit every step.

Build a research agent with tool calling.

Tools: web_search(query), fetch_page(url), save_finding(claim, source_url, confidence). Give each tool a narrow input schema and a short description.

Loop: allow at least fifty steps, stop when the agent has five saved findings or decides the question is answered. Never let the agent answer without at least two independent sources.

Output: a brief with a one paragraph answer, a bullet list of findings, and a sources section. Save the brief to a "reports" table.

UI: stream the answer, render every tool call as a timeline row with its input and a compact result, and add a copy button plus markdown export.

Paste one article, get the newsletter, the thread, the carousel script and the video hook, all in your own voice.

Store a voice profile with rules and banned phrases, then generate each format in a separate call so the outputs stay sharp instead of blending together.

Build a content repurposing agent.

Input: a long article plus a saved voice profile (tone rules, favourite words, banned phrases, audience).

Generate four outputs in separate calls so each one is focused: a newsletter intro, a social thread of six posts, a carousel script of seven slides, and three video hooks.

Rules for every output: no em dashes, no emoji, no filler phrases like "in today's fast paced world", short sentences, concrete nouns.

UI: one input panel on the left, four result cards on the right, each editable inline with a copy button and a regenerate button that only regenerates that card.

Every founder drowns in the same forty emails. This agent sorts them, drafts the answers and asks before sending anything.

Classify each message into a small set of intents, attach a suggested action, and require explicit approval for anything that leaves the app.

Build an inbox triage agent.

For each incoming message, classify it as one of: sales, support, partnership, invoice, noise. Add urgency low, medium or high, and a one sentence reason.

Draft a reply for every message that is not noise, using saved templates as the base and matching the sender's language.

Any action that sends an email or changes external state must require approval in the UI first. Show the draft, the intent and the reason on an approval card with approve, edit and discard.

UI: a triage queue grouped by intent, keyboard shortcuts for approve and skip, and a daily digest view of what was handled.

Clinics, salons and workshops still miss half their calls. A voice agent answers on the first ring and writes the booking straight into the calendar.

Speech to text on the way in, a short scripted dialogue in the middle, text to speech on the way out, and a confirmation message the caller can check.

Build a voice booking agent.

Flow: transcribe the caller audio, run a slot filling dialogue that collects service, preferred day, preferred time and phone number, confirm the details out loud, then create the booking.

Never invent availability. Check the bookings table first and offer the two closest free slots when the requested time is taken.

Confirm by reading the booking back and sending a text summary. Store the full transcript with the booking for review.

UI: an operator dashboard with today's calls, transcripts, created bookings and a flagged list of calls the agent could not finish.

Most churn happens in the first ten minutes. An agent that knows where the user is stuck fixes activation better than any tooltip tour.

Feed the agent the user's completed steps and current screen, let it suggest the single next action, and give it a tool that can actually perform that action.

Build an in-app onboarding copilot.

Context: pass the current route, the list of completed setup steps and the last three user events into the system prompt on every call.

Behaviour: always propose exactly one next action, explain in one sentence why it matters, and offer to do it. Never list five options.

Tools: create_project, invite_teammate, connect_data_source. Mark every tool as needing approval, and show the approval card inline in the chat.

UI: a slide-over panel available from every page, a progress checklist at the top, and an admin view showing where users get stuck most often.

Ask a question in plain language, get a chart and the query behind it. The honesty of showing the query is what makes people trust it.

Give the agent the schema, restrict it to read-only views, let it write the query, run it server side and render the result as a chart with the SQL visible underneath.

Build a data analyst agent over a read-only schema.

Safety: expose only read-only views, reject anything that is not a select, cap rows returned, and run every query server side with a timeout.

Behaviour: the agent writes the query, explains in one sentence what it measures, then picks the chart type that fits the shape of the result.

UI: a question box with example questions, a chart, a collapsible SQL block, and a saved questions list that can be rerun with one click.

Handle empty results and query errors explicitly with a plain language message and a suggested fix.

Not another article spinner. This agent reads the current results page, finds what everyone missed, and briefs a page that deserves the click.

Collect the top results, extract their headings, cluster the shared subtopics and output an outline with the angles nobody covered plus internal link targets.

Build an SEO brief agent.

Input: a target keyword and the site the page will live on.

Steps: search the keyword, fetch the top eight results, extract their headings and word counts, cluster the shared subtopics, and list the questions none of them answer well.

Output a brief with: search intent in one line, target title and description, an H2 outline, entities to mention, three internal link targets from the given site, and the differentiating angle.

UI: a single input, a progress list of the steps as they run, and the finished brief in a copyable panel with markdown export.

Filters make people leave. A short conversation about what they actually need gets them to the product page ready to buy.

The agent asks about use case and constraints, queries the live catalogue, and returns three options with a plain comparison of the trade-offs.

Build a shopping assistant agent for an online store.

Tools: search_products(query, filters), get_product(id), check_stock(id).

Behaviour: ask at most three questions about use case, budget and any dealbreaker, then recommend exactly three products. For each one, give the reason it fits and the honest downside. Never recommend an out of stock item.

UI: chat with product cards inline, each card showing image, price, stock status and an add to cart button. Keep the conversation on the product page as a side panel.

Log every conversation with the products shown and whether the visitor added to cart, so the store can measure assisted revenue.

Two hundred applications, one honest scorecard per candidate, and a record of exactly why each decision was made.

Parse the resume, score it against the criteria you wrote, ask two clarifying questions by email, and hand the shortlist to a human with reasoning attached.

Build a recruiting screening agent.

Input: a job description with must have and nice to have criteria, plus uploaded resumes.

For each candidate produce: a score per criterion, an overall recommendation, the strongest evidence quoted from the resume, and the biggest open question.

Never infer age, gender, nationality or anything the criteria do not mention, and never reject a candidate automatically. The agent proposes, a human decides.

UI: a candidate table sorted by score with expandable scorecards, a compare view for the top five, and a one click email that asks the open question.

Upload a statement, get categories, trends and one uncomfortable sentence about the subscription you forgot.

Parse the file, categorise transactions, detect recurring charges, and let the user ask follow-up questions about their own numbers.

Build a personal spending agent.

Input: a CSV bank statement uploaded by the user.

Processing: normalise dates and amounts, categorise every transaction using rules first and the model only for the leftovers, and detect recurring charges by matching merchant and cadence.

Output: a summary with total by category, month over month change, the three largest changes explained in one sentence each, and a list of subscriptions with their yearly cost.

UI: upload area, a category chart, a transactions table with inline category editing that retrains the rules, and a chat box for follow up questions about the uploaded data only.

Keep all data private to the signed in user with row level security.

One chat window that reads your CRM, your docs and your billing, then does the boring cross-tool task nobody wants to open five tabs for.

Model Context Protocol turned tool access into a standard. Instead of writing a separate integration for every service, the agent gets a list of typed tools and picks the right one at runtime. You keep a registry of connections, a permission map per user role, and a log of every call the agent made.

Build an internal tool-calling agent with a typed tool registry.

Data: connections (user_id, service, label, status), tools (name, description, args_schema, mode read or write), tool_calls (tool, args, result, duration_ms, cost), approvals (tool_call_id, status).

Server: one function that returns the tools allowed for the current user role, one function that executes a tool after validating arguments against args_schema, and one that records the call.

Agent loop: the model receives the allowed tool list, chooses at most one tool per turn, and must explain in one sentence why it chose it.

Safety: any tool marked write requires an approval card showing the exact arguments before it runs. Never execute a write tool without a recorded approval row.

UI: chat panel, a connections page with a test-run button, and a run timeline showing each tool call with duration and cost.

Protect every table with row level security so a user only ever sees their own connections and calls.

The most searched agent of the year. It takes a list of companies, finds the reason to reach out, writes a message that does not read like a template, and puts the reply on your calendar.

The value is not in sending more mail, it is in the research step. For each company the agent gathers a few public signals, scores fit against your ideal customer profile, drops anything below the bar, and only then drafts. Every draft waits for a human click before it leaves.

Build an AI SDR agent focused on research quality, not send volume.

Data: accounts (name, domain, size, notes), signals (account_id, type, text, source_url, found_at), fit_scores (account_id, score, reason), drafts (account_id, subject, body, status), replies (draft_id, category, next_step).

Pipeline: import accounts from CSV, research each account and store at least one signal with a source URL, score fit from 0 to 100 against a stored ideal customer profile, and draft only for accounts above the threshold.

Writing rule: every draft must quote exactly one stored signal and stay under 90 words. If no signal exists, skip the account and say why.

Human control: drafts land in an approval queue with inline editing. Nothing sends without an approved row and a per-day send cap.

Replies: classify each reply as interested, not now, or not a fit, and surface interested ones with a suggested meeting time.

UI: pipeline board, an account page showing signals with source links, and a draft queue with approve, edit and skip.

Twelve brittle scenarios, three tools, nobody remembers which one sends the invoice. Fold them into one app where every run is visible and every failure has a name.

Deterministic steps stay deterministic. The model is used only where a decision needs judgement: classify this, choose the recipient, decide whether it can wait. Everything else is plain code on a schedule, which is what makes the whole thing cheap and boring in the best way.

Build a workflow runner app where an AI step is used only for judgement.

Data: workflows (name, schedule, active), steps (workflow_id, position, kind rule or model, config), runs (workflow_id, started_at, status), run_steps (run_id, step_id, input, output, duration_ms, error), dead_letters (run_id, payload, reason).

Execution: run steps in order, store input and output of every step, retry a failed step three times with growing delay, then write it to dead_letters and stop the run.

Model steps: must return exactly one value from a fixed list defined in the step config, with a one sentence reason stored alongside.

UI: workflow list with last run status, a run timeline showing each step with duration and output, a manual run button, and a dead letter screen with a retry action.

Keep secrets in server functions only and protect every table with row level security.

A clinic, a salon or a repair shop misses a third of its calls. Each one is a paying customer who just called the next number on the list.

The agent picks up, answers the five questions everyone asks, checks the calendar, books or takes a message, and sends the owner a summary. The trick is the fallback: when the caller sounds annoyed or asks something outside the script, it offers a human and stops talking.

Build an AI receptionist for a local business.

Data: business_profile (hours, services, prices, address, five FAQ pairs), calls (started_at, caller, outcome), transcripts (call_id, role, text, confidence), bookings (service, slot, caller, status hold or confirmed), messages (call_id, text, callback_number).

Behaviour: greet, identify the request, answer only from business_profile, check available slots, place a hold, confirm, then release or confirm the hold.

Limits: answers stay under two sentences. If the model cannot answer from business_profile, or the caller sounds frustrated, offer a callback and store the number instead of guessing.

After the call: generate a summary with outcome, next step and a link to the transcript, and send it to the owner.

UI: a text chat to test the same logic without voice, a call log with transcripts, a bookings calendar, and an editable business profile page.

The fastest agent to build and the easiest to demo. Paste one thought, get seven hooks, seven scripts and the caption, all in your own voice.

Voice is the product. The agent stores ten samples of how you actually write, extracts the patterns once, and applies them to every script. Without that step you get the same generic hook everyone else posts.

Build a short video script agent that writes in the user's own voice.

Setup: the user pastes ten samples of their own writing. Extract a voice profile once with tone, sentence length, favourite structures and banned words, and store it.

Input: one idea in a sentence.

Output: seven hooks scored for curiosity and clarity, the best three expanded into 40 second scripts using hook, tension, payoff and call to action, plus a caption and five tags for each.

Rules: no generic openers, no words from the banned list, and every script must be readable out loud in under 45 seconds.

UI: idea input, a scored hook list, a script editor, and a weekly calendar where scripts can be dragged between days.

One brief in, one finished ad out: script, storyboard, voice over, subtitles and three cuts for different placements. The part people underestimate is the shot list, not the render.

The agent works in stages instead of one giant prompt. It writes the offer and the promise first, then a scene by scene shot list with duration per shot, then the voice over text timed to those durations, then it assembles the clips and burns in subtitles. Each stage is saved, so you can rewrite one scene without regenerating the whole ad.

Build an ad video agent that turns a product brief into a finished commercial.

Data: briefs (product, buyer, pain, promise, proof), scripts (brief_id, angle, status), shots (script_id, index, seconds, visual, voice_over, on_screen_text, clip_url), renders (script_id, aspect, url, status).

Flow, one stage at a time and each stage saved before the next:
1. From the brief, propose three angles with a one line promise each. Wait for the user to pick one.
2. Build a shot list as rows with index, seconds, visual, on screen text. Total duration must equal the chosen placement length of 15, 30 or 60 seconds.
3. Write the voice over per shot, sized to that shot's seconds at about 2.5 words per second.
4. Attach a clip to each shot, then queue renders for 9:16, 1:1 and 16:9 with burned in word level subtitles.

Rules: one promise per ad, the hook lands in the first two seconds, no claim that is not backed by the proof field, and never exceed the placement length.

UI: brief form, angle picker, an editable shot table where changing seconds re-times only that shot's voice over, a render queue with status, and a version list to compare cuts side by side.

Paid social does not fail on the edit, it fails on the first two seconds. This agent produces twenty hooks per product, keeps the ones that survive scoring, and turns them into shot ready creator briefs.

The output is not a script, it is a shooting kit: hook line, what the creator holds and does in each beat, the line said out loud, the caption and the thumbnail frame. Every variant carries a tracking name so ad results can be pasted back and the agent learns which hook family wins.

Build a UGC ad script agent that produces shot ready creator briefs and learns from results.

Data: products (name, promise, proof, audience), hooks (product_id, family, line, curiosity_score, clarity_score, claim_risk), variants (hook_id, beats json, caption, tags, tracking_name), results (tracking_name, spend, views, clicks, conversions).

Hook families: problem, contrast, mistake, result, demo, story. Generate three hooks per family, score each from one to five on curiosity and clarity, flag any claim not supported by the proof field, keep the top eight and discard the rest.

For each surviving hook produce four beats of five seconds: hook, problem, demo, call to action. Every beat states what is in frame, what the creator does with their hands, and the exact line spoken. Add a caption, three tags and a tracking name of the form product-family-number.

Results loop: accept a CSV of results by tracking name, compute cost per click per hook family, and weight the next generation toward the winning families.

UI: product form, a scored hook table, a beat editor, a print view of the creator brief, and a results dashboard by hook family.

Record a messy five minute walkthrough, get back a 60 second demo with a written narration, zoom on every click that matters and clean subtitles. The dead air is what kills demos, and that is exactly what the agent removes.

Transcription is only the entry point. The agent maps the transcript to the moments in the recording, drops silences and repeated attempts, rewrites the rambling into short benefit led narration, then places zoom and highlight markers on the timestamps where a click happened. The user edits a timeline of segments, not a video file.

Build a product demo video agent that turns a raw screen recording into a short polished demo.

Data: recordings (file_url, duration, target_length), words (recording_id, text, start, end), segments (recording_id, start, end, task, narration, importance), markers (segment_id, timestamp, type zoom or highlight, region), exports (recording_id, aspect, url, status).

Pipeline: transcribe with word level timestamps, remove silences longer than 0.6 seconds and repeated sentence starts, group the rest into segments where one segment equals one task the product performs, rewrite each segment into a single benefit sentence, score segments by importance and keep only enough to fit the target length.

Then place a zoom marker at every click timestamp and a highlight on the region that changed, render with word level subtitles and export 16:9 and 9:16 from the same edit.

Rules: narration describes the outcome, not the interface. Never say click here. Total length must not exceed the target. Keep every cut reversible by storing segments rather than rewriting the source file.

UI: upload page, a segment timeline where segments can be reordered, muted or restored, a narration editor with live duration, a marker overlay on the preview, and an export panel per aspect ratio.