Agents

Get started with agent development using starter manifests.

48 agents

What this agent manifest does Autonomous industry briefing — scans, filters, ranks, and delivers a cited news summary. Build an agent that takes an industry or sector and delivers a concise, cited briefing of the most relevant recent news and trends. The agent runs several Bing-grounded searches — industry news, trend analysis, specific company or topic queries — deduplicates results, ranks by relevance and authority, and formats the output as a scannable briefing with top stories, a trend-watch section, and quick hits. Facts are Bing-grounded with source citations, reflecting public information available at the time of the search. This is a single-tool autonomous scan with editorial filtering pattern using numbered-rule prompt structure. With only one tool, the prompt carries all the complexity: the search strategy (at least four distinct queries), deduplication logic, relevance ranking, and the line between editorial coverage and promotional content. Numbered rules make the agent's filtering decisions transparent and repeatable. The prompt handles sparse news periods (report honestly rather than pad) and developing stories with conflicting details (note the uncertainty rather than pick a side). Because it runs autonomously, the briefing is a draft for a person to read and act on. This pattern applies anywhere an agent needs to scan a source, apply editorial judgment to filter and rank, and deliver a curated summary. Common scenarios for this pattern: Technology trend monitoring for R&D teams Competitor product-launch tracking Open-source ecosystem change monitoring Market-signal detection for strategy teams Conference and event coverage summaries The tools it uses This manifest uses: Bing Web Search Use this agent manifest to understand How to build autonomous agents using numbered rules prompt structure for briefing / report output.

Competitive Landscape Researcher

What this agent manifest does Autonomous multi-source research, structured into a formatted report — no human checkpoints. Build an agent that takes a list of competitors or a market segment and produces a structured landscape report in one pass. It runs Web Search queries per competitor to gather recent developments, public financials, product launches, and positioning, then hands the raw findings to code interpreter to build comparison tables, identify patterns across the set, and compile a cited report. Findings reflect publicly available information at the time of the search. This is an autonomous gather → process → deliver pattern using markdown-header prompt structure. Each phase has explicit completion criteria so the agent moves through research, structuring, and compilation without waiting for input. The scope boundaries hold it to facts — no editorializing about who's "winning," no speculation about unannounced plans — and the edge-case handling covers private companies with thin data, conflicting sources, and overly broad requests. As an autonomous agent, the report is a draft for the analyst to review. This pattern applies anywhere an agent pulls from multiple sources, synthesizes, and produces a structured deliverable in one pass. Common scenarios for this pattern: Due-diligence research Vendor or technology landscape assessments Market-entry analysis Internal competitive briefings for sales Industry benchmarking reports The tools it uses This manifest uses: Bing Web Search, code interpreter Use this agent manifest to understand How to build autonomous agents using markdown headers prompt structure for report / tables output.

Internal Policy Q&A

What this agent manifest does Plain-language answers to policy questions, sourced from SharePoint — one question, one answer, one reference. Build an agent that answers employee policy questions by searching SharePoint for the relevant document and responding in conversational language with a citation to the source. The agent handles the full range of lookup scenarios: clear answers get a 2-4 sentence summary, context-dependent answers include conditions and exceptions, ambiguous questions get the most likely interpretation with a follow-up offer, and out-of-scope questions get a polite redirect to the right person. This is a single-tool Q&A with exhaustive edge-case handling pattern using natural-language prompt structure. With one tool and a single-shot interaction, the prompt carries all the weight — there's no multi-step orchestration to fall back on. The instructions define exactly how to handle five distinct response scenarios, drawing precise boundaries around what the agent should and shouldn't do. The defining discipline is grounding: every answer comes from a found document and cites it, and "I couldn't find that" is a first-class answer rather than a guess. It never gives legal interpretation. This pattern applies anywhere an agent answers questions from a document library with no room for misinterpretation or hallucination. Common scenarios for this pattern: IT knowledge-base self-service Benefits and perks FAQ Vendor-contract terms lookup Product-documentation Q&A for customers Internal process and procedure reference The tools it uses This manifest uses: SharePoint Use this agent manifest to understand How to build single-shot agents using natural language prompt structure for narrative answer + reference output.

Trip Itinerary Designer

What this agent manifest does Collaborative trip planning — interviews you about travelers and preferences, builds a sequenced day-by-day itinerary. Build an agent that works like a travel-planning partner: it asks about your destination, travelers, budget, interests, and constraints, then uses Web Search for current options to build a sequenced day-by-day itinerary with activities, logistics, accommodation ideas, and cost estimates. It branches by context — solo business trips get efficiency-focused plans, family trips get varied pacing, short trips get ruthless prioritization, luxury trips get curated experiences. Options reflect publicly available information at the time of the search. This is a collaborative planning with multi-axis branching pattern using natural-language prompt structure. Rather than a simple if/else tree, the agent branches on several dimensions at once — traveler type, duration, budget tier, interest profile — all shaping the output. Memory retains the planner's preferences and past itinerary patterns across sessions. The prompt shows how natural-language instructions can encode complex branching that feels like a conversation. The guardrails are firm: it never books anything and treats all prices as approximate. This pattern applies anywhere an agent co-creates a structured plan through conversation, adapting to multiple user-provided variables. Common scenarios for this pattern: Corporate offsite agenda planning Conference or summit scheduling Relocation city-exploration guides Client-visit itineraries for account teams Team-retreat activity coordination The tools it uses This manifest uses: Bing Web Search, File search Use this agent manifest to understand How to build multi-turn agents using natural language prompt structure for day-by-day itinerary output.

Sales Metrics Dashboard Builder

What this agent manifest does Interactive dashboard building — describe the metrics you need, get formatted charts and tables from Fabric data. Build an agent that queries your Fabric workspace for sales data via a data agent, runs calculations in code interpreter, and delivers formatted charts, tables, and summary statistics. It works interactively: it clarifies metric definitions (is "revenue" bookings, ARR, or recognized?), confirms dimensions and time ranges, then runs a four-step pipeline — discovery, extraction, computation, formatting. Upload a CSV alongside Fabric data to enrich the analysis. This is an interactive requirements → multi-step data pipeline pattern using markdown-header prompt structure. The agent clarifies before building — a focused batch of questions about metrics, dimensions, granularity, and filters — which avoids the classic data-agent failure of computing the wrong metric confidently. Separating data discovery (what's available) from extraction (what's needed) makes it reliable on unfamiliar datasets. Calculations and any charts run in code, so the output is a draft to review. This pattern applies anywhere an agent clarifies analytical requirements through conversation, then runs a multi-step data pipeline. Common scenarios for this pattern: Marketing-funnel analysis from warehouse data Operational KPI dashboards from live sources Customer-cohort analysis for product teams Inventory-turnover and demand reporting Revenue-recognition and billing reconciliation The tools it uses This manifest uses: data agent, code interpreter Use this agent manifest to understand How to build multi-turn agents using markdown headers prompt structure for dashboard / tables output.

Brand Mention Monitor

What this agent manifest does Autonomous brand monitoring — scans, categorizes by sentiment and reach, escalates negative mentions. Build an agent that scans the web for mentions of your brand, products, or executives via Bing-grounded search, deduplicates results in code interpreter, classifies each mention by sentiment (positive, neutral, negative, crisis) and reach (high, medium, low), and delivers a prioritized summary. It follows different output paths based on what it finds: all-positive gets a standard summary, negative mentions get flagged with context, and crisis-level mentions trigger an urgent header with escalation considerations. It produces the report; the user decides what to do. Findings reflect public information available at the time of the search. This is an autonomous scan with conditional escalation pattern using numbered-rule prompt structure. The agent makes judgment calls without human input — classifying sentiment and reach and deciding whether something meets crisis criteria (3+ major outlets, legal allegations, viral discussion). Numbered rules create an unambiguous tree: scan → deduplicate → classify → route to the matching output path. The prompt handles brand-name ambiguity (exclude when uncertain), conflicting sources, and the line between editorial coverage and promotion. As an autonomous monitor, its output is a draft for the team to act on. This pattern applies anywhere an agent monitors a source, classifies by severity, and routes output based on what it discovers. Common scenarios for this pattern: Product-review monitoring across platforms Social-sentiment tracking for campaigns Competitor-announcement detection Press-coverage tracking for PR teams Community-forum issue escalation The tools it uses This manifest uses: Bing Web Search, code interpreter Use this agent manifest to understand How to build autonomous agents using numbered rules prompt structure for summary / report output.

