100 AI Automation Ideas You Can Build in 2026

Most lists of AI automation ideas are lists of wishes. They name an outcome — "automate your reporting," "automate your outreach" — and leave out the part that decides whether the thing survives contact with a real week of work: what starts it, what it is allowed to do, what it hands back, and who signs off.

This list does not do that. Every one of the hundred ideas below is written as a build spec with five fields:

• Trigger — the event that starts the run. If you cannot name it, you do not have an automation, you have a chore you are doing by hand on a schedule.
• Action — what the agent actually does between trigger and output.
• Output — the artifact. A draft, a record, a file, a message, a ticket.
• Human checkpoint — where a person looks before anything irreversible happens.
• Build with — the components involved, in generic terms that map onto AGNT primitives (triggers, tools, agents, goals, workflows, memory).

A word on the checkpoints, because they are the point. The failure mode of this era is not that agents are too weak. It is that people wire a capable model directly to a system of record, or to a customer, and discover the failure two weeks later in an audit. Only entries whose checkpoint explicitly says no approval is required should run unattended, and only after a monitored burn-in period. The rest should never lose their approval step, and I have said so item by item rather than pretending otherwise.

Nothing here contains a claimed ROI figure, a "10x," or a saved-hours number. I do not know your baseline. What I can tell you is which of these are cheap to build and hard to break, and which are the opposite — that is what the effort and risk matrix is for.

If you want the shorter, more strategic version of this territory first, read AI agent use cases. If you want to build one of these today and have never shipped an agent before, start with how to build an AI agent and come back. Working examples by department live in use cases.

---

How to read this list

Each idea is numbered and grouped by function. The groups are:

Group	Items	Character of the work
Marketing	1–10	High volume, low individual stakes, public-facing
Sales	11–20	Touches revenue records and named humans
Support	21–30	Fast loops, customer-visible, tone-sensitive
Operations	31–40	Cross-system, high blast radius
Finance	41–50	Auditable, regulated, approval-heavy
HR and people	51–60	Legally sensitive, bias-exposed
Software engineering	61–70	Verifiable by tests, which makes it unusually safe
Research and analysis	71–80	Cheap to run, expensive to trust without sourcing
Personal work	81–90	Single-user, low stakes, best place to learn
Monitoring	91–100	Always-on, alert-fatigue-prone

Read the group that owns your worst recurring task. Ignore the rest until that one is running.

---

Marketing (1–10)

Marketing is the standard on-ramp because the artifacts are drafts, the review is fast, and a bad output costs a rewrite rather than a refund. The trap is volume: an agent that produces forty mediocre drafts a week creates a review queue nobody staffs, and the queue quietly becomes a publish-without-reading pipeline.

1. Brief-to-draft article pipeline

• Trigger: A new row appears in the content calendar with status ready for draft.
• Action: Pull the brief, the target query, and three internal pages to link, then produce a full draft against a house structure template.
• Output: A Markdown draft with frontmatter, headings, and internal links already placed.
• Human checkpoint: Mandatory editorial pass before publish. No agent gets write access to the CMS publish endpoint.
• Build with: Database trigger → retrieval tool over your own site → writing agent with a style guide in memory → file output.

2. Repurposing fan-out

• Trigger: An article is published.
• Action: Derive a short-form post set, a newsletter blurb, and a slide outline from the same source text, each respecting the format's own constraints rather than truncating the article.
• Output: One draft per channel in a review folder.
• Human checkpoint: Review before scheduling; the tone drift between channels is where these fail.
• Build with: Webhook trigger → one agent per channel running in parallel → shared source document.

3. Internal link auditor

• Trigger: Weekly schedule, or on publish.
• Action: Crawl the site, build a page-to-topic map, and find pages that should link to each other but do not.
• Output: A ranked list of suggested link insertions with the exact anchor sentence and destination.
• Human checkpoint: Approve suggestions in batch; auto-inserting links into live pages is a fast way to create nonsense anchors.
• Build with: Scheduled trigger → crawler tool → embedding-based similarity → report file.

4. Ad copy variant generator with brand constraints

• Trigger: A campaign brief is filed.
• Action: Generate copy variants under hard constraints — character limits, banned claims, required disclaimers — and reject its own outputs that violate them.
• Output: A table of compliant variants tagged by angle.
• Human checkpoint: Legal or brand review before any variant reaches an ad account. Mandatory in regulated categories.
• Build with: Form trigger → generation agent → deterministic validator step → spreadsheet output.

5. Landing page copy refresher

• Trigger: A page's conversion rate drops below its trailing baseline.
• Action: Read the page, the analytics, and recent support tickets mentioning the same product, then propose specific copy changes tied to observed confusion.
• Output: A diff-style proposal: current line, proposed line, reason.
• Human checkpoint: Always. Copy changes on money pages go through the normal test process.
• Build with: Metric threshold trigger → analytics tool + ticket search → analysis agent → document.

6. Competitor page-change watcher

• Trigger: Daily schedule.
• Action: Fetch a watchlist of competitor pricing, feature, and changelog pages, diff them against yesterday, and summarize only the meaningful changes.
• Output: A short digest, sent only when something actually changed.
• Human checkpoint: None required for the digest itself. Do not let it write to your positioning docs.
• Build with: Schedule → scrape tool → stored snapshot in memory → diff and summarize agent → chat message.

7. Newsletter assembly from the week's activity

• Trigger: Thursday morning schedule.
• Action: Gather published posts, shipped features, and notable community threads, then assemble them into the newsletter template with written transitions.
• Output: A ready-to-edit draft in the email tool.
• Human checkpoint: Human sends. Always. An agent with send permission on a list is a recall waiting to happen.
• Build with: Schedule → multiple source tools → assembly agent → email platform draft API.

8. Testimonial and quote miner

• Trigger: Weekly schedule.
• Action: Scan support conversations, reviews, and social mentions for positive, specific, quotable statements, then filter out the vague ones.
• Output: A candidate list with source link, exact quote, and customer identity.
• Human checkpoint: Mandatory. Nobody's words go on a marketing page without permission, and the permission request is a human email.
• Build with: Schedule → source connectors → classification agent → review queue.

9. SEO cannibalization detector

• Trigger: Monthly schedule.
• Action: Compare ranking URLs per query across the last three months and flag queries where two of your own pages trade positions.
• Output: A conflict report with a recommended winner and consolidation plan.
• Human checkpoint: Approve before any redirect or merge. Redirects are hard to unwind.
• Build with: Schedule → search console data → analysis agent → report.

10. Event and webinar follow-up sequencer

• Trigger: Attendance data lands after an event.
• Action: Segment attendees by attendance depth and questions asked, then draft a distinct follow-up per segment referencing what was actually discussed.
• Output: Drafted sequences per segment, unsent.
• Human checkpoint: Review before send, especially the "asked a hostile question" segment.
• Build with: File-upload trigger → segmentation logic → drafting agent → CRM sequence draft.

