Five agents developers build with Agent200
Productivity, sales research, developer operations, research and multi-service automation: five agents built from the same parts, and the parts each one leans on.
2 min read
The same building blocks, connectors, managed OAuth, workflows, models and paid services, add up to very different products. Here are five agents developers build on Agent200, and the parts each one leans on.
1. A personal productivity agent
It reads the relevant messages and email, prepares a brief and hands it to the user at the start of the day.
- Services: chat and email, such as Slack, Microsoft Teams, Gmail or Outlook.
- Agent200 parts: managed OAuth for each user’s accounts, a
briefworkflow, a model to write it.
2. A sales research agent
Before a meeting, it combines the customer record, the related email and a search of the public web into one page of research.
- Services: a CRM such as HubSpot or Salesforce, email, and a search service such as Tavily or Exa.
- Agent200 parts: a
customer_contextworkflow, per-user connections, paid search on the same key.
3. A developer operations agent
It helps an engineer investigate an incident or answer a question about the codebase by pulling from the tools the team already uses.
- Services: GitHub or GitLab, Jira or Linear, Sentry or Datadog, and the team’s chat.
- Agent200 parts: connectors with read-only endpoints enabled, a model that reasons across the results.
4. A research agent
It searches, reads the pages that matter and returns an answer with its sources.
- Services: Tavily, Exa, Brave Search, Firecrawl or Perplexity, alongside an AI model.
- Agent200 parts: models and paid services through one API key and one statement.
5. A multi-service automation
One request needs information from several systems, in a particular order: look something up in one, use the result in another.
- Services: whichever systems the job spans.
- Agent200 parts: a sequential workflow that chains the endpoints into one reusable capability.
What they have in common
None of these agents had to implement a provider API, an OAuth callback or a separate billing relationship. Each developer described what the agent should do, chose the services and the model, and let Agent200 run the capabilities for the right user.
These are examples, not a menu. See more on the Use Cases page, and every supported service in the integrations catalog.