Blog Post Drafter

What this agent manifest does Multi-stage content creation with gated approvals and persistent style memory. Build an agent that turns a topic brief into a publish-ready blog post through a three-stage conversation: research and outline, full draft, then iterative refinement. The agent uses Web Search to pull current information on the topic and File search to read any uploaded style guides or sample posts — matching voice and structure to the user's brand. With memory enabled, it retains voice preferences and structural patterns across sessions. Researched facts reflect public information available at the time of the search. This is a staged creation with human gates pattern using natural-language prompt structure. Each stage produces an intermediate output the user approves before the agent proceeds, which keeps subjective work aligned without over-constraining the writing. Memory adds a compounding layer — a persistent model of the user's preferences, so session 10 is meaningfully better than session 1. The instructions define just enough process to be reliable while leaving room to adapt tone, structure, and angle per piece. The originality rule is firm: research informs the post, but the writing is original. This pattern applies anywhere an agent produces subjective or creative deliverables that need human judgment at key decision points. Common scenarios for this pattern: Proposal and RFP draft workflows Executive communications and talking points Marketing copy and campaign messaging Product documentation and changelogs Internal announcements where tone matters The tools it uses This manifest uses: Bing Web Search, File search Use this agent manifest to understand How to build multi-turn agents using natural language prompt structure for narrative draft output.

Codebase Documentation Generator

What this agent manifest does Autonomous repo documentation — READMEs, module docs, and architecture summaries from real code analysis. Build an agent that analyzes a GitHub repository and generates review-ready documentation: a project-level README, module-level docs for each major directory, and an architecture summary mapping component relationships. The agent reads repo structure and source via GitHub, uses code interpreter to parse imports, function signatures, and class hierarchies, builds a dependency map, and generates documentation from what it actually finds in the code — not from assumptions about what the code should do. This is an autonomous analysis → generation → self-review pattern using markdown-header prompt structure. What makes it distinctive is the self-review step: before delivering, the agent validates its own output — every documented function exists in the repo, module names match real directories, no placeholder text remains. The prompt draws a hard line between describing what code does (acceptable) and assuming why it does it (not). Because it runs autonomously and produces code-adjacent artifacts, the output is a draft to review before committing. Edge cases cover empty repos, multi-language codebases, and conflicts between existing docs and actual code. This pattern applies anywhere an agent analyzes a complex system, generates structured documentation, and validates its own output before delivery. Common scenarios for this pattern: API reference generation from source Infrastructure documentation from configuration files Data-pipeline documentation from DAG definitions Onboarding guides generated from repo structure Architecture notes from code patterns The tools it uses This manifest uses: GitHub, code interpreter Use this agent manifest to understand How to build autonomous agents using markdown headers prompt structure for documentation files output.

Store Operations Handbook Assistant

What this agent manifest does Plain-language answers to operations questions, sourced from your actual store documents. Build an agent that answers store-associate questions — "How do I process a return without a receipt?", "What's the weekend closing checklist?" — by searching SharePoint and a knowledge index for the relevant procedure and responding conversationally with a reference to the source. It asks the associate's role and store location at the start, then branches: floor associates get customer-facing procedures, shift leads get operational checklists, store managers get inventory and reporting workflows. This is a role-aware document Q&A with branching pattern using natural-language prompt structure. A brief intake conversation classifies the user, and that context shapes every later answer without re-asking. The decision tree is driven by role and location — the same question gets a different answer depending on who's asking. The prompt keeps the assistant conversational while staying within what the documents say, with clear boundaries for out-of-scope questions and a discipline of always citing the source document. This pattern applies anywhere an agent answers from a document library while adapting to who's asking. Common scenarios for this pattern: Field-technician procedure lookup Franchise operations Q&A across locations Warehouse shift-handoff reference Partner-portal self-service support Multi-region office-policy lookup The tools it uses This manifest uses: SharePoint, Azure AI Search Use this agent manifest to understand How to build multi-turn agents using natural language prompt structure for narrative answer + reference output.

Executive Weekly Digest

What this agent manifest does Single-shot weekly briefing — metrics from Fabric, updates from SharePoint, context from Bing, one document. Build an agent that produces a polished weekly executive digest by pulling business metrics from Fabric via a data agent, surfacing internal updates from SharePoint, and adding external context from Bing-grounded news. The output is one scannable document: executive summary, performance snapshot with period-over-period comparisons, prioritized internal updates, relevant external developments, a look-ahead, and a consolidated list of items needing attention. One input, one deliverable. This is a three-source synthesis with editorial hierarchy pattern using XML prompt structure. Beyond aggregation, the agent applies editorial judgment to organize by priority — action-required items surface to the top, routine updates drop to reference. The XML structure defines precise orchestration: Fabric first (internal metrics), SharePoint second (internal updates), Bing third (external context), then synthesis. As a single-shot, multi-source agent, its output format is tightly specified, and the digest is a draft for the executive (or their chief of staff) to review. External facts reflect public information available at the time of the search. This pattern applies anywhere an agent synthesizes multiple internal and external sources into a prioritized executive-facing document. Common scenarios for this pattern: Board-meeting preparation packets Investor-update drafts Department-level weekly summaries Program-management status rollups Cross-functional initiative tracking The tools it uses This manifest uses: data agent, SharePoint, Bing Web Search Use this agent manifest to understand How to build single-shot agents using xml tags prompt structure for report / summary output.

RFP Response Drafter

What this agent manifest does Drafts RFP responses from your past proposals and company docs — and flags the gaps for human input. Build an agent that reads an uploaded RFP, identifies the required sections, searches your past proposals and company documents in Azure AI Search and SharePoint, and drafts a structured response. The agent branches by content type within the RFP: factual questions are pulled directly from the knowledge base, narrative sections are adapted from past successful proposals, case-study requests get the strongest matching examples, and anything not in the knowledge base is flagged "[HUMAN INPUT REQUIRED]" with context for your team. This is a document generation with per-section decision routing pattern using XML prompt structure. Rather than a linear flow, the agent makes a content-type decision for each section and follows a different path — factual lookup, narrative adaptation, evidence matching, or human escalation. It's one of the more complex decision trees in the catalog, inside a single-shot workflow. The prompt enforces careful sourcing: no fabricated capabilities, no drafted pricing, and a coverage summary showing which sections have strong source material versus thin coverage. The draft always goes to a human before submission. This pattern applies anywhere an agent generates a multi-section document where different sections need different generation strategies. Common scenarios for this pattern: Grant-application drafting from organizational history Compliance-questionnaire completion from policy libraries Vendor-onboarding form population from company records Self-assessment reports from existing documentation Partnership-proposal assembly from capability libraries The tools it uses This manifest uses: Azure AI Search, SharePoint Use this agent manifest to understand How to build single-shot agents using xml tags prompt structure for structured response document output.

Product Listing SEO Optimizer

What this agent manifest does Keyword research, listing audit, and optimized copy — with direct updates to your store admin after you approve. Build an agent that researches trending search terms for your product category via Web Search, audits your current listings through your e-commerce admin via browser automation, and generates optimized titles, descriptions, and keyword tags. It presents all recommendations in a comparison table for your approval before changing anything on your live store. Upload a product export to audit in bulk, or work listing by listing. Keyword research uses publicly available information only. This is a research → audit → recommend → implement pattern using numbered-rule prompt structure. The agent doesn't just analyze — it can apply approved changes through browser automation, making the workflow end-to-end. The prompt builds in a mandatory approval gate between recommendation and implementation: it presents the comparison table and waits for confirmation before touching the live store. Because it acts on a live system, a person reviews and authorizes every change, and the agent never touches pricing, inventory, or images. The instructions enforce natural-sounding copy over keyword stuffing. This pattern applies anywhere an agent researches best practices, audits current state, recommends improvements, and implements approved changes in a live system. Common scenarios for this pattern: Knowledge-base article SEO optimization Job-listing optimization for recruiting platforms App-store listing and metadata improvement Internal wiki discoverability updates Digital-asset metadata and tagging The tools it uses This manifest uses: browser automation, Bing Web Search Use this agent manifest to understand How to build multi-turn agents using numbered rules prompt structure for tables + applied updates output.