---

Sales (11–20)

Sales automations touch named humans and revenue records, which changes the calculus. The rule I use: an agent may read anything, may write to a scratch field, and may not change a stage, an amount, or an owner without a person clicking.

11. Inbound lead enrichment and routing

• Trigger: New form submission.
• Action: Enrich the company from public sources, score against your ICP definition, and assign a routing recommendation with the reasoning attached.
• Output: An enriched lead record plus a routing note.
• Human checkpoint: Auto-routing is acceptable once the scoring has agreed with humans for a few hundred leads. Until then, recommend only.
• Build with: Webhook → enrichment tool → scoring agent → CRM update.

12. Pre-call briefing pack

• Trigger: Fifteen minutes before a calendar event with an external attendee.
• Action: Assemble company news, prior email threads, open tickets, product usage, and the last call's notes into one page.
• Output: A brief delivered to the rep's chat.
• Human checkpoint: None. It is read-only and it only talks to your own team.
• Build with: Calendar trigger → CRM, support, and analytics tools → summarizer agent → direct message.

13. Call notes to CRM fields

• Trigger: A call recording transcript becomes available.
• Action: Extract next steps, stated objections, budget language, competitors mentioned, and proposed dates into structured fields.
• Output: A structured summary attached to the opportunity.
• Human checkpoint: The rep confirms extracted fields before they overwrite anything. Auto-writing a close date from a transcript produces a forecast built on hallucinated confidence.
• Build with: Transcription webhook → extraction agent with a strict schema → CRM patch after approval.

14. Stale pipeline sweeper

• Trigger: Daily schedule.
• Action: Find opportunities with no activity past their stage's normal dwell time and draft a specific re-engagement message per deal based on the last real conversation.
• Output: A queue of draft messages, one per stalled deal.
• Human checkpoint: Rep sends each one. Bulk-sending generated re-engagement mail is how you get domain reputation damage.
• Build with: Schedule → CRM query → drafting agent → task queue.

15. Proposal assembly from an approved library

• Trigger: An opportunity moves to proposal.
• Action: Select clauses, case studies, and pricing tables from an approved library that match the deal's shape, then assemble the document.
• Output: A draft proposal, assembled from approved blocks only.
• Human checkpoint: Mandatory. Pricing and terms are never model-generated; the agent selects, it does not invent.
• Build with: Stage-change trigger → clause library retrieval → assembly agent → document generator.

16. RFP and security questionnaire drafter

• Trigger: A questionnaire file is uploaded.
• Action: Match each question to previously approved answers, draft only the unmatched ones, and mark its own confidence per row.
• Output: A completed sheet with a clear split between reused and newly drafted answers.
• Human checkpoint: Mandatory for every newly drafted row, and for any security or compliance claim regardless of confidence.
• Build with: File trigger → answer-bank retrieval → drafting agent → spreadsheet output.

17. Territory and account research batches

• Trigger: A rep submits a list of target accounts.
• Action: For each account, gather funding, headcount trend, tech signals, and a plausible entry point, citing sources.
• Output: One research card per account, with links.
• Human checkpoint: None for research. Every claim must carry a source URL, and unsourced claims get dropped rather than guessed.
• Build with: Form trigger → parallel research sub-agents → search and scrape tools → collated report.

18. Churn-risk early signal

• Trigger: Weekly schedule.
• Action: Combine usage decline, support sentiment, champion departure signals, and invoice history into a risk view per account.
• Output: A ranked account list with the specific signal that fired.
• Human checkpoint: CSM reviews before any outreach. Never let this fire an automated "we noticed you're leaving" email.
• Build with: Schedule → product analytics + support + billing tools → scoring agent → dashboard.

19. Quote sanity checker

• Trigger: A quote is created.
• Action: Compare discount, term, and configuration against policy and against comparable closed deals, flagging deviations.
• Output: A pass or a flag list, posted to the deal thread.
• Human checkpoint: Approval routing stays human. The agent flags; a manager approves.
• Build with: CRM trigger → policy rules in a tool + historical query → checking agent → thread comment.

20. Post-close handoff packet

• Trigger: An opportunity is marked closed-won.
• Action: Compile promises made during the sales cycle, technical requirements, stakeholder map, and timeline into an onboarding brief.
• Output: A handoff document and a created onboarding project.
• Human checkpoint: Rep confirms the promises list. This is the single highest-value item in the sales group and the one people skip.
• Build with: Stage trigger → transcript and email retrieval → summarizing agent → project tool.

---

Support (21–30)

Support is where automation quality is felt fastest, in both directions. A good deflection saves a customer time; a bad one is a customer telling a bot the same thing four times. Draft-and-suggest beats auto-reply in almost every case for the first year.

21. Ticket triage and tagging

• Trigger: New ticket created.
• Action: Classify by product area, severity, and intent, detect language, and set the routing queue.
• Output: A tagged, routed ticket.
• Human checkpoint: Safe to run unattended after you have measured misclassification on a few hundred tickets. Keep severity escalation human.
• Build with: Helpdesk webhook → classification agent with a fixed label set → helpdesk API.

22. Suggested reply with cited sources

• Trigger: Ticket enters an agent's queue.
• Action: Search documentation, past resolved tickets, and release notes, then draft a reply that cites the specific doc sections it used.
• Output: A private draft note on the ticket, never a sent message.
• Human checkpoint: The support agent sends. This is deliberate: suggestion mode captures most of the value with none of the tone risk.
• Build with: Queue trigger → retrieval over docs and ticket history → drafting agent → internal note.

23. Documentation gap finder

• Trigger: Weekly schedule.
• Action: Cluster tickets that were resolved without any documentation link, and identify the missing article that would have deflected them.
• Output: A prioritized list of articles to write, with the source tickets attached.
• Human checkpoint: None needed; it produces a backlog, not a change.
• Build with: Schedule → ticket export → clustering agent → backlog items.

24. Escalation summarizer

• Trigger: A ticket is escalated to engineering.
• Action: Condense the full conversation into a reproduction case: environment, steps, expected, actual, and what support already ruled out.
• Output: A structured bug report linked back to the ticket.
• Human checkpoint: Support agent confirms the reproduction steps before the report is filed.
• Build with: Escalation trigger → transcript retrieval → extraction agent → issue tracker.

25. Multilingual response drafting

• Trigger: A ticket arrives in a language your team does not staff.
• Action: Translate inbound, draft a reply in your working language, then produce the outbound translation with terminology locked to a glossary.
• Output: A three-panel draft: original, working, outbound.
• Human checkpoint: Mandatory for anything contractual, legal, or refund-related. Idiomatic drift in translation is a real liability.
• Build with: Language-detection trigger → translation tool with glossary → drafting agent → internal note.

