Agent200

Use Cases

Five agents.
One infrastructure.

Different products need the same things underneath: access to external services, user authorization, reusable capabilities, models and execution. Here is how that looks in five kinds of agent.

Illustrative scenarios These scenarios are illustrative and their SDK code is conceptual. Each one draws on services from the integrations catalog.

01 Personal productivity agent

A morning brief from the inbox and the workspace.

Your agent answers one question with context from two places. A custom capability named brief retrieves the relevant Gmail emails and Slack conversations; the model you selected turns them into a summary for the user who authorized both accounts.

End user → your agent

What needs my attention this morning?

brief

Custom capability
  • Gmail Retrieve relevant emails 200 OK
  • Slack Retrieve relevant messages 200 OK

openai/gpt-5.6-sol composes the answer

Your agent → end user · illustrative output

Two emails are waiting on a reply from you, and the launch thread in Slack needs your decision on the rollout date. Everything else can wait until the afternoon.

You build

  • The assistant and its interface
  • When the brief runs: scheduling stays in your app
  • What happens with the result

Agent200 provides

  • Gmail and Slack connectors
  • OAuth and each user's authorized connections
  • The reusable brief capability
  • Model access and tool execution inside run()

02 Sales research agent

Meeting research, assembled before the meeting.

Customer details, the email history and a web search normally live behind three integrations. Configure a workflow that retrieves and combines them, make it available next to a search tool, and let the model decide what the question needs.

CRMEmailWeb search two tools
sales-agent.js
Conceptual example
A conceptual Agent200 run request that makes a custom workflow and a search tool available to the model.
const research = await agent200
  .user("rep_481")
  .run({
    model: "openai/gpt-5.6-sol",
    instructions: "Prepare concise meeting research.",
    input: `I'm meeting Dana from Northwind at 3pm.
            What should I know?`,
    tools: ["customer_context", "tavily_search"],
  });

Illustrative CRM here means a connector such as HubSpot or Salesforce.

You build

  • The sales agent and where it lives in your product
  • The instructions that shape the research
  • How reps trigger it and see the answer

Agent200 provides

  • Connectors to the supported services
  • customer_context as one reusable workflow
  • Search and model access on the same API key
  • Execution of every tool call the model makes

03 Developer operations agent

Incident questions, answered from the systems involved.

During an incident the facts are split between software-development tools and team chat. An agent with access to both, limited to the endpoints and scopes you permit, can gather what changed and what was said, and answer in one place.

ops-agent · execution

input

Checkout latency went up after the last deploy. What changed?

  1. recent_changes

    200 OK

    Software-development connector · retrieve recent changes

  2. incident_thread

    200 OK

    Communication connector · search the incident channel

  3. Model composes the answer

    Done

    From both tool results, within the same run() request

Permissions Access is always subject to the end user's authorization and the permissions you configure.

You build

  • The ops agent and its place in your tooling
  • Which questions it should handle, and how
  • Any alerting or scheduling around it

Agent200 provides

  • Access to the supported external systems
  • Per-endpoint and per-scope permission control
  • User-specific connections for each engineer
  • The tool-calling loop inside each request

04 Research agent

Search and models, without two more vendor accounts.

A research agent needs a search service such as Tavily and one or more AI models. Through Agent200 both are reached with the API key you already have, and the usage of both is accounted for in one place.

Your Agent200 API key

  • Web search

    Tavily, requested through Agent200

    No Tavily key

  • AI model

    Selected by name, per request

    No provider key

Usage of both is accounted for through your Agent200 account, instead of two separate provider relationships.

You build

  • The research agent and its method
  • Which model fits which task
  • How findings are stored, cited and presented

Agent200 provides

  • Access to supported search services
  • Access to supported AI models
  • One API key instead of one per provider
  • One billing relationship for the usage

05 Multi-service automation

Several systems, one capability.

Some operations only make sense across services. Combine the endpoints into a workflow once, give it a name, and every part of your app can invoke it through the SDK. The model sees a single tool, not the requests behind it.

You build

  • The automation and the business rules around it
  • When and why the operation runs
  • What the result triggers next

Agent200 provides

  • The connectors behind each endpoint
  • The workflow that combines them
  • A single named capability for the SDK
  • Execution when the capability is invoked

Endpoints you select

  • CRM Retrieve account details
  • Email Search related emails
  • Chat Search related conversations
  • Files List shared documents

One capability

Reusable

account_snapshot

The model receives one tool definition. Agent200 knows which endpoints belong to it and runs the configured workflow when it is invoked.

tools: ["account_snapshot"]

Illustrative An illustrative configuration. The services shown stand for whichever supported connectors your workflow combines.

Who builds with Agent200

For whoever is building the agent.

Agent200 is infrastructure for developers, not a chatbot builder for end users. If you are writing the agent, it is for you.

  1. 01

    Independent developers building an AI product of their own.

  2. 02

    Startups building an AI-powered app.

  3. 03

    Software engineers adding agent capabilities to an existing product.

  4. 04

    Engineering teams building internal AI agents.

  5. 05

    Companies developing AI automation for their customers.

The developer

Configures what the agent can do.

Developers are Agent200's customers. They create the account and projects, generate API keys, select integrations, define capabilities and use the SDK, and they are responsible for the paid services their app consumes.

The end user

Authorizes access to their own accounts.

End users are the people using what the developer built. They do not necessarily need an Agent200 account. When the agent needs their Slack or Gmail, they approve it through an OAuth flow managed by Agent200, and the connection is tied to their identity inside the developer's project.

200 OK

Your use case.
One SDK.

Whatever your agent does, the infrastructure underneath looks the same. Build the agent; Agent200 provides and executes its external capabilities.

Get Started See how it works