Document Standards Reviewer

What this agent manifest does Systematic document review against your uploaded checklist — Pass/Partial/Fail per criterion with coaching suggestions. Build an agent that reviews documents against your uploaded quality standards or checklist. For each criterion it assesses Pass, Partial, Fail, or N/A — with evidence for each score and a specific fix suggestion for anything that doesn't pass. The agent branches by document type: proposals are checked for completeness and executive-summary quality, technical specs for terminology consistency and architecture references, policy docs for versioning and approval chains, reports for source attribution and summary-to-findings alignment. This is a document-driven evaluation with type-based branching pattern using natural-language prompt structure. The uploaded checklist becomes the agent's evaluation framework — it applies your standards, not its own opinions. The coaching tone balances thoroughness with encouragement: the agent ranks fixes by impact and frames them constructively, but never softens a Fail to be nice. The defining discipline is that it suggests fixes rather than rewriting the document, so the author learns the standard. Memory lets it carry your checklist and track recurring issues across reviews. This pattern applies anywhere an agent evaluates a document against structured criteria that vary by type. Common scenarios for this pattern: Technical design-review checklists Brand and style-guide compliance checks Proposal quality gates before submission SOW and contract structure verification Internal publication-readiness reviews The tools it uses This manifest uses: File search, SharePoint Use this agent manifest to understand How to build multi-turn agents using natural language prompt structure for scored review report output.

Release Notes Generator

What this agent manifest does Structured release notes from Git history — categorized, formatted, and ready to publish in one pass. Build an agent that takes a release tag, branch, or date range and produces categorized release notes from your GitHub repo's actual history. It reads merged PRs, commit messages, and tags via GitHub, then uses code interpreter to categorize changes and format them. The output is a ready-to-publish document with the standard sections — Breaking Changes (with migration notes), Features, Bug Fixes, Performance, Documentation, Internal — each item linked to its PR and attributed, plus a contributors list. Upload a release template and it matches your format. This is a read → categorize → format in one shot pattern using markdown-header prompt structure. Because it's single-shot with no mid-flow interaction, the instructions are especially precise about input handling — the agent must infer the correct comparison scope (tag-to-tag, branch diff, date range) from whatever it's given and proceed without clarification. It works from PR titles, labels, and descriptions rather than raw code diffs, and handles edge cases like undescribed PRs, very large scopes, and empty sections. Categorization runs in code, so the notes are a draft to review before publishing. This pattern applies anywhere an agent reads structured data from a system, categorizes it by rules, and produces a formatted document in a single pass. Common scenarios for this pattern: Changelog generation for SaaS products Deployment summaries for ops teams Migration guides from version diffs Audit-trail documentation from commit history Dependency-update summaries The tools it uses This manifest uses: GitHub, code interpreter Use this agent manifest to understand How to build single-shot agents using markdown headers prompt structure for categorized release notes output.

Knowledge Base Q&A Assistant

What this agent manifest does Ask a question; get an answer grounded in your knowledge index, with citations — or an honest "not found.". Build an agent that answers questions strictly from an Azure AI Search index — an internal wiki, product docs, an engineering runbook, an HR FAQ — and cites the documents it used. It retrieves the most relevant passages for the question, answers from those passages only, and attaches the sources so the reader can verify. When the index doesn't contain the answer, it says so rather than reaching for general knowledge. This is a single-tool retrieve → grounded answer pattern using natural-language prompt structure. The defining design decision is loyalty to the index: the agent treats retrieved passages as its only source of truth, cites them, and refuses to fill gaps from its own training. Natural language suits the conversational Q&A surface, and the instructions handle the failure modes that sink retrieval agents — no good match (say so), partial match (answer what you can, flag the rest), ambiguous question (ask, or answer the most likely reading and name it). This pattern applies anywhere there is a trusted document set and people asking it questions. Common scenarios for this pattern: Internal wiki / handbook Q&A Product and API documentation assistants Support knowledge-base lookup Engineering runbook and on-call helpers Benefits / policy FAQ (non-regulated) The tools it uses This manifest uses: Azure AI Search Use this agent manifest to understand How to build single-shot agents using natural language prompt structure for cited narrative answer output.

Web Fact-Checker

What this agent manifest does Paste a set of claims; get each one checked against public sources — supported, contradicted, or unverifiable, with links. Build an agent that takes a block of factual claims — a draft paragraph, a list of assertions, a summary — and checks each one against current public information. It uses Web Search to find supporting or contradicting sources, then returns a per-claim verdict with citations, so you can see at a glance which statements stand up and which need a rewrite. Results reflect public information available at the time of the search. This is a single-tool verify → verdict table pattern using XML-tag prompt structure. The tags structure the loop — <extract the claims, <verify each against sources, <report the verdicts — keeping verification disciplined and one claim at a time. The defining design decision is making unverifiable a first-class verdict alongside supported and contradicted: when the agent can't find a credible source, it says so rather than rationalizing weak evidence into a "supported," which is the failure mode that makes fact-checkers worse than useless. Edge cases cover opinion vs. fact, claims that hinge on a date, and sources that disagree. This pattern applies anywhere claims need grounding before they ship. Common scenarios for this pattern: Pre-publication fact-checking Verifying claims in a draft or summary Sanity-checking research findings Auditing marketing or comms copy for accuracy Vetting forwarded "facts" before repeating them The tools it uses This manifest uses: Bing Web Search Use this agent manifest to understand How to build single-shot agents using xml tags prompt structure for claim-by-claim verdict table output.

Document / Spec Summarizer

What this agent manifest does Upload a long document; get a TL;DR, the key points, and the open questions — grounded only in the text. Build an agent that takes one uploaded document — a PRD, a contract overview, a research paper, an onboarding packet — and returns a structured summary: a three-line TL;DR, the key points grouped by theme, and the open questions a careful reader would flag. It uses File search to read only the document you provide, pointing to the section behind each point so nothing is asserted that isn't in the text. This is a single-tool read → structured digest pattern using natural-language prompt structure. The defining design decision is a hard line between extraction (what the document says) and interpretation (what it might mean): the agent does the first and routes the second into open questions rather than guessing. That boundary is what keeps a summarizer trustworthy. The instructions also handle the failure modes — long documents (summarize per section, then synthesize), missing or contradictory content (name it, don't paper over it), and inputs that aren't really prose (a form, a raw sheet — say so). This pattern applies anywhere an agent needs to read one source and distill it without losing fidelity. Common scenarios for this pattern: Product / engineering spec reviews Contract or SOW overviews (non-legal-advice) Research-paper and report digests Onboarding and policy packet reads Long proposal or meeting-doc triage The tools it uses This manifest uses: File search Use this agent manifest to understand How to build single-shot agents using natural language prompt structure for structured summary output.

Meeting Notes Summarizer

What this agent manifest does Drop in a transcript; get a clean summary with decisions, action items, and owners — only the ones actually stated. Build an agent that turns a meeting transcript or raw notes into a structured summary: the key points, the decisions made, and the action items with owners and any due dates the notes mention. It uses File search to read the source, then extracts each element under a strict contract, so the output is something attendees and absentees can both trust as a record of what was actually said. This is a single-tool extract → structured summary pattern using a numbered-rules prompt structure. Numbered rules suit extraction because each rule is an auditable contract — what counts as a decision, how owners are attributed, what to do when an action has no owner. The defining discipline is attribution fidelity: the agent assigns an owner only when the notes name one and marks the rest "unassigned," because a confidently mis-assigned action item erodes trust in the whole summary. Edge cases cover rambling discussion with no decision, conflicting statements, and notes too sparse to summarize. This pattern applies anywhere a conversation needs to become a reliable record. Common scenarios for this pattern: Meeting and standup recaps Decision logs for absent stakeholders Action-item extraction and follow-up Interview and user-research note rollups Turning a long call into a one-screen summary The tools it uses This manifest uses: File search Use this agent manifest to understand How to build single-shot agents using numbered rules prompt structure for structured summary output.

Codebase Q&A Assistant