26. Backlog aging watchdog

• Trigger: Hourly schedule.
• Action: Find tickets past SLA or approaching it, and post a per-owner summary rather than a per-ticket alarm.
• Output: One consolidated nudge per owner per run.
• Human checkpoint: None. Design it to consolidate, or it becomes noise and gets muted.
• Build with: Schedule → helpdesk query → grouping logic → chat message.

27. Post-resolution follow-up

• Trigger: Seventy-two hours after a ticket closes.
• Action: Check whether a related ticket reopened or a related error appeared, and only then draft a check-in.
• Output: A conditional follow-up draft.
• Human checkpoint: Human sends. Unconditional follow-ups are spam; conditional ones are service.
• Build with: Delayed trigger → helpdesk and log queries → conditional agent → draft.

28. Voice of customer digest

• Trigger: Monthly schedule.
• Action: Theme the month's tickets, reviews, and community posts into recurring problems ranked by frequency and by revenue exposure of the accounts involved.
• Output: A digest with representative verbatims per theme.
• Human checkpoint: None for reading. Do not let it write directly into the roadmap.
• Build with: Schedule → multi-source retrieval → theming agent → report.

29. Refund and credit request pre-check

• Trigger: A ticket is classified as a refund request.
• Action: Pull the account's plan, usage, prior credits, and policy eligibility, then present the case with a recommendation.
• Output: A decision packet on the ticket.
• Human checkpoint: Mandatory, without exception. Money leaving the business is a human decision every time.
• Build with: Classification trigger → billing tool + policy document → analysis agent → internal note.

30. Onboarding question anticipator

• Trigger: A new account completes signup.
• Action: Compare their setup to the paths of accounts that later filed early tickets, and identify the two most likely stumbling points.
• Output: A prompt to the CSM with specific suggested outreach.
• Human checkpoint: CSM decides whether to reach out. The prediction is often right and occasionally condescending.
• Build with: Signup webhook → cohort query → prediction agent → task.

---

Operations (31–40)

Operations automations have the widest blast radius on this list because they cross systems. A marketing draft that goes wrong wastes an hour. An inventory sync that goes wrong reprices your catalogue. Build these with dry-run modes and keep them there longer than feels necessary.

31. Vendor invoice-to-record intake

• Trigger: An invoice arrives in the shared inbox.
• Action: Extract vendor, amount, currency, line items, PO reference, and due date, then match against the open PO.
• Output: A draft payable record with the matched PO and any mismatch flagged.
• Human checkpoint: Mandatory on any mismatch, and on any vendor seen for the first time.
• Build with: Email trigger → document extraction tool → matching agent → ERP draft record.

32. Meeting-to-action-item router

• Trigger: A meeting transcript is finalized.
• Action: Extract commitments with owner and date, deduplicate against existing open tasks, and create only the genuinely new ones.
• Output: Created tasks plus a summary of what was skipped as duplicate.
• Human checkpoint: Owner confirms assignment. Auto-assigning work to people who did not agree to it damages trust in the whole system.
• Build with: Transcript webhook → extraction agent → task tool with dedupe query.

33. Standard operating procedure drafter

• Trigger: A process is performed and screen-recorded, or a request is filed.
• Action: Convert the recording or the practitioner's rough notes into a numbered procedure with prerequisites, steps, and failure recovery.
• Output: A draft SOP in the internal wiki.
• Human checkpoint: The practitioner reviews. Generated SOPs are confidently wrong about edge cases they never saw.
• Build with: File trigger → transcription and vision tools → structuring agent → wiki draft.

34. Inventory reorder proposal

• Trigger: Daily schedule.
• Action: Combine stock levels, lead times, seasonality, and open orders into per-SKU reorder proposals with the reasoning shown.
• Output: A proposed purchase order set.
• Human checkpoint: Mandatory. Approve before any PO is issued. This is a spend decision wearing a data-analysis costume.
• Build with: Schedule → inventory and supplier data → forecasting logic → approval queue.

35. Shipment exception handler

• Trigger: A carrier status changes to exception or delayed.
• Action: Determine the affected orders, draft the customer notification, and open an internal task if the delay crosses the promised window.
• Output: A notification draft and an internal task.
• Human checkpoint: Human sends anything that includes a new promised date. Machines should not make promises.
• Build with: Carrier webhook → order query → drafting agent → queue plus task.

36. Contract renewal calendar

• Trigger: Weekly schedule.
• Action: Read stored contracts for renewal and notice-period dates, then surface anything whose notice window opens in the next sixty days.
• Output: A renewal action list with the notice deadline and the responsible owner.
• Human checkpoint: None for the alert. Never let it send a notice; missing or sending a termination notice are both expensive.
• Build with: Schedule → document store retrieval → date extraction agent → calendar and digest.

37. Data hygiene sweeper

• Trigger: Nightly schedule.
• Action: Find duplicate records, malformed fields, and orphaned relationships across the CRM and billing systems, and propose merges.
• Output: A dry-run report of proposed changes with record IDs.
• Human checkpoint: Approve merges in batch. Run in dry-run for at least a month before you allow any write.
• Build with: Schedule → database queries → matching agent → report, then a separate gated apply step.

38. Access request processor

• Trigger: An access request is filed.
• Action: Check the requester's role against the access matrix, identify whether the request is standard or exceptional, and prepare the provisioning steps.
• Output: A decision packet with the exact permissions requested.
• Human checkpoint: Mandatory for anything above read-only, and for all production and financial systems. No exceptions, no learned autonomy.
• Build with: Ticket trigger → identity provider query → policy agent → approval workflow.

39. Facilities and asset request triage

• Trigger: A request form is submitted.
• Action: Categorize, check budget availability, find the standard vendor, and pre-fill the order.
• Output: A pre-filled request awaiting approval.
• Human checkpoint: Manager approval on spend, per your existing threshold.
• Build with: Form trigger → budget lookup → classification agent → approval routing.

40. Cross-system reconciliation

• Trigger: Daily schedule.
• Action: Compare the same entity across two systems — subscriptions in billing versus entitlements in the product — and list every disagreement.
• Output: A discrepancy report grouped by likely cause.
• Human checkpoint: Investigate before correcting. Auto-correcting reconciliation drift can propagate the wrong side of the disagreement.
• Build with: Schedule → two API connectors → comparison logic → report.

---

Finance (41–50)

Finance is the group where "mandatory approval" appears most often, and that is correct. The value here is in preparation, extraction, and anomaly surfacing. The decision stays with a person who can be held accountable for it.

41. Expense report pre-audit

• Trigger: An expense report is submitted.
• Action: Check receipts against policy — limits, categories, missing documentation, duplicate submissions — and explain each flag.
• Output: A pre-audit note attached to the report.
• Human checkpoint: Approver decides. The agent never approves or rejects, because "policy violation" is often "manager already said yes verbally."
• Build with: Submission webhook → receipt extraction → policy agent → note.

