A “customer service agent” is merely a use-case label. A useful example has a name, a job, connected apps, an operating limit, and a rule for what happens when the work becomes risky. The OECD describes AI agents as systems that perceive and act on an environment with some autonomy, using tools to pursue goals and adapt to changing inputs (OECD.AI). For a closer distinction between bounded assistance and acting systems, see AI agents vs AI assistants.
Oasis's current template directory contains 152 agents. This guide examines ten of them across support, sales, engineering, research, finance, and operations. They are published configurations. No customer deployment claim is implied. The details below come from the live template pages and the first-party template inventory.
AI agent examples at a glance
| Agent | Job | Defining boundary |
|---|---|---|
| Zendesk Ticket Triage | Classify and route support tickets | Escalates data loss, security, and legal issues immediately |
| HR Helpdesk | Answer policy questions from internal sources | Refuses sensitive employee cases and ambiguous policy |
| Cold Email Personalizer | Research and draft prospect-specific outreach | Skips a prospect when it cannot find a verifiable signal |
| Competitor Monitor | Track changes to competitor pages | Reports the page-level difference rather than a generic update alert |
| GitHub PR Reviewer | Find consequential defects in a pull request | Ignores style and formatting noise |
| Incident Copilot | Assemble incident context and draft updates | Makes no production changes |
| PostHog Product Analyst | Analyze product behavior | Checks event definitions before interpreting a funnel |
| Research Assistant | Search, open, and synthesize sources | Preserves disagreement between sources |
| Invoice vs PO Matcher | Reconcile invoices, purchase orders, and receipts | Separates duplicates and missing purchase orders from other mismatches |
| Operations Lead | Reconcile project records across work systems | Reports by owner and blocker instead of by app |
Support and internal policy agents
1. Zendesk Ticket Triage
The Zendesk Ticket Triage configuration uses Claude Haiku 4.5 with low reasoning effort and up to 30 turns. Zendesk is required; Linear and Slack are optional. Memory is on, while browsing is off.
It reads the ticket body rather than trusting the subject, applies the team's existing taxonomy, sets priority from the reported impact and customer tier, and routes the ticket. Its strongest detail is the exception rule: any mention of data loss, security, or legal trouble is escalated immediately instead of entering ordinary triage.
That rule separates reversible queue management from cases where delay or a loose classification could matter. Memory can preserve the team's routing conventions across runs. With browsing off, the decision stays grounded in the ticket and connected support data instead of public material that may not reflect company policy.
Use a different pattern when the work includes resolving tickets or sending replies. This agent routes work. It does not claim to retrieve a verified answer, update a customer account, or close the case.
2. HR Helpdesk
HR Helpdesk runs Claude Sonnet 4.6 at medium effort with a 25-turn cap. BambooHR, Notion, Confluence, and Slack are required; no optional integration is listed. It learns across runs and cannot browse the public web.
The agent answers from the company's handbook and cites the relevant internal section. Complaints, harassment, health, accommodations, performance, termination, and questions about named colleagues go straight to a person without a drafted answer. It also stops when the written policy is silent or ambiguous.
That makes it useful for documented policy questions and a poor fit for employee relations, legal interpretation, or any case where policy must be created rather than retrieved.
Sales and market intelligence agents
3. Cold Email Personalizer
The Cold Email Personalizer uses Claude Sonnet 4.6 at medium effort for up to 35 turns. Gmail is required; Exa, Apollo, and HubSpot are optional. Both memory and browsing are enabled.
For each prospect, it looks for a specific public signal such as something the person published, a company change, or an observable product problem. It then builds the message around that evidence. If it finds nothing checkable, it skips the prospect instead of filling the email with generic praise.
Skip this pattern when your outreach program lacks consent rules, approved messaging, or human review before sending. The template drafts personalized outreach; its public specification does not say that it verifies legal compliance or sends messages autonomously.
4. Competitor Monitor
Competitor Monitor runs GPT-5.6 Sol with medium reasoning effort and up to 40 turns. It requires Exa, Firecrawl, Slack, and Google Sheets; no optional integration is listed. Browsing and cross-run memory are on.
The agent watches competitor pricing pages, product pages, release information, and hiring activity. It retains the previous page state, reports the actual change, and adds a short note about the possible positioning consequence.
It is the wrong tool for a one-time competitive brief or a strategy decision that depends on private win-loss data. Public page changes can reveal movement, but they cannot explain why a buyer chose one vendor over another.
Engineering and analytics agents
5. GitHub PR Reviewer
The GitHub PR Reviewer uses Claude Sonnet 4.6 at high effort with up to 40 turns. GitHub is required; Linear and Slack are optional. Memory is on and web browsing is off.
It reads the pull-request diff and searches for failure paths, race conditions, inefficient repeated queries, missing authorization checks, and behavior the tests do not cover. Findings must include a concrete input that would fail. Style and formatting comments are intentionally excluded so consequential defects remain visible.
Choose another tool if you need code generation, a complete security audit, or a release decision. Reviewing a diff is narrower than proving the surrounding system is safe, and the template does not change code.
6. Incident Copilot
Incident Copilot runs Claude Sonnet 4.6 at high effort for up to 45 turns. PagerDuty, Sentry, Datadog, Linear, and Slack are all required; no optional integration is listed. It learns across runs and has browsing disabled.
During an incident, it assembles the alert, affected scope, recent changes, and the investigation timeline. It drafts separate internal and customer-facing status updates. Its operational boundary is explicit: it changes nothing in production.
This configuration shows a useful way to constrain an engineering agent. It can reconcile evidence across the monitoring stack and keep communication current, while the responder retains control of remediation. The requirement for every connected system also exposes a dependency: a missing telemetry source leaves an incomplete incident picture that should be reported as such.
This is a support pattern for a human responder. It is unsuitable when the desired agent must execute remediation, when the required telemetry is unavailable, or when the team has no incident process to structure the output.
7. PostHog Product Analyst
The PostHog Product Analyst uses GPT-5.6 Terra at medium effort with up to 35 turns. PostHog is required and Google Sheets is optional. Memory is enabled; browsing is off.
It answers questions about funnels, retention, feature adoption, and cohorts. Before analyzing a funnel, it checks whether the underlying events still mean what the question assumes. Results include sample sizes and segment breakdowns so an overall metric does not conceal a problem concentrated in one group.
Do not use it as a substitute for instrumentation design or causal analysis. If events are missing, ownership is unclear, or a decision requires an experiment rather than a descriptive query, the agent lacks the evidence needed to answer.
Research agents
8. Research Assistant
The Research Assistant runs GPT-5.6 Sol at high effort with a 45-turn maximum. Exa, Firecrawl, Perplexity, and Google Docs are required; no optional integration is listed. Browsing is on and memory is off.
It searches broadly, opens the sources that matter, and prefers primary material over commentary. When sources conflict, it reports the disagreement instead of blending incompatible claims into a single conclusion. Disabling memory suits a workflow where a new evidence set should govern each run.
Here, the job depends on browsing. The agent needs current external evidence and enough turns to search, open, compare, and write. Its refusal to manufacture consensus is the practical guardrail: disagreement remains visible for the reader to evaluate.
Open-ended web research is a poor choice for decisions that require privileged company data, licensed databases the agent cannot access, or a deterministic answer from a controlled document set. A broad search can improve coverage, but source quality still determines the result.
Finance and operations agents
9. Invoice vs PO Matcher
The Invoice vs PO Matcher uses GPT-5.6 Terra at medium effort with up to 30 turns. Google Sheets is required; Google Drive and QuickBooks are optional. Both memory and browsing are off.
It compares the invoice, purchase order, and goods receipt line by line. Instead of returning a vague mismatch label, it presents the conflicting values together. Duplicate invoices and invoices without purchase orders are separated from other exceptions so reviewers can follow the right process for each case.
Keep it away from payment approval and ledger posting. The template documents reconciliation and exception reporting, not authority to move money. It also cannot match records that are absent or use inconsistent identifiers without a resolution rule.
10. Operations Lead
Operations Lead runs Claude Sonnet 4.6 at medium effort with a 35-turn cap. Linear, Jira, Notion, Slack, and Google Sheets are required; no optional integration is listed. It has cross-run memory and no web access.
The agent reconciles what project trackers say with what documents and Slack conversations show. Reports are organized around owners and blockers, with the follow-up needed from each person, instead of being divided into app-by-app summaries.
This broad pattern becomes a poor fit when no system is authoritative or teams use conflicting definitions of status. Connecting more tools does not resolve governance. Establish ownership and field meanings before asking an agent to reconcile them. Teams still defining those inputs can start with a small-business workflow automation guide before choosing an agent pattern.
Where AI agents fail
These examples look different, but their failure modes repeat.
The run reaches its turn limit
Every template above has a finite per-run budget. The caps range from 25 turns for HR Helpdesk to 45 turns for the Research Assistant and Incident Copilot. A task that requires more tool calls, retries, or investigation than the budget allows may stop before completion.
Treat the cap as part of workflow design. Split an unbounded research request into stages, reduce the number of records in a batch, or define what the agent should return when time runs out. Repeatedly raising the cap can hide a poorly scoped task.
An integration loses authorization
An agent that depends on Gmail, Slack, GitHub, or another connected app cannot complete its job when that connection fails. OAuth refresh tokens can expire or be revoked, and Google's current guidance says applications must handle both conditions and may need to prompt the user to authorize again (Google OAuth documentation).
The safe response is visible failure. Report which source could not be read, avoid partial writes that look complete, and route reauthorization to an account owner. Silent omission is especially dangerous in reconciliation and reporting agents.
Browsing adds inputs the task does not need
In the current library, 110 of 152 templates have browsing switched off. Agents in that group include Zendesk Ticket Triage, Incident Copilot, PostHog Product Analyst, and Invoice vs PO Matcher. Their relevant evidence already lives in connected systems of record.
This is an inference from the template configurations: disabling browsing narrows the evidence boundary and makes the result easier to audit. Public-web access belongs in work that needs current outside information, such as prospect research or competitor monitoring. It adds little to invoice matching and can introduce irrelevant material.
How to choose an agent pattern
Start with the boundary, then the capability. Write down the system that owns the facts, the actions the agent may take, the conditions that require a person, and what a failed run should report. Model choice comes after that scope; a workflow-level comparison of ChatGPT and Claude can help when the model family is still open.
The examples above earn their place because those decisions are visible. Zendesk Ticket Triage escalates named risk categories. Incident Copilot cannot touch production. Cold Email Personalizer skips a prospect when its evidence is weak. Those rules make an agent inspectable before anyone depends on its output.