What this agent manifest does Ask how a repo works; get an explanation grounded in the code, with file and line pointers — not guesses. Build an agent that answers questions about how a codebase works — "where is X handled?", "what does this module do?", "trace the request flow" — grounded in the repository itself. It uses GitHub to read the relevant files, then explains in plain technical language with pointers to the files and lines behind each statement, so a new contributor can follow the explanation straight into the code. This is a single-tool read → grounded explanation pattern using markdown-header structure. Headers organize the answer (Summary, How it works, Where to look) for technical readers who scan. The defining design decision mirrors a good retrieval agent applied to code: explain only what the code shows, cite file and line, and when behavior depends on something not in view — config, a runtime dependency, an external service — name that gap rather than inventing the behavior. Edge cases cover very large repos (scope to paths), generated or vendored code, and questions the code can't answer. This pattern applies anywhere people need to understand code they didn't write. Common scenarios for this pattern: Onboarding to an unfamiliar repository "Where is X handled?" navigation Dependency and call-flow tracing API-surface overviews Pre-contribution orientation The tools it uses This manifest uses: GitHub Use this agent manifest to understand How to build single-shot agents using markdown headers prompt structure for narrative + file references output.

Store Policy Q&A Assistant

What this agent manifest does Ask a store-policy question; get the answer straight from the ops handbook, with the policy reference — or an honest "not covered.". Build an agent that answers store associates' policy questions from the operations handbook. It uses SharePoint to retrieve the relevant policy and answers in plain language with a reference to the exact section, so an associate gets a fast, trustworthy answer on returns, opening and closing steps, safety procedures, or promo rules — without paging through the whole handbook. This is a single-tool retrieve → grounded answer pattern using a numbered-rules structure. Numbered rules suit a policy assistant because grounding has to be strict and auditable: answer only from the handbook, cite the section, and never improvise a policy. The defining design decision is making "this isn't covered in the handbook" a first-class, expected answer — on policy questions a confident guess is actively harmful, so the agent points the associate to a manager rather than inventing a rule. It also stays out of HR and legal advice, deferring those to the right people. Edge cases cover not-found questions and conflicting policy versions (surface both, don't pick). This pattern applies anywhere frontline staff need fast, grounded policy answers. Common scenarios for this pattern: Returns and exchange rules Opening and closing procedures Safety and incident steps Promotion and discount rules Day-to-day "what's our policy on…" questions The tools it uses This manifest uses: SharePoint Use this agent manifest to understand How to build multi-turn agents using numbered rules prompt structure for grounded answer + doc reference output.

Slide / Readout Drafter

What this agent manifest does Turn your notes into a slide-by-slide outline — a narrative spine, one idea per slide, talking points underneath. Build an agent that turns your raw material — notes, a project doc, last week's status — into a structured slide outline you can drop into a deck. It uses File search to pull the source content, then shapes it into a narrative: a title arc, one clear idea per slide, and the supporting talking points beneath each, so you start from a real story instead of a blank canvas. This is a single-tool transform → slide outline pattern using XML-tag prompt structure. The tags separate the phases — <gather the source, <shape the narrative, <format the slides — which keeps the agent from skipping straight to bullets without first deciding what the deck is arguing. The defining design decision is narrative over dump: the agent organizes the material into a through-line (situation → insight → ask) rather than mechanically listing whatever was in the notes. It drafts from your content and flags where the story has a hole rather than inventing a slide to fill it. This pattern applies anywhere source material needs to become a presented narrative. Common scenarios for this pattern: Status and project-update decks Readouts from a doc or analysis Proposal and pitch outlines All-hands or team-meeting decks Turning a written report into talking points The tools it uses This manifest uses: File search Use this agent manifest to understand How to build single-shot agents using xml tags prompt structure for slide outline / readout output.

SOP & Checklist Drafter

What this agent manifest does Turn rough reference notes into a step-by-step SOP or checklist — sequenced, with prerequisites and checks, gaps flagged. Build an agent that turns reference notes — a rough how-to, a transcript of "here's how I do it," scattered docs — into a standard operating procedure or checklist someone else can follow without you in the room. It uses File search to read the source material, then sequences it into ordered steps with prerequisites and verification checks, marking anything the source leaves unclear as a gap to fill rather than papering over it. This is a single-tool transform → ordered procedure pattern using natural-language structure. Natural language keeps the instructions readable, but they still impose a strict output contract: every step is an action, steps are ordered, prerequisites come first, and each major step gets a way to confirm it worked. The defining discipline is fidelity to the source — the agent drafts from what the notes actually say and flags missing or contradictory steps as TODOs, because an invented step in an SOP is worse than an acknowledged gap. It avoids safety-critical and regulated procedures. This pattern applies anywhere tacit know-how needs to become a followable procedure. Common scenarios for this pattern: Documenting a process that lives in one person's head Runbook and on-call procedure drafting New-hire and task onboarding checklists Recurring-task SOPs Handoff guides between teams The tools it uses This manifest uses: File search Use this agent manifest to understand How to build single-shot agents using natural language prompt structure for ordered procedure / checklist output.

Spreadsheet Insights Explainer

What this agent manifest does Upload a spreadsheet; get a plain-language readout — what's in it, the headline numbers, and the patterns worth a look. Build an agent that takes an uploaded spreadsheet — a sales export, survey results, usage logs, a budget sheet — and explains what's in it without you writing a single formula. It uses code interpreter to profile the columns (types, ranges, missing values), compute the summary statistics that fit each column, and surface the few notable patterns: a skewed distribution, an outlier cluster, a relationship worth a closer look. The output is a readout a non-analyst can act on, with the numbers behind every statement. This is a single-tool analyze → plain-language readout pattern using markdown-header structure. Headers give a multi-step analysis a clean spine — Overview, Headline Findings, Caveats — so the agent profiles before it summarizes and summarizes before it editorializes. The defining discipline is describing what the data shows, not inventing why: the agent reports a correlation or an outlier and explicitly does not assert a cause. Edge cases cover schema mismatches, empty or huge files, and columns that aren't what their headers claim. This pattern applies anywhere an uploaded table needs to become a readable story. Common scenarios for this pattern: Quick reads of an unfamiliar data export Survey and feedback result summaries Usage / telemetry log overviews Budget or spend sheet reviews Experiment-data first looks The tools it uses This manifest uses: code interpreter Use this agent manifest to understand How to build single-shot agents using markdown headers prompt structure for report / tables output.

Marketing Copy Drafter

What this agent manifest does Give a brief and a brand guide; get labeled, on-brand copy variants — headlines, subject lines, blurbs — without unsupported claims. Build an agent that drafts marketing copy in your brand's voice. It uses File search to read your brand guide, then generates a set of distinct, labeled variants from your brief — headlines, email subject lines, landing-page blurbs, social posts — each true to your tone and free of claims the brief doesn't support. You get options to react to instead of a blank page. This is a single-tool transform → copy variants pattern using natural-language structure, which fits a creative task where rigid scaffolding would flatten the voice. The instructions still hold a firm line: ground the tone in the brand guide and make no product claim the brief doesn't substantiate — no "the best," "guaranteed," or invented benefits — because unsupported claims are both off-brand and a compliance risk. The agent produces genuinely different angles rather than five rewordings of one idea, and labels each so you can pick and refine. Edge cases cover a thin brief (ask for the missing angle) and a missing brand guide (state the neutral voice it's defaulting to). This pattern applies anywhere on-brand copy options speed up the first draft. Common scenarios for this pattern: Ad and headline variations Email subject-line options Landing-page and hero blurbs Social post drafts Short product blurbs The tools it uses This manifest uses: File search Use this agent manifest to understand How to build single-shot agents using natural language prompt structure for labeled copy variants output.

Product Description Writer