42. Month-end close checklist runner

• Trigger: The first business day after month end.
• Action: Walk the close checklist, check which items have their supporting data available, and chase the owners of what is missing.
• Output: A live close status board and per-owner nudges.
• Human checkpoint: None for status tracking. Journal entries stay human.
• Build with: Schedule → accounting system queries → tracking agent → board plus messages.

43. Variance explainer

• Trigger: Actuals are posted for the period.
• Action: Compare against budget by line, identify the largest variances, and pull the transactions and context that explain each one.
• Output: A draft variance commentary with the supporting transactions linked.
• Human checkpoint: Finance reviews and rewrites the narrative. The agent finds the transactions; the human decides what they mean.
• Build with: Data-ready trigger → ledger query → analysis agent → document.

44. Collections outreach drafting

• Trigger: An invoice passes a defined days-past-due mark.
• Action: Check for disputes, credits, and open support issues before drafting a reminder at the appropriate escalation tone.
• Output: A drafted reminder plus the account's payment context.
• Human checkpoint: Mandatory. Sending a dunning email to a customer with an open unresolved complaint is a preventable own goal.
• Build with: Aging report trigger → cross-system checks → drafting agent → queue.

45. Subscription revenue anomaly detection

• Trigger: Nightly schedule.
• Action: Compare recognized revenue, new subscriptions, and cancellations against trend, and flag statistically unusual movements.
• Output: An anomaly alert including the underlying records.
• Human checkpoint: None for the alert. It reports, it does not adjust.
• Build with: Schedule → billing data → statistical check → alert.

46. Vendor spend consolidation review

• Trigger: Quarterly schedule.
• Action: Group spend by category, find overlapping vendors and duplicate tools, and assemble the contract terms for each.
• Output: A consolidation opportunity report.
• Human checkpoint: None for the report; every resulting cancellation is a human decision with a stakeholder conversation attached.
• Build with: Schedule → ledger and contract store → analysis agent → report.

47. Cash position briefing

• Trigger: Daily, before the working day starts.
• Action: Pull balances, scheduled receipts, and scheduled payments to produce a short-horizon cash view with the largest movements named.
• Output: A one-screen briefing.
• Human checkpoint: None. Read-only, internal, and it should stay that way — no payment initiation, ever.
• Build with: Schedule → banking and AP/AR connectors → summarizer → message.

48. Tax document collector

• Trigger: Annual and quarterly filing windows.
• Action: Gather required documents from known locations, check each against the requirements list, and identify what is missing and from whom.
• Output: A completeness checklist with the gathered files.
• Human checkpoint: Mandatory. Filing is human, always, and the agent should never see it as its job.
• Build with: Schedule → document store → checklist agent → folder plus report.

49. Pricing change impact model

• Trigger: A proposed price change is filed.
• Action: Apply the change to the existing customer base under stated assumptions and show the arithmetic per segment.
• Output: A scenario table with the assumptions listed at the top.
• Human checkpoint: Mandatory. Every assumption must be visible and challengeable; a model that hides its assumptions is worse than no model.
• Build with: Form trigger → customer data query → calculation step in code, not prose → table.

50. Purchase order matching

• Trigger: A goods receipt is recorded.
• Action: Perform the three-way match across PO, receipt, and invoice, and quantify any variance.
• Output: A matched-or-flagged record.
• Human checkpoint: Clean matches within tolerance can auto-clear after a proven burn-in. Every flagged variance goes to a person.
• Build with: ERP trigger → three-source query → deterministic matcher → ERP update.

---

HR and people (51–60)

Two rules for this group. First, no automation touches a hiring, promotion, compensation, or termination decision — it may prepare information for one. Second, anything that reads candidate or employee data needs a documented retention and access policy before it runs, not after.

51. Job description drafter from a role scorecard

• Trigger: A hiring manager files a scorecard.
• Action: Convert responsibilities and success criteria into a posting in house voice, checked against inclusive-language guidance.
• Output: A draft posting.
• Human checkpoint: Hiring manager and recruiter both review before posting.
• Build with: Form trigger → style and language guidance in memory → drafting agent → document.

52. Application acknowledgement and status hygiene

• Trigger: An application is submitted, or a candidate's stage changes.
• Action: Send the correct stage-appropriate acknowledgement and flag candidates who have sat in a stage past the fairness window.
• Output: A sent acknowledgement and an internal aging alert.
• Human checkpoint: Acknowledgements can run unattended; rejections are written and sent by a person.
• Build with: ATS webhook → templating → send plus alert.

53. Structured interview kit builder

• Trigger: An interview loop is scheduled.
• Action: Generate role-specific questions mapped to the scorecard competencies, with a scoring rubric per question and follow-up probes.
• Output: An interview kit per interviewer, each covering different competencies.
• Human checkpoint: Interviewers review and adjust. The kit is scaffolding, not a script.
• Build with: Calendar and ATS trigger → competency library → generation agent → documents.

54. Interview debrief consolidation

• Trigger: All scorecards for a loop are submitted.
• Action: Consolidate feedback by competency, surface where interviewers disagreed, and name the specific evidence each cited.
• Output: A debrief summary highlighting disagreement rather than averaging it away.
• Human checkpoint: Mandatory, and the hiring decision is made in a human conversation. Never let the summary carry a recommendation.
• Build with: ATS trigger → scorecard retrieval → synthesis agent → document.

55. Onboarding orchestration

• Trigger: An offer is accepted.
• Action: Create the task set across IT, facilities, payroll, and the manager, sequenced by start date, and track completion.
• Output: A tracked onboarding plan with owners.
• Human checkpoint: Access provisioning still runs through the normal approval gate. See item 38.
• Build with: ATS trigger → template workflow → task tool → status tracking.

56. Policy question answerer

• Trigger: An employee asks a question in the HR channel.
• Action: Retrieve the answer from the current handbook and quote the relevant section with a link, and say plainly when it does not know.
• Output: A cited answer, or an explicit handoff.
• Human checkpoint: Anything touching leave, accommodation, compensation, or conduct goes straight to a person. Configure that as a hard routing rule, not a model judgment.
• Build with: Chat trigger → handbook retrieval → answering agent with a refusal path → reply.

57. Performance review preparation packet

• Trigger: The review cycle opens.
• Action: Gather a person's shipped work, project outcomes, and prior goals into a single evidence packet for both self-review and manager review.
• Output: A per-person evidence packet.
• Human checkpoint: The packet contains evidence only, never assessment. The employee sees their own packet before the manager writes.
• Build with: Schedule → project and code system queries → assembly agent → document.

58. Learning path recommender

