Aggregated
Call several endpoints and return one combined result.
Slack messages and Gmail emails, for example, can be retrieved independently and handed back as a single structured result.
Workflows
Configure it once.
Call it by name.
A workflow combines endpoints from one or more services into a single capability. Give it a name, and every run() request can use it like any other tool, without your agent carrying the integration code.
A capability name and what it expands to
What you write
your-agent.js
Conceptual example
const result = await agent200
.user("user_123")
.run({
model: "openai/gpt-5.6-sol",
input: "Prepare my brief.",
tools: ["brief"],
});What Agent200 runs
brief
Custom capability - Slack Retrieve relevant messages
- Gmail Retrieve relevant emails
- Combine Apply the configured output structure
Returned to the model as one tool result
Capabilities
The model sees a tool.
Agent200 keeps the integration.
A connector is access to an external service. A capability is something a model can invoke. Agent200 turns the first into the second, so the model never has to understand a provider's HTTP API, only what a tool does, when to use it and which inputs it accepts.
What the model receives
Illustrative tool definition- Name
- slack_search
- What it does
- Searches messages in the Slack workspace the end user has authorized.
- When to use it
- When the task needs information from the user's Slack conversations.
- Inputs
- The values the capability accepts, described by its input schema.
What it never has to know
- Slack's endpoints, request formats and response structures
- The end user's OAuth tokens, and refreshing them
- Constructing the request and communicating with the provider
When the model calls the tool, Agent200 executes the underlying request through the Slack connector and returns the result to the model.
Two shapes of capability
slack_search
One endpoint
The simplest capability exposes a single connector endpoint under a name and an input schema the model can use.
- Slack · Search messages
brief
Several endpoints, one name
A capability can also combine endpoints from the same service or from different services. The model still sees one tool.
- Slack · Retrieve relevant messages
- Gmail · Retrieve relevant emails
Visual workflow builder
Several endpoints in.
One capability out.
Part of the developer dashboard, the builder lets you assemble a capability on a canvas instead of writing each underlying API request yourself: choose the endpoints, decide how their results come together, and save it under a name.
capability
brief
Concept · planned builder
Input
Workflow input
What the model passes when it calls brief
Slack
Retrieve relevant messages
Gmail
Retrieve relevant emails
Combine
Combine results
Apply the configured output structure
Result
Return data to the model
One tool result, from two services
Illustrative The canvas above sketches a workflow named brief: endpoints from two services on the left, one combined result on the right. Read it as a diagram of the pattern, not a screenshot of the builder.
-
In the dashboard
The visual builder is where you connect endpoints, configure how they run and define the tool your agent will call.
-
Or through the SDK
Capabilities can also be configured from code. Either way, the result is the same: a named capability your requests can reference.
Workflow patterns
Side by side, or one after another.
The builder is intended to support two ways of putting endpoints together. You define the behaviour; Agent200 runs it whenever the capability is invoked.
Sequential
Use the output of one endpoint as the input to the next.
A workflow could retrieve information from one service, pull an identifier out of it, and pass that identifier on to another service.
- Step 1 Retrieve information from one service
- Step 2 Extract an identifier from the response
- Step 3 Pass it to an endpoint of another service
What you would configure
The developer defines the workflow's behaviour. These are the kinds of settings a workflow may expose.
- Input schemas
- Endpoint selection
- Request parameters
- Data mappings
- Transformations
- Output schemas
Illustrative These are the configuration elements the builder is being designed around. The set will grow as new workflow patterns get real usage.
Capability output
Structured data the model can reason over.
A capability may return structured information. For brief, that could be one object with the Slack messages and the Gmail emails side by side.
- Shaped by your configuration
- The actual output depends on the endpoints behind the capability and on how the workflow is configured to structure them.
- Handed to the model, not stored as a feature
- The result goes back into the run so the model can keep reasoning with it. Agent200 is not currently intended to keep a persistent, searchable index of retrieved connector data.
brief → result
Conceptual example
{
"slack": [
{
"message": "Project update..."
}
],
"gmail": [
{
"subject": "Weekly update",
"content": "..."
}
]
}Planned Richer shapes are on the roadmap: passing the output of one operation into the next, along with schema definition and transformation controls, so a capability can return exactly what your model needs.
Inside run()
One tool call.
Several API operations.
During a run() request the model decides whether to call your capability. When it does, Agent200 executes the whole workflow behind that single call and returns one result. The model then continues, calls more tools, or writes the final response.
-
Your app
agent200.run()
model, instructions, input and tools: ["brief"]
-
Agent200 · model
AI model
Reads the task and the tool definitions, then chooses which tools to call, if any.
Tool definitions provided
brief · name, description, inputs
Repeats until complete
Each tool result returns to the model, which may reason further or call another tool.
-
Agent200 · tool execution
Custom workflowCalls: brief
- Slack API Retrieve relevant messages
- Gmail API Retrieve relevant emails
Combined result Returned to the model as one tool result -
Your app
200 OKFinal response
Returned to your code, to use in the rest of your agent's flow.
- 1 /Your app calls run() with a model, an input and the tools the model may use.
- 2 /Agent200 invokes the model and provides the tool definitions. The model decides what, if anything, to call.
- 3 /The model requests brief. It only needs the capability's description and inputs, not the endpoints behind it.
- 4 /Agent200 executes the workflow you configured: Slack and Gmail are called with the end user's authorized connections.
- 5 /The combined result goes back to the model, which can keep reasoning or call another tool. The loop repeats until the request is complete.
- 6 /The model produces the final response and Agent200 returns it to your app.
What the model deals with
- One tool named brief, with a description of what it does
- The inputs brief accepts
- One combined result to keep reasoning with
What Agent200 executes
- The Slack API request
- The Gmail API request
- user_123's authorized connections for both
- Combining the responses into the configured structure
Making a capability available does not mean it runs: the model invokes it only when the task calls for it. When a run happens is up to you: your app schedules its own requests.
Beyond two services
Not limited to one request, or to one service.
The same principle scales to longer workflows. Encapsulate the steps once, and every part of your app can ask for customer_context instead of repeating the integration logic.
customer_context
Illustrative future configuration - 01 Retrieve CRM customer details.
- 02 Retrieve related emails.
- 03 Search relevant Slack conversations.
- 04 Return the combined information.
This example shows the principle: a reusable capability built from multiple API operations. The CRM could be HubSpot or Salesforce; the pattern is the same.
200 OK
Turn the endpoints you need
into one capability.
Combine operations from one or more services into a named tool, then reference it from any run() request.