What this agent manifest does Feed a product spec sheet; get a consistent title, feature bullets, and long description — grounded in the specs, no invented claims. Build an agent that turns a product spec sheet into a polished, consistent description. It uses File search to read the specs, then writes to a set structure — a title, scannable feature bullets, and a longer description — pulling every concrete detail from the sheet so the copy is accurate and uniform across a whole catalog. You get listing-ready copy that matches the product. This is a single-tool transform → formatted copy pattern using natural-language structure, which keeps the product voice natural while the instructions enforce a fixed output shape. The defining discipline is fidelity to the spec: the agent writes only from the details on the sheet, never invents a feature or measurement to make the copy fuller, and avoids absolute claims like "the best" or "indestructible" — both for accuracy and because unsupported superlatives are a compliance risk. Edge cases cover missing fields (note them, don't fill them) and inconsistent units (flag, don't silently convert). This pattern applies anywhere structured product data needs to become consistent copy. Common scenarios for this pattern: Catalog and marketplace listings Product-detail-page copy Spec-to-blurb conversion Seasonal catalog refreshes Standardizing inherited descriptions The tools it uses This manifest uses: File search Use this agent manifest to understand How to build single-shot agents using natural language prompt structure for title / bullets / long description output.

Test Case Generator

What this agent manifest does Point it at a function or spec; get happy-path, edge, and negative test cases enumerated and ready to review. Build an agent that reads a target function, module, or written spec from a GitHub repository and produces a structured catalog of test cases: the happy paths, the edge cases (boundaries, empty and large inputs), and the negative cases (bad input, error states). For each case it writes the setup, the input, and the expected result in a table you can hand straight to whoever writes the tests — or use as their skeleton. This is a single-tool read → enumerated test cases pattern using numbered-rule prompt structure. Numbered rules fit because test enumeration is a contract, not a conversation: read the target, classify its behavior, then walk a fixed taxonomy (happy → edge → negative) so the same input yields the same disciplined coverage map. The instructions are explicit that the agent proposes cases for human review and does not assert the set is exhaustive — coverage is the reviewer's call, and any example code is a starting point to run, not a verified test. This pattern applies anywhere a spec or interface can be turned into checkable cases. Common scenarios for this pattern: Test scaffolding for a new function or endpoint Backfilling regression tests on legacy code Edge-case brainstorming during code review Turning acceptance criteria into test cases Building a QA checklist for a release The tools it uses This manifest uses: GitHub Use this agent manifest to understand How to build single-shot agents using numbered rules prompt structure for enumerated test cases output.

Log File Analyzer

What this agent manifest does Drop in a log export; get clustered errors with counts and a timeline — patterns surfaced, root cause left to you. Build an agent that turns a raw log or error export into something you can read: clustered error signatures, how often each occurs, when they started and stopped, and the top offenders. It uses code interpreter to parse the file, normalize similar messages into clusters, and assemble a timeline — converting a wall of repetitive lines into a ranked, time-aware picture of what happened. This is a single-tool analyze → error clusters pattern using XML-tag prompt structure. XML tags give a multi-phase job clean separation — <parse, <cluster, <report — so each stage has one job and the agent doesn't blur parsing with conclusions. The defining discipline is restraint: it groups, counts, and times the errors and surfaces the patterns, but it does not declare a root cause as fact or recommend a production change — those are the on-call engineer's calls, made with the agent's summary in hand. Edge cases cover unstructured or mixed formats, enormous files (sample and say so), and logs with no clear errors. This pattern applies anywhere a high-volume log needs to become legible. Common scenarios for this pattern: Incident triage prep Error-rate and crash-log review Post-deployment health checks Reducing a noisy-alert backlog Making an unfamiliar log readable The tools it uses This manifest uses: code interpreter Use this agent manifest to understand How to build single-shot agents using xml tags prompt structure for report / tables output.

Campaign Brief Summarizer

What this agent manifest does Name a campaign topic; get a researched brief skeleton — audience, angle, channels, open questions — with sources. Build an agent that gives a campaign a running start. It uses Web Search to research the topic, market, and competitive messaging, then drafts a structured brief skeleton: who the audience is, the angles worth testing, the channels that fit, and the open questions still to resolve — each grounded claim cited. You start strategy from a researched draft instead of a blank template. Results reflect public information available at the time of the search. This is a gather → brief skeleton pattern using a numbered-rules structure. Numbered rules keep the research disciplined — what to look for, how to cite, what to do when the topic is too broad. The defining design decision is intellectual honesty about gaps: instead of inventing market sizes or made-up stats to fill the brief, the agent puts unknowns in an explicit Open questions section, because a fabricated number in a campaign brief is worse than an acknowledged unknown. Edge cases cover a topic too broad to research usefully (narrow it first) and thin public information. This pattern applies anywhere a campaign needs a researched starting point. Common scenarios for this pattern: Campaign kickoffs Audience and landscape research Competitor-messaging scans Seasonal-campaign planning New-market entry briefs The tools it uses This manifest uses: Bing Web Search Use this agent manifest to understand How to build single-shot agents using numbered rules prompt structure for campaign brief skeleton output.

API Spec Explainer

What this agent manifest does Point an agent at an API spec; get a plain-language guide — key endpoints, auth, and a worked example call. Build an agent that reads an API specification — an OpenAPI/Swagger file, a reference doc — and explains how to actually use it. It uses File search to read the spec, then lays out the auth model, the endpoints that matter for the user's goal, the key parameters, and a worked example request and response, turning a dense reference into something a developer can build against quickly. This is a single-tool read → developer guide pattern using markdown-header structure. Headers match how developers read reference material — Auth, Key Endpoints, Example — letting them jump to what they need. The defining design decision is grounding: every endpoint, field, and status code comes from the spec, and where the spec is silent (rate limits, error semantics, required scopes) the agent says "not specified" rather than filling it with a plausible-sounding default. Edge cases cover huge specs (scope to the user's task), malformed specs, and questions the spec doesn't cover. This pattern applies anywhere an API reference needs translating into usable guidance. Common scenarios for this pattern: Getting started against an unfamiliar API Auth-flow and required-scope clarification Finding the right endpoint for a task Generating an example request to adapt Onboarding to an internal service's API The tools it uses This manifest uses: File search Use this agent manifest to understand How to build single-shot / multi-turn agents using markdown headers prompt structure for narrative + examples output.

Content Performance Explainer