• Trigger: A development goal is set.
• Action: Match the goal against the internal course catalogue and approved external resources, and sequence them.
• Output: A proposed learning path.
• Human checkpoint: Employee and manager agree on it. A recommendation, not an assignment.
• Build with: Goal-set trigger → catalogue retrieval → matching agent → plan.

59. Engagement survey theming

• Trigger: A survey closes.
• Action: Theme free-text responses, preserve verbatims, and report theme frequency by team only where the group is large enough to protect anonymity.
• Output: A themed report with anonymity thresholds enforced.
• Human checkpoint: People team reviews before distribution. The anonymity threshold must be enforced in code, not by asking the model to be careful.
• Build with: Survey webhook → clustering agent → threshold filter step → report.

60. Offboarding checklist runner

• Trigger: A departure is recorded.
• Action: Enumerate access to revoke, assets to recover, knowledge to transfer, and ownership to reassign, then track each to closure.
• Output: A tracked offboarding plan.
• Human checkpoint: Access revocation timing is confirmed by a person. Automated same-second revocation has locked people out mid-handover more than once.
• Build with: HRIS trigger → identity and asset queries → checklist workflow → tracked tasks.

---

Software engineering (61–70)

Engineering is the one group where machine output can be checked by machine. Tests, types, and linters give you a verification loop that no other department has, which makes these safer than their apparent complexity suggests. The checkpoint is still code review, because a test suite proves the code does something, not the right thing.

61. Pull request summarizer and risk tagger

• Trigger: A PR is opened.
• Action: Summarize the change in plain language, list the touched subsystems, and flag changes to migrations, auth, or public interfaces.
• Output: A PR comment with the summary and risk tags.
• Human checkpoint: None for the comment. It informs the review; it does not replace it.
• Build with: Git webhook → diff retrieval → analysis agent → PR comment.

62. Test generation for uncovered branches

• Trigger: Coverage drops below the threshold on a merged change.
• Action: Identify uncovered branches and write tests that exercise them, then run them and discard any that pass trivially.
• Output: A PR containing new tests only.
• Human checkpoint: Review required. Generated tests that assert current behavior can lock in a bug as a contract.
• Build with: CI trigger → coverage report → coding agent in a sandbox → PR.

63. Dependency upgrade pilot

• Trigger: A dependency release is published.
• Action: Open a branch, upgrade, run the full suite, and read the changelog for breaking changes relevant to your usage.
• Output: A PR with the upgrade, the test result, and a changelog-derived risk note.
• Human checkpoint: Merge is human. Patch-level upgrades with a green suite can auto-merge once you trust the suite; major versions never do.
• Build with: Registry webhook → sandboxed build environment → coding agent → PR.

64. Flaky test investigator

• Trigger: A test fails and then passes on rerun.
• Action: Correlate the failure with recent changes, timing, ordering, and shared state, then propose a specific cause.
• Output: An issue with the evidence and a hypothesis.
• Human checkpoint: None for filing. Do not let it quarantine tests automatically; quarantine is how suites rot.
• Build with: CI webhook → run-history query → analysis agent → issue tracker.

65. Incident timeline builder

• Trigger: An incident is declared.
• Action: Continuously assemble deploys, alerts, config changes, and chat decisions into a timestamped timeline as the incident runs.
• Output: A live timeline document that survives into the postmortem.
• Human checkpoint: None during the incident. The postmortem's conclusions are written by the humans who were there.
• Build with: Incident trigger → deploy, alert, and chat connectors → running summarizer → shared doc.

66. Log-to-issue converter

• Trigger: A new error signature appears above a frequency threshold.
• Action: Group occurrences, extract a representative stack trace, identify the likely owning module from code ownership data, and check for an existing issue.
• Output: A filed issue, or a comment on the existing one.
• Human checkpoint: None for filing. Dedupe hard, or you will create an issue tracker nobody opens.
• Build with: Log platform webhook → grouping logic → drafting agent → issue tracker.

67. API change and documentation sync

• Trigger: A merge changes a route, schema, or public type.
• Action: Diff the interface, update the reference documentation, and flag any published example that the change breaks.
• Output: A documentation PR.
• Human checkpoint: Review before merge, in the same review the code change gets.
• Build with: Git webhook → schema diff → writing agent → docs PR.

68. Migration script drafter

• Trigger: A model or schema change is proposed.
• Action: Draft the forward migration and the rollback, run both against a seeded copy, and report row counts and timing.
• Output: A migration PR with the dry-run evidence attached.
• Human checkpoint: Mandatory, twice: review and a separate production execution approval. Migrations are the classic irreversible operation.
• Build with: Change trigger → sandbox database → coding agent → PR.

69. Performance regression bisector

• Trigger: A benchmark regresses past its noise band.
• Action: Bisect the commit range by re-running the benchmark, and identify the introducing commit.
• Output: A report naming the commit and the affected metric.
• Human checkpoint: None for the report. Fixes are human work.
• Build with: Benchmark CI trigger → sandboxed runner → bisect loop → report.

70. Release notes assembler

• Trigger: A release branch is cut.
• Action: Group merged PRs by user-visible impact, drop internal noise, and write notes in customer language rather than commit language.
• Output: Draft release notes.
• Human checkpoint: Product review before publishing. Generated notes reliably promote a refactor to a feature.
• Build with: Tag trigger → PR history → writing agent → draft.

---

Research and analysis (71–80)

Research automations are cheap to build and easy to over-trust. The single discipline that makes them useful is a hard sourcing rule: every factual claim carries a link, and a claim the agent cannot source gets dropped rather than smoothed over. Build that as a validation step, not a prompt instruction.

71. Source-attributed topic brief

• Trigger: A research request is submitted.
• Action: Search, scrape the primary sources rather than aggregators, and write a brief where each claim is followed by its source link.
• Output: A brief with a source table and an explicit list of what could not be verified.
• Human checkpoint: Spot-check the citations. Confident prose over a broken link is the failure mode here.
• Build with: Form trigger → search and scrape tools → writing agent → validator that rejects unsourced claims.

72. Regulatory change tracker

• Trigger: Weekly schedule over a watchlist of regulator publication pages.
• Action: Fetch new publications, filter to your jurisdictions and categories, and summarize what changed and the compliance date.
• Output: A change digest linking each item to the official document.
• Human checkpoint: Mandatory legal review before any policy or product change. The agent tracks; counsel interprets.
• Build with: Schedule → official-source scraping → filtering agent → digest.

73. Literature and paper triage

• Trigger: New results appear for a saved query on a preprint or journal feed.
• Action: Screen abstracts against your inclusion criteria, cluster by method, and rank by relevance to a stated question.
• Output: A shortlist with a reason per inclusion and per exclusion.
• Human checkpoint: A researcher reads the shortlisted papers. The agent decides what to read, never what is true.
• Build with: Feed trigger → metadata retrieval → screening agent → report.

74. Survey and interview transcript coding

• Trigger: A batch of transcripts is uploaded.
• Action: Apply a defined codebook, tag excerpts, and surface excerpts that fit no existing code as candidates for new ones.
• Output: A coded dataset with the uncoded remainder isolated.
• Human checkpoint: The researcher validates the coding on a sample and owns any codebook change.
• Build with: File trigger → codebook in memory → coding agent → structured output.

75. Market and category field refresh

• Trigger: Quarterly schedule.
• Action: Rebuild the competitor and adjacent-player map from public sources, and diff it against last quarter.
• Output: An updated field with a changelog of entrants, exits, and repositioning.
• Human checkpoint: None for the map. Any strategic conclusion is a human one.
• Build with: Schedule → search and scrape → structuring agent → document plus stored snapshot.

76. Dataset profiler

• Trigger: A new dataset lands in the analysis folder.
• Action: Profile column types, null rates, distributions, and outliers, and list the questions the data can and cannot answer.
• Output: A profile report with caveats stated first.
• Human checkpoint: None. It describes; it does not conclude.
• Build with: File trigger → code execution for the statistics → writing agent for the narrative → report.

77. Hypothesis-to-query translator

• Trigger: An analyst states a question in plain language.
• Action: Translate it into a query against the documented schema, explain the join logic, and run it read-only against a limited row budget.
• Output: The query, its explanation, and a result sample.
• Human checkpoint: Analyst reviews the query before any result is used in a decision. Read-only credentials, always.
• Build with: Chat trigger → schema documentation retrieval → query agent → read-only database tool.

78. Earnings and public filing digest

• Trigger: A watched company publishes a filing or transcript.
• Action: Extract the segments, guidance language, and risk factor changes relative to the prior filing.
• Output: A digest that quotes the source rather than paraphrasing numbers.
• Human checkpoint: None for internal reading. Never restate a figure without quoting it from the filing.
• Build with: Filing feed trigger → document retrieval → extraction agent → digest.

79. Customer research synthesizer

• Trigger: A research round closes.
• Action: Combine interview transcripts, survey results, and product analytics into findings where each is supported by at least two independent sources.
• Output: A findings document with the evidence trail per finding.
• Human checkpoint: Researcher owns the findings. The two-source rule is enforced by the workflow, not by asking nicely.
• Build with: Manual trigger → multi-source retrieval → synthesis agent → validation step → document.

80. Prior-work checker before a build

• Trigger: A new project brief is filed.
• Action: Search internal documents, repositories, and past project records for anything solving the same problem.
• Output: A prior-art note listing what already exists and how close it is.
• Human checkpoint: None. This one is pure upside and almost nobody builds it.
• Build with: Form trigger → internal search across wiki, code, and drive → summarizing agent → note.

---

Personal work (81–90)

Single-user automations are the best place to learn agent design, because you are the reviewer, the blast radius is your own calendar, and you find out within a day whether the thing is actually useful. If you have never built an agent, build one from this group first — the tutorial walks the same path.

81. Morning brief

• Trigger: Weekday schedule, before you start.
• Action: Pull today's calendar, overnight mentions, blocked items assigned to you, and anything you said you would do yesterday.
• Output: A single message, short enough to read standing up.
• Human checkpoint: None. Read-only.
• Build with: Schedule → calendar, chat, and task connectors → summarizer → message.

82. Inbox triage into a decision queue

• Trigger: Every thirty minutes during working hours.
• Action: Classify new mail into reply-needed, read-later, delegate, and archive, and draft nothing yet.
• Output: A sorted queue with counts.
• Human checkpoint: Auto-archiving is safe for known-noise senders only. Everything else waits for you.
• Build with: Schedule → mail connector → classification agent → labels.

83. Reply drafting in your voice

• Trigger: You flag a thread as reply-needed.
• Action: Read the thread and your prior replies to similar threads, then draft a response matched to your register and length habits.
• Output: A draft in the drafts folder.
• Human checkpoint: You send. Always. This is worth restating because the temptation to remove it grows with how good the drafts get.
• Build with: Label trigger → thread retrieval + writing samples in memory → drafting agent → draft.

84. Meeting preparation and follow-through

• Trigger: A meeting ends.
• Action: Extract your own commitments from the transcript and put them in your task list with the context and the promised date.
• Output: Tasks in your own system, sourced to the moment in the transcript.
• Human checkpoint: Quick confirm. Extraction on your own commitments is high-precision; on other people's, it is not.
• Build with: Transcript webhook → extraction agent → task tool.

85. Reading pile summarizer with a recall test

• Trigger: You save a link.
• Action: Extract the article, produce a summary at the length you specify, and store it against the topic in memory so later questions can retrieve it.
• Output: A summary in your notes, linked to the original.
• Human checkpoint: None. Keep the original link so you can always check the summary.
• Build with: Bookmark webhook → scrape tool → summarizing agent → notes plus memory.

86. Weekly review assembler

• Trigger: Friday afternoon.
• Action: Gather what you shipped, what slipped, and what you committed to next week from calendar, tasks, and code history.
• Output: A pre-filled weekly review you edit rather than write.
• Human checkpoint: You write the reflection. The agent gathers the facts.
• Build with: Schedule → multi-source queries → assembly agent → document.

87. Travel and logistics packet

• Trigger: A trip is booked.
• Action: Assemble confirmations, transfer times, local details, and the meeting schedule into one offline-readable document.
• Output: A trip packet.
• Human checkpoint: Verify the times against the confirmations. Timezone arithmetic is a classic silent failure.
• Build with: Booking email trigger → extraction → assembly agent → document.

88. Personal knowledge base curator

• Trigger: Weekly schedule.
• Action: Find notes with no links, duplicate topics, and open questions you never answered, then propose merges and follow-ups.
• Output: A curation list.
• Human checkpoint: You approve merges. Never let it edit your notes directly.
• Build with: Schedule → notes API → analysis agent → list.

89. Deep work defender

• Trigger: New meeting invitations arrive.
• Action: Check them against your stated focus blocks and priorities, and draft a decline or a reschedule proposal where they conflict.
• Output: A drafted response and a proposed alternative slot.
• Human checkpoint: You decide. Automated declines are a social hazard regardless of how right they are.
• Build with: Calendar webhook → rules plus priorities in memory → drafting agent → draft.

90. Recurring-decision log

• Trigger: You make a decision and note it in a specific place.
• Action: Structure it — the decision, the alternatives, the reasoning, the assumptions, and the date to revisit — and schedule the revisit.
• Output: A decision record plus a calendar reminder.
• Human checkpoint: None. The value comes from the revisit, which is why the scheduling matters more than the writing.
• Build with: Note trigger → structuring agent → document plus calendar.

---

Monitoring (91–100)

Monitoring automations fail in a specific and predictable way: they become noise, get muted, and then miss the one thing that mattered. Design every one of these to be silent by default, to consolidate rather than fire per-event, and to state clearly what it checked and found nothing wrong with.