What this agent manifest does Upload a content/campaign export; get a plain readout — top performers, laggards, and the caveats — without over-claiming cause. Build an agent that turns a content or campaign metrics export into a readout a marketer can act on. It uses code interpreter to analyze the data — engagement, conversion, channel and piece comparisons — and explains what performed, what underperformed, and what to watch for, in plain language with the numbers attached. You get the "so what" without building a single pivot table. This is a single-tool analyze → plain readout pattern using markdown-header structure. Headers split the highlights, the laggards, and the caveats so the read is scannable. The defining discipline is causal restraint in a domain that invites over-attribution: the agent reports that a piece outperformed and by how much, but it frames the why as a hypothesis to test rather than a proven cause, because "this subject line drove the lift" is rarely something a single export can prove. Edge cases cover small samples (flag, don't over-read), inconsistent metrics across channels, and missing conversion data. This pattern applies anywhere campaign or content metrics need a fast, honest read. Common scenarios for this pattern: Post-campaign recaps Channel-performance comparisons A/B and variant readouts Content-audit performance reviews Monthly content-metrics summaries The tools it uses This manifest uses: code interpreter Use this agent manifest to understand How to build single-shot agents using markdown headers prompt structure for performance readout output.

Data Pull & Chart Explainer

What this agent manifest does Ask a data question; get the query result, a chart, and a plain-language read of what it shows — with caveats. Build an agent that answers a data question end to end: it uses a data agent to query the connected dataset, then code interpreter to chart the result and describe what the chart actually shows. You get the visual and the "so what?" together — the headline movement, the notable segments, and the caveats — without writing the query or building the chart yourself. This is a query → visualize → explain pattern using markdown-header structure. Headers separate the result, the chart, and the read so a stakeholder can take just the parts they need. The two tools have distinct jobs: the data agent fetches grounded numbers, code interpreter turns them into a chart and computed summary. The defining discipline is causal restraint — the agent reports what moved and by how much, but frames relationships as association, not cause, because a chart showing two lines moving together is the easiest place to over-claim. Edge cases cover empty result sets, very large pulls (summarize, don't dump), and ambiguous metrics. This pattern applies anywhere a data question should return a visual and a read together. Common scenarios for this pattern: KPI and metric snapshots Cohort and segment views Funnel and conversion reads Operational-metric checks Quick "what does this trend look like?" answers The tools it uses This manifest uses: data agent, code interpreter Use this agent manifest to understand How to build single-shot agents using markdown headers prompt structure for chart + plain-language read output.

Doc Compare & Redline Helper

What this agent manifest does Compare two document versions; get a clean summary of what was added, removed, and changed — and which changes matter. Build an agent that compares two versions of a document — a current draft against the published version, this quarter's policy against last quarter's — and tells you what actually changed. It uses File search for the version you provide and SharePoint to retrieve the stored counterpart, then summarizes the substantive differences: what was added, removed, and reworded, with a note on which changes are meaningful versus cosmetic. This is a retrieve → diff → summarize pattern using natural-language structure. Natural language keeps the comparison readable while the instructions still enforce a clear contract: organize changes by added/removed/changed and rank by significance. The defining design decision is scope discipline — the agent summarizes what changed and how much it matters operationally, but it does not interpret legal meaning or advise on contract terms, staying a neutral change-summarizer. Edge cases cover format mismatches between the two versions, very large documents, and reorderings that aren't real changes. This pattern applies anywhere two versions of a document need a fast, honest diff. Common scenarios for this pattern: Policy and handbook updates Spec and requirements revisions Contract-overview deltas (non-legal-advice) Proposal version comparison Tracking changes across document drafts The tools it uses This manifest uses: File search, SharePoint Use this agent manifest to understand How to build single-shot agents using natural language prompt structure for change summary output.

Onboarding Pack Assembler

What this agent manifest does Assemble a new-hire onboarding guide from repo READMEs and internal process docs — setup, key repos, workflows, who to ask, all linked. Build an agent that assembles a "first week" onboarding guide for a new team member by pulling from two places: your repositories (READMEs, contributing docs, setup scripts) via GitHub, and your internal process and policy docs via SharePoint. It stitches them into one navigable guide — environment setup, the repos that matter, the core workflows, and who to ask — with a link to the source behind every section. This is a multi-source gather → assembled guide pattern using a numbered-rules structure. Numbered rules make the orchestration auditable: each rule assigns a tool to the content it owns — GitHub for anything code or repo, SharePoint for anything process or policy — so the agent doesn't guess setup steps from memory. The defining discipline is sourcing: every step is grounded in a real doc and cited, and where a needed step isn't documented anywhere, the agent inserts a flagged gap rather than fabricating a plausible command. It never includes secrets or credentials it encounters. This pattern applies anywhere scattered documentation needs to become one coherent guide. Common scenarios for this pattern: New-hire and team onboarding Repo ramp-up for a transferring engineer Environment-setup walkthroughs "First week" / "first PR" guides Contributor handbooks The tools it uses This manifest uses: GitHub, SharePoint Use this agent manifest to understand How to build single-shot agents using numbered rules prompt structure for assembled guide with links output.

Audience Research Scanner

What this agent manifest does Name an audience; get a persona sketch built from public signals — needs, language, channels — each tied to a source. Build an agent that researches an audience and structures what it finds into a usable persona sketch. It uses Bing Web Search to gather public signals — forum discussions, reviews, articles, public commentary — and code interpreter to organize and cluster them into themes: needs, pain points, the language the audience actually uses, and where they gather. The result is a persona grounded in observable signal, with sources, rather than a set of assumptions. Results reflect public information available at the time of the search. This is a gather → structure → deliver pattern using XML-tag prompt structure. The tags separate <gather (collect public signals) from <structure (cluster into themes) from <deliver (the sketch), keeping research and synthesis distinct so the synthesis stays traceable to evidence. The defining discipline is evidence over invention: every element of the persona points back to a real signal, and where the public record is thin, the agent says "limited signal" rather than padding the persona with plausible-sounding demographics. Edge cases cover thin data and conflicting signals across sources. This pattern applies anywhere audience understanding should start from real signal. Common scenarios for this pattern: Persona and segment research Qualitative segment sizing Trend and pain-point spotting Messaging and language discovery Pre-campaign audience grounding The tools it uses This manifest uses: Bing Web Search, code interpreter Use this agent manifest to understand How to build single-shot agents using xml tags prompt structure for persona sketch + signals output.

Brand Voice Reviewer

What this agent manifest does Submit draft copy; get the off-brand lines flagged against your voice guide, each with a suggested edit and the reason. Build an agent that reviews copy against your brand-voice guide and tells you exactly where it drifts. It uses File search to read the draft and SharePoint to pull your brand-voice guide, then flags the specific lines that miss the mark — too formal, off-tone, using avoided words — with a suggested edit and a one-line rationale tied to the guide. You get a targeted review, not a vague "this feels off." This is a retrieve standard → review → suggest pattern using natural-language structure, which suits the coaching tone of a voice review. The instructions still enforce a clear contract: flag specific lines, cite the guideline each one violates, and suggest an edit. The defining design decision is restraint — the agent suggests targeted fixes and explains them so the writer learns the voice, rather than silently rewriting the whole piece into something the writer can't reproduce next time. It separates clear guideline violations from subjective calls and labels the latter. Edge cases cover a missing guide (review against stated general principles, transparently) and genuinely subjective tone questions. This pattern applies anywhere copy needs to stay on-voice across many hands. Common scenarios for this pattern: Copy QA before publishing Tone-consistency reviews across writers Localized or translated-copy voice checks Partner- and agency-content review Coaching new writers on the brand voice The tools it uses This manifest uses: File search, SharePoint Use this agent manifest to understand How to build single-shot agents using natural language prompt structure for flagged lines + suggested edits output.

Retail Sales Trend Explainer

What this agent manifest does Ask the weekly sales question; get pulled data, trend tables by category/store/period, and a plain read — with caveats. Build an agent that answers retail sales-trend questions end to end. It uses a data agent to query the sales dataset and code interpreter to analyze and explain the trends — by category, by store, across periods — turning the recurring "how did we do?" into a fast, consistent readout with the tables and the plain-language interpretation together. Results are grounded in the queried data, not estimated. This is a query → analyze → explain pattern using markdown-header structure. Headers separate the highlights, the supporting tables, and the caveats so a manager can scan to what they need. The data agent fetches grounded numbers; code interpreter computes the period-over-period and segment comparisons. The defining discipline is causal restraint in a seasonal domain — the agent reports that a category rose or a store outperformed and frames likely drivers (seasonality, a promo window) as context to consider, not proven cause, because retail movement has many overlapping causes a single pull can't isolate. Edge cases cover empty result sets, very large pulls, and incomplete periods (don't compare a partial week to a full one). This pattern applies anywhere recurring sales questions deserve a fast, grounded read. Common scenarios for this pattern: Weekly and monthly sales reads Category-performance comparisons Store and region comparisons Seasonality checks Period-over-period trend summaries The tools it uses This manifest uses: data agent, code interpreter Use this agent manifest to understand How to build single-shot agents using markdown headers prompt structure for trend highlights + tables output.

Customer Review Synthesizer

What this agent manifest does Upload customer reviews, get structured sentiment analysis and theme extraction — one file, one dashboard. Build an agent that takes a CSV or export of customer reviews from any platform — Shopify, Amazon, Trustpilot — and produces a structured analysis: a sentiment breakdown, top recurring themes ranked by frequency, complaints and praise highlights, representative quotes per theme, and a theme-by-sentiment cross-tabulation. The entire pipeline runs in code interpreter — parsing, classifying, counting, formatting — with no external dependencies. Reviewer names and identifying information are never included, and every quote is real text from the upload (never fabricated). This is a single-tool data pipeline pattern using XML prompt structure. The prompt defines a precise five-step sequence (parse → classify → extract → cross-analyze → format) entirely within code interpreter. Because it's single-shot with no chance to iterate, the output spec is unusually detailed — every table, column, and section is predefined so the agent delivers a full analysis on the first pass. The guardrails handle small samples, mixed languages, and corrupted data. Because the pipeline runs in code, the output is a draft to sanity-check. This pattern applies anywhere an agent processes an uploaded dataset through a structured analytical pipeline and delivers formatted results. Common scenarios for this pattern: Employee-survey analysis Support-ticket categorization and trending Product-feedback synthesis from beta programs Event-attendee feedback reports App-store review monitoring The tools it uses This manifest uses: code interpreter Use this agent manifest to understand How to build single-shot agents using xml tags prompt structure for structured sentiment dashboard output.

Public Dataset Finder & Profiler

What this agent manifest does Describe your data question; get ranked public-dataset candidates, each profiled for structure and coverage, with honest caveats. Build an agent that helps you source data for a question. It uses Web Search to find candidate public datasets — open-data portals, government and research sources, public repositories — and code interpreter to profile a sample of the promising ones: columns, row counts, time and geographic coverage, obvious gaps. You get a ranked shortlist with a real profile of each, so you can decide what to download before you invest the time. Results reflect public sources available at the time of the search. This is a discover → profile → compare pattern using markdown-header structure. Headers organize the discovery results and the per-dataset profiles for quick scanning. The two tools split the work: Web Search finds candidates, code interpreter inspects a sample so the assessment is grounded in the actual data, not the dataset's marketing blurb. The defining discipline is qualified fitness — the agent ranks candidates and names what each is good and bad for, but never declares a dataset a perfect fit, and it flags licensing or access constraints (paywalled, restricted, attribution required) up front. Edge cases cover no good match and datasets that can't be sampled. This pattern applies anywhere a question needs data you don't already have. Common scenarios for this pattern: Sourcing data for a research question Benchmark and reference-dataset hunting Open-data exploration and feasibility scoping Dataset due-diligence before committing Finding a public proxy for an internal metric The tools it uses This manifest uses: Bing Web Search, code interpreter Use this agent manifest to understand How to build single-shot agents using markdown headers prompt structure for ranked candidates + per-dataset profile output.

Promotions Planner Helper

What this agent manifest does Plan a promotion faster; get a skeleton drawn from your past promos plus seasonal research — offers, timing, channels — as options, not promises. Build an agent that gives promotion planning a head start. It uses SharePoint to pull your past-promotion docs (what you ran, when, how it was structured) and Web Search for current seasonal and market context, then drafts a plan skeleton: candidate offers, a timing outline, and channel ideas. You start from your own history plus fresh context instead of a blank calendar. Results reflect public information available at the time of the search. This is a gather → structure → deliver pattern using XML-tag prompt structure. The tags separate <gatherhistory (internal past promos) from <research (seasonal context) from <draft (the skeleton), keeping internal knowledge and external research distinct and traceable. The defining design decision is honesty about outcomes: the agent frames offers and timing as options to evaluate, and it never promises a revenue lift or sales outcome — projected results aren't something a planning draft can guarantee, and claiming them is a compliance risk. Edge cases cover thin promo history (work from seasonal context and say so) and a vague planning window. This pattern applies anywhere a recurring planning task can start from history plus context. Common scenarios for this pattern: Seasonal-promotion planning Clearance and end-of-line planning Bundle and offer ideation Promo-calendar drafting Repeating a past promo with fresh timing The tools it uses This manifest uses: Bing Web Search, SharePoint Use this agent manifest to understand How to build single-shot agents using xml tags prompt structure for promotions plan skeleton output.

API Integration Troubleshooter

What this agent manifest does Systematic API debugging — makes read-only test calls, analyzes responses, walks you through the diagnosis. Build an agent that diagnoses API integration issues by actually calling the API — safely. Describe your issue (auth failures, unexpected responses, rate limits, data-format mismatches) and the agent works a systematic diagnostic tree: connectivity → authentication → request format → response handling → edge cases. It uses the OpenAPI tool to make test calls and code interpreter to parse responses, compare against the spec, and generate corrected code. By default it makes only GET (read-only) calls and announces every call before making it — writes require your explicit approval. The output is a diagnostic-path table, a clear root cause, and a verified fix. Upload your API docs for faster diagnosis. This is a diagnostic decision tree with live-system interaction pattern using numbered-rule prompt structure. Most troubleshooting agents give theoretical advice; this one tests hypotheses by making real calls, where each step produces a response that confirms or rules out a failure mode. The prompt enforces safe defaults — read-only unless approved, no real credentials in output, stop-and-warn on anything that could cause data loss — so the live-interaction power comes with guardrails. A person approves any state-changing call, and generated fixes are drafts to verify. This pattern applies anywhere an agent systematically diagnoses issues by interacting with a live system and narrowing root causes through structured testing. Common scenarios for this pattern: Webhook delivery-failure investigation OAuth and authentication-flow debugging Data-sync discrepancy diagnosis between systems Third-party SDK integration troubleshooting Microservice communication-failure analysis The tools it uses This manifest uses: OpenAPI, code interpreter Use this agent manifest to understand How to build multi-turn agents using numbered rules prompt structure for diagnostic report + corrected code output.

PR Review & Merge Assistant

What this agent manifest does First-pass PR review — standards check, risk triage, and structured feedback for a human reviewer. Never merges. Build an agent that reads a pull request via GitHub, checks the changes against your team's uploaded coding standards via File search, and delivers a concise first-pass review: risk level (low/medium/high), a summary of what changed, standards-check results, specific issues with file and line references, and a recommendation — approve, approve with comments, or request changes. The recommendation is advice for a human reviewer: the agent never merges, approves, or modifies code. Low-risk PRs (dependency bumps, config changes) get a fast recommendation; high-risk PRs (security changes, migrations, missing tests) get detailed concerns. This is a triage with graduated response pattern using markdown-header prompt structure. The agent doesn't treat every PR the same — it categorizes by risk and adjusts review depth: simple changes get a fast recommendation, complex changes get thorough scrutiny. The prompt enforces a constructive tone (note positives alongside issues) and handles edge cases like missing descriptions, diffs too large to fully analyze, and standards docs that conflict with the team's actual patterns. Because a human makes the merge decision and the review may include suggested fix snippets, the output is explicitly a draft to verify. This pattern applies anywhere an agent assesses incoming items, classifies by risk or priority, and produces graduated, advisory responses. Common scenarios for this pattern: Security-alert triage and severity classification Support-ticket routing by complexity and urgency Content moderation with graduated review levels Change-request evaluation for CAB processes Inbound-lead qualification scoring The tools it uses This manifest uses: GitHub, File search Use this agent manifest to understand How to build single-shot agents using markdown headers prompt structure for structured review notes output.

Meeting Prep Briefing

What this agent manifest does Pre-meeting briefing from three sources — attendee research, internal docs, and cited external context. Build an agent that produces a structured meeting briefing by pulling attendee backgrounds from the web, surfacing relevant internal documents from SharePoint, and grounding key facts with cited sources via Bing. Give it a meeting title, attendee list, and agenda, and it delivers a polished brief: participant profiles, links to relevant internal materials, recent news that could impact the discussion, and suggested talking points. Each source plays a distinct role — SharePoint for internal context, Web Search for attendee backgrounds, Bing for cited topic grounding. With memory, it learns your recurring meetings and preferred briefing depth. Research uses only public professional information, and the briefing is a draft for you to review. This is a three-source synthesis with ordered tool execution pattern using XML prompt structure. The agent runs tools in a deliberate sequence — internal context first (SharePoint), then attendee research (Web Search), then topic grounding (Bing) — so each step builds on the last. The XML structure cleanly separates role, tool strategy, output format, and guardrails. The prompt handles ambiguous attendee names, missing internal docs, and sensitive topics, and the privacy guardrail keeps research to professional context only. This pattern applies anywhere an agent synthesizes information from multiple distinct sources into a unified briefing or dossier. Common scenarios for this pattern: Client-meeting preparation for account teams Board-meeting briefing packets Partnership-evaluation summaries Conference-speaker research for event organizers Prospect research for business development The tools it uses This manifest uses: Bing Web Search, SharePoint Use this agent manifest to understand How to build multi-turn agents using xml tags prompt structure for structured briefing document output.

Data Quality Auditor

What this agent manifest does Systematic, read-only data-quality checks against Fabric — nulls, duplicates, outliers, freshness, schema — with a 0-100 score. Build an agent that connects to your Fabric workspace, queries target datasets, and runs a battery of quality checks — completeness, uniqueness, freshness, consistency, outliers, referential integrity, and schema validation. It uses a data agent to read schemas, row counts, and statistics, then code interpreter to run each check, classify findings by severity (critical/high/medium/low), and compile a scored report. The output leads with an Overall Quality Score (X/100) and a findings table — e.g. | Check | Finding | Severity | Table.Column | — so the most important issues are visible at a glance. The agent never modifies, deletes, or writes to any data source. This is an autonomous checklist execution with severity classification pattern using numbered-rule prompt structure. Each rule maps to a phase — identity, input, retrieval, checks, severity, output, quality rules — so behavior is fully predictable: same checks, same order, same thresholds every run. The prompt enforces read-only operation and handles inaccessible tables, large datasets requiring sampling, and the discipline of reporting what was checked and what wasn't. Because checks run in code, the report is a draft for the data owner to verify. This pattern applies anywhere an agent runs a systematic, repeatable audit against a data source and produces a scored report. Common scenarios for this pattern: ETL pipeline output validation Data-migration verification Dashboard data-source health checks Warehouse table profiling for new consumers Periodic data-governance reporting The tools it uses This manifest uses: data agent, code interpreter Use this agent manifest to understand How to build autonomous agents using numbered rules prompt structure for scored audit report output.

Internal App Test Runner

What this agent manifest does Browser-based smoke testing — executes confirmed test cases against your internal app, logs failures to GitHub. Build an agent that navigates your internal web application via browser automation, executes test scenarios step by step, compares actual results to expected outcomes, and creates GitHub issues for any failures with full reproduction steps. It reviews the test plan with you before executing — confirming which cases to run, the target URL, and any known issues to skip — and never modifies the application or its data. The output is a clear pass/fail/blocked summary plus auto-filed GitHub issues for each failure. Upload test cases or describe key scenarios and the agent structures them into testable steps. This is a human-confirmed plan → automated execution → result tracking pattern using markdown-header prompt structure. The agent doesn't just run tests — it first parses and presents the test plan for confirmation, creating shared understanding before anything executes. The browser-automation instructions are deliberately explicit about navigation: wait for page load, verify an element exists before interacting, retry up to three times before marking blocked. It pairs browser actions with GitHub issue creation for a closed loop. Because it drives a live app and files real issues, the plan-confirmation gate and credential safety are built in, and a person owns the results. This pattern applies anywhere an agent executes a structured plan against a live system and tracks outcomes. Common scenarios for this pattern: Regression testing after deployments Acceptance-criteria verification for new features Periodic health checks on internal tools Onboarding-flow validation across environments Form and workflow testing for business applications The tools it uses This manifest uses: browser automation, GitHub Use this agent manifest to understand How to build multi-turn agents using markdown headers prompt structure for pass/fail report + logged issues output.

Vendor Evaluation Scorecard Builder

What this agent manifest does Compare options against your weighted criteria; get a sourced, weighted scorecard and a ranking — as decision input, not the decision. Build an agent that turns an option comparison into a structured scorecard. It uses Bing Web Search to gather public information on each option, SharePoint to pull your internal evaluation criteria and their weights, and code interpreter to compute a weighted score and rank the options. The result is a transparent scorecard — every criterion, every weight, every score, and the assumptions behind them — that gives a comparison real structure. This is an autonomous gather → score → rank pattern using XML-tag prompt structure. The tags separate the phases — <gather, <score, <rank — so a multi-tool autonomous flow stays legible and each tool's output is traceable. The defining design decisions are two: keep public vendor claims labeled separately from your internal criteria so unverified marketing never silently inflates a score, and present the ranking as decision input requiring human review, not a purchasing recommendation. Because the agent works autonomously across several steps, its output is a draft for a person to validate. Edge cases cover missing data (mark it, don't guess) and subjective criteria. This pattern applies anywhere structured, weighted comparison beats gut feel. Common scenarios for this pattern: Tool and platform comparisons Build-vs-buy input Shortlist ranking RFP option scoring (non-binding) Capability-matrix building The tools it uses This manifest uses: Bing Web Search, SharePoint, code interpreter Use this agent manifest to understand How to build single-shot agents using xml tags prompt structure for weighted scorecard + ranked options output.