91. Site and endpoint availability watch

• Trigger: Every minute from multiple regions.
• Action: Check critical endpoints for status, latency, and response shape, and confirm across regions before alerting.
• Output: An alert on confirmed failure only, with the regional evidence.
• Human checkpoint: None. Alert routing is human-configured; escalation policy is not a model decision.
• Build with: Schedule → HTTP checks → confirmation logic → alert channel.

92. Certificate, domain, and key expiry watch

• Trigger: Daily schedule.
• Action: Enumerate certificates, domains, and API credentials with known expiry dates and check the remaining window.
• Output: Escalating notices at sixty, thirty, and seven days.
• Human checkpoint: Renewal is human unless your certificate automation already owns it end to end.
• Build with: Schedule → inventory list → check step → notifications.

93. Cost anomaly watch

• Trigger: Daily schedule.
• Action: Compare cloud, API, and model spend against the trailing baseline per service, and attribute any spike to the specific resource or key.
• Output: An alert naming the resource and the delta.
• Human checkpoint: None for the alert. Never let it terminate resources; a runaway cost and a running production service look identical from the billing API.
• Build with: Schedule → billing APIs → comparison logic → alert.

94. Broken link and dead redirect sweep

• Trigger: Weekly schedule.
• Action: Crawl the site and documentation, follow every outbound and internal link, and record failures with the page that contains them.
• Output: A fix list grouped by containing page.
• Human checkpoint: None for the report. Fixes go through the normal content process.
• Build with: Schedule → crawler → report.

95. Brand and executive mention watch

• Trigger: Continuous polling of search, social, and forum sources.
• Action: Filter to genuine mentions, classify sentiment and urgency, and route only what needs a response.
• Output: A routed mention with the source link and a suggested owner.
• Human checkpoint: Every public response is written and sent by a person. This is not negotiable at any level of confidence.
• Build with: Polling schedule → source connectors → classification agent → routing.

96. Third-party status dependency board

• Trigger: Continuous polling of your vendors' status pages.
• Action: Map each vendor incident to the internal features that depend on it, and alert only the owning team.
• Output: A dependency-aware incident notice.
• Human checkpoint: None. The dependency map is maintained by humans and should be reviewed quarterly.
• Build with: Polling → status endpoints → dependency map in memory → targeted alert.

97. Data freshness and pipeline SLA watch

• Trigger: At each dataset's expected arrival time.
• Action: Verify the data arrived, that row counts are within the expected band, and that key columns are not newly null.
• Output: A freshness alert naming the dataset and the specific check that failed.
• Human checkpoint: None for the alert. Never let it auto-rerun a pipeline; duplicate loads are worse than late data.
• Build with: Per-dataset schedule → warehouse queries → check step → alert.

98. Security posture drift watch

• Trigger: Daily schedule.
• Action: Compare current cloud configuration, public bucket exposure, and identity policies against the approved baseline.
• Output: A drift report listing each deviation and when it appeared.
• Human checkpoint: Mandatory for every remediation. Automated rollback of a security setting can undo a deliberate, approved change during an incident.
• Build with: Schedule → cloud config APIs → diff against stored baseline → report.

99. Model and prompt output drift watch

• Trigger: Daily schedule over a fixed evaluation set.
• Action: Run a held-out set through every production agent and score outputs against known-good references.
• Output: A quality report per agent, with score deltas over time.
• Human checkpoint: None for the report. Any agent that regresses past your threshold should be disabled by a person, not by itself.
• Build with: Schedule → evaluation set in storage → agent invocation → scoring step → dashboard.

100. Automation health watch

• Trigger: Daily schedule.
• Action: Check every automation you have built for last-run time, error rate, approval queue depth, and whether anyone has approved anything recently.
• Output: A health report, including a list of automations producing output nobody reads.
• Human checkpoint: None for the report. Retiring an automation is a human decision, and you should be making it regularly.
• Build with: Schedule → your platform's execution history → analysis agent → report.

This last one deserves more attention than it usually gets. A queue of drafts nobody reviews is not an automation, it is a backlog with a scheduler attached. The health watch is how you find those before they find you.

---

Effort and risk matrix

Effort is build-and-maintain cost. Risk is what happens when the agent is confidently wrong. Position determines how you should sequence work — not whether an idea is good.

	Low risk	High risk
Low effort	Build first. 6, 12, 22, 26, 47, 76, 81, 85, 91, 92, 94, 96 — read-only, single-source, immediately useful. This quadrant is where you learn the platform without exposure.	Build with a hard gate. 29, 44, 52, 56, 95 — deceptively simple to wire up, and every one of them can reach a customer or an employee. The build is an afternoon; the approval design is the actual work.
High effort	Build second. 3, 9, 23, 28, 61, 66, 70, 71, 75, 79, 99, 100 — multi-source, needs iteration on quality, but a bad output costs a rewrite. Most of the durable value on this list lives here.	Build last, or not at all. 31, 34, 37, 38, 40, 50, 60, 63, 68, 98 — cross-system writes, irreversible operations, security-relevant state. Run in dry-run mode for weeks. Some of these should stay dry-run permanently.

Two things this matrix will not tell you. It cannot rank ideas by value to your business, because that depends entirely on which task is currently eating your week. And it cannot tell you that a low-risk item is worth building — plenty of low-risk automations are also low-value, and the health watch at item 100 exists to catch them.

---

Seven starter builds

If you are starting from zero, these seven produce visible value quickly and teach the primitives you need for everything else. Build them in this order.

1. Morning brief (item 81). Read-only, single user, three connectors. It teaches scheduled triggers, multi-tool retrieval, and output formatting. You will know within three days whether the summarization quality is where you need it, and tuning it teaches you more about prompt design than any guide.

2. Competitor page-change watcher (item 6). Adds persistent state. The agent must store yesterday's snapshot and compare, which is your introduction to memory as a design element rather than a feature. Also your first encounter with the discipline of staying silent when nothing changed.

3. Ticket triage and tagging (item 21). Your first classification task against a fixed label set, and your first real measurement problem. Run it in shadow mode — predicting labels without applying them — and compare against what humans chose. That comparison is the pattern for validating every classifier you build afterward.

4. Pre-call briefing pack (item 12). Multi-system retrieval assembled into one artifact under time pressure, since it fires fifteen minutes before a meeting. It teaches parallel tool calls and graceful degradation when one source is slow or empty. A brief that arrives late is worthless, which forces you to think about timeouts.

5. Suggested reply with cited sources (item 22). Retrieval-augmented generation with a hard sourcing requirement, delivered as a draft rather than a send. This is the template for most of the writing automations on this list: retrieve, draft, cite, hand to a human. Get the citation validator right here and you will reuse it a dozen times.

6. Pull request summarizer (item 61). Your first automation on structured technical input with an objectively checkable result. Engineers will tell you immediately when it is wrong, which is the fastest feedback loop available. It also introduces webhook triggers on external systems.

7. Automation health watch (item 100). Build this seventh, once you have six things running. It closes the loop: it tells you which of the previous six are actually being used, which are erroring silently, and which are producing drafts that sit unreviewed. Most people never build this and end up with a graveyard of automations they are afraid to turn off.

Once these seven are stable, pick the highest-cost recurring task in your own week and find its number above. For the platform mechanics of wiring triggers to agents to tools, the build tutorial covers the specifics, and the tools directory covers the connector layer.

---

Where these break

Every automation on this list has a characteristic failure. Knowing which one applies to your build is most of the design work.

Silent degradation. An agent that quietly gets worse — a source page changes structure, a model version shifts, an API starts returning partial data — keeps producing output that looks correct. Nothing errors. Nobody notices for weeks. This is the reason item 99 and item 100 exist, and the reason every automation should log what it checked, not just what it found.

Approval theater. A human is nominally in the loop but approves in bulk without reading, because the queue is forty items and the last thirty were fine. The checkpoint exists on the org chart and not in reality. The fix is volume control: an automation producing more review than a person can genuinely do is misconfigured. Cut the volume or remove the checkpoint honestly and accept the risk explicitly.

Wrong-confidence writing. Generative systems produce the same fluent, assured prose whether they are summarizing a document they read or filling a gap they invented. Sourcing rules must be enforced as validation steps in the workflow, not as instructions in a prompt. A step that drops unsourced claims is worth more than any amount of asking the model to be careful.

Trigger storms. An automation that fires per-event will, on a bad day, fire two thousand times. Rate limits get hit, costs spike, and the alert channel becomes unreadable. Consolidate, debounce, and cap. Every scheduled or event-driven automation needs a maximum-runs-per-window guard.

Irreversibility. Sends, payments, deletions, migrations, access revocations, and public posts cannot be undone by an apology. Any workflow that reaches one of these needs a human between intent and execution. This is the line I do not move regardless of how well the agent has performed.

Scope creep into judgment. The reliable pattern is: agents gather, extract, draft, and check; humans decide. Automations tend to drift across that line gradually — first the agent summarizes the debrief, then it ranks the candidates, then someone starts treating the ranking as the decision. Re-read your automations quarterly and ask which ones have quietly started deciding.

Where approval is mandatory, without exception

No amount of measured accuracy earns autonomy on these:

• Money leaving the business — payments, refunds, credits, purchase orders (29, 34, 41, 44, 48).
• Anything sent to a customer or the public under your name (7, 10, 14, 35, 95).
• Employment decisions and anything touching leave, accommodation, compensation, or conduct (54, 56).
• Production access grants and security configuration changes (38, 98).
• Irreversible data operations — schema migrations, merges, deletions (37, 68).
• Contractual and regulatory commitments, including security questionnaire answers (16, 36, 72).

---

FAQ

What is the difference between an AI automation and a traditional workflow automation?
Traditional automation executes a fixed set of rules against structured input: if field X equals Y, do Z. AI automation adds a step that handles unstructured input or ambiguous judgment — reading a transcript, classifying an intent, drafting prose. The rest of the workflow around it should still be deterministic. Most of the ideas above are ninety percent conventional automation with one model-powered step in the middle, and that ratio is a feature.

How many of these can run without a human?
Roughly the read-only ones — briefings, digests, reports, alerts, and research that never writes back to a system of record. That is something like a third of this list. Every automation that writes to a record, sends to a person, or spends money should keep its checkpoint. Some earn autonomy after a measured burn-in period; the mandatory list above never does.

Where should I actually start?
With the task you personally dread most, provided it appears on this list with a low-effort, low-risk position. Building the theoretically highest-value automation first is the standard mistake — it is usually the complex cross-system one, it takes three weeks, and you have learned nothing about the platform along the way. Build the morning brief. It is useful on day one.

How do I know an automation is working?
Two measurements, both boring. First, does the output get used — read, approved, edited, acted on — or does it accumulate unread? Second, when a human reviews it, how often do they change something substantive? A draft that is edited every time is doing less than it appears. Item 100 is how you collect the first measurement; you have to instrument the second yourself.

Should each of these be one agent or several?
Start with one agent and the smallest set of tools it needs. Split into multiple agents when a step needs genuinely different context or when parts can run in parallel with no dependency between them — the research batch in item 17 is a good example, since each account can be researched independently. Splitting early creates coordination overhead that buys nothing.

How do I stop an automation from producing noise?
Design it to be silent by default. It reports only when something changed, consolidates per-owner rather than per-event, and includes a cap on runs per window. The competitor watcher in item 6 and the backlog watchdog in item 26 are both built around this, and it is the single most common design failure in the monitoring group.

What does an automation cost to run?
It depends on model choice, invocation frequency, and how much context each run pulls in — I am not going to give you a number that would be wrong for your setup. What I will say is that the cost driver is almost always context volume multiplied by frequency, not the sophistication of the task. A cheap-looking automation that polls every minute and pulls a large context each time will outspend a complex one that runs weekly. Item 93 exists precisely because people discover this on their invoice.

Can I combine several of these into one workflow?
Yes, and the handoff-packet pattern in item 20 is the good version of this: one trigger, several coordinated steps, one artifact. The bad version is a single workflow that tries to own an entire department, because when one step breaks you cannot tell which, and you cannot change anything without risking everything. Keep workflows scoped to one artifact and one trigger.

Which of these need memory?
Anything that compares against a previous state — the page-change watcher, the drift watches, the reconciliation jobs — needs stored snapshots. Anything that should sound like a specific person or follow a house style needs stored examples. Everything else can run stateless, and stateless is easier to debug.

Where do I see these running as complete examples?
Working department-by-department builds are in use cases, the strategic framing for where agents fit is in AI agent use cases, the step-by-step build is in how to build an AI agent, and the connector and tooling layer is covered in the 100 best AI agent tools.

Build the automation in AGNT

AGNT is made for the trigger → agent → tool → approval → output pattern used throughout this list. Build it as a visual workflow when the path should be repeatable; use an agent when judgment is required; use a goal when the work must continue and re-plan. Download AGNT and build the first low-risk automation locally.

---

What to do with this list

Do not build fifty of these. Build one, use it for two weeks, and see whether you would miss it if it stopped. That single question filters better than any prioritization framework, and it is the reason the starter list above is seven items rather than thirty.

The organizations getting real value from AI automation in 2026 are not the ones with the most agents running. They are the ones who put a person at every point where a mistake would be expensive, kept the volume low enough that the person actually looks, and retired the automations nobody was reading. That is unglamorous, and it is the whole discipline.

Pick your number. Build it this week.