Repo Audit & Report Builder

What this agent manifest does Point an agent at a repo; get a health audit — structure, docs coverage, loose ends — as findings ranked by severity, against your standard. Build an agent that audits a repository and writes up its health. It uses GitHub to read the repo's structure and contents, code interpreter to analyze it (documentation coverage, TODO/FIXME density, file-organization signals), and File search to load your team's standards or checklist so the audit measures against the right bar. The output is a report: findings grouped by area, each rated for severity, with constructive suggestions — a snapshot you can act on. This is a gather → analyze → report pattern using a numbered-rules structure. Numbered rules keep an autonomous multi-tool audit consistent and repeatable — the same checks, the same severity definitions, every run. The defining discipline is advisory scope: the agent reports findings and suggests improvements but does not make merge, ship, or release decisions, which stay with the team. Because it works autonomously across several steps, the report is a draft for human review. Edge cases cover very large repos (scope and say so), partial access, and repos with no defined standard to measure against. This pattern applies anywhere a repository needs a structured health check. Common scenarios for this pattern: Code-health and tech-debt snapshots Onboarding audits of an inherited repo Pre-release readiness reviews Documentation-coverage checks Periodic repo hygiene reports The tools it uses This manifest uses: GitHub, code interpreter, File search Use this agent manifest to understand How to build single-shot agents using numbered rules prompt structure for audit report output.

Weekly Team Status Reporter

What this agent manifest does Automated status reports from GitHub and SharePoint — shipped, in progress, and blocked in one summary. Build an agent that pulls recent activity from GitHub repos and SharePoint sites and compiles a concise weekly status report organized into three buckets — Shipped, In progress, and Blocked / needs attention — with a single count line at the bottom (e.g. 3 shipped | 5 in progress | 2 need attention). It reads merged PRs, open PRs, blocker-labeled issues, release tags, recently modified documents, and project trackers, links every item to its source, and reports facts without judging whether the week was "good" or "bad" — so the summary is ready to paste into a team channel as-is. This is a multi-source aggregation with fixed structure pattern using numbered-rule prompt structure. The rules define a linear workflow — collect from GitHub, collect from SharePoint, organize into predefined buckets, format — with no branching and no decisions. The prompt demonstrates that constraints make simple agents reliable: every output looks the same and every run follows the same path. The strict "facts, not judgments" boundary is what makes the report trustworthy enough to share without editing. This pattern applies anywhere an agent aggregates activity from multiple systems into a recurring summary. Common scenarios for this pattern: Sprint-retrospective data gathering Cross-team project rollups Weekly engineering digests for leadership Release-readiness summaries Operational handoff reports between shifts The tools it uses This manifest uses: GitHub, SharePoint Use this agent manifest to understand How to build autonomous agents using numbered rules prompt structure for bucketed status report output.

Internal Procurement Portal

What this agent manifest does Inventory monitoring and reorder recommendations by default — optional, human-enabled submission with safety checks. Build an agent that checks inventory levels in your Fabric workspace via a data agent, identifies items below their reorder threshold, and produces a prioritized reorder report: what to reorder, how much, from which supplier, and what to escalate. By default it recommends only — nothing is submitted. When you explicitly enable autonomous mode, it navigates your procurement portal via browser automation to submit the approved reorders, applying safety checks at every step: standard reorders within approved limits proceed, while value overruns, duplicate orders, inactive suppliers, and zero-stock items are flagged for manual review. An optional API cross-check can verify inventory against a live source. This is a monitor → recommend → (optionally) act with safety gates pattern using numbered-rule prompt structure. The redesign leads with the safe, high-value job — monitoring and recommendations — and treats real-world action as an advanced, opt-in capability. Because the agent can submit real purchase orders, the instructions build in multiple safety layers (max order values, duplicate detection, supplier validation, a portal-outage fallback) and require a human to review the report; the numbered rules make every decision auditable against a specific rule. This pattern applies anywhere an agent monitors a system, recommends actions, and can optionally execute approved ones within human-controllable boundaries. Common scenarios for this pattern: Supply replenishment for retail or warehouse operations Service-ticket escalation and routing on threshold rules Infrastructure scaling requests from monitoring data Recurring purchase-order generation from consumption data Maintenance work-order creation from equipment readings The tools it uses This manifest uses: data agent, browser automation, OpenAPI Use this agent manifest to understand How to build multi-turn agents using numbered rules prompt structure for reorder report output.