CumulusDocs
Open Studio
On this page

Build with Cumulus

Connect a voice agent to your application: define its conversation, give it tools that use your business systems, publish a version and start a call. Cumulus runs the conversation. Your application supplies the business logic and decides which changes it permits.

For example, a service agent can ask what needs repair, look up appointments through your scheduling API and request a booking after the caller confirms. Your backend makes the reservation; Cumulus records the conversation, tool results and call outcome.

Start with the customer SDK

Build a voice agent in your application takes you from an installed SDK to a complete service-desk example. Define the agent and a tool, implement the tool in your backend, validate locally, publish and connect a dedicated test number. The example includes source code and tests.

Choose the Python SDK for typed HTTP API access, or @cumulus/sdk 0.3.4 for TypeScript and JavaScript, which also includes agent-authoring and server helpers. Compare and install the SDKs, then follow the guide for your language. Your tool server can use your existing language and framework; it communicates with Cumulus over HTTP.

What you needWhere to go
A complete first integrationCustomer SDK tutorial
Exact SDK functions, options and typesCustomer SDK reference
HTTP endpoints, request bodies and responsesCustomer HTTP API reference
Authentication, requests and retriesUsing the API
A connected coding assistantCumulus MCP

What belongs in your application

Your application owns the agent source, tool implementations, business records and authorization for actions such as booking or updating an account. A tool definition describes what the agent can request. Its implementation authenticates that request, checks your business rules and performs the operation.

Cumulus stores and runs the published conversation. Publishing sends configuration, not the implementation of your tool. You can add the tool routes to your existing backend; you do not need a separate service for every tool.

The SDK's customer-server handlers help receive tool requests, resolve initial call context and process signed events. If you use another language, implement the same HTTP contracts in your framework.

Build, publish and run

An agent contains the conversation you are building. Its draft is editable. A publication is an immutable version of that conversation. A run is one execution of a publication, such as a call or a cloud task.

  1. Define and connect. Describe the conversation and tool contracts. Bind tool URLs, secret references and phone resources for your environment.
  2. Review the change. Validate the definition and preview remote changes before updating the draft. Revision checks protect changes made by a teammate.
  3. Publish. Validate the draft and publish the intended revision. Keep the returned agent, version and receipt.
  4. Connect a number and call. Assign an imported number explicitly, then start a call against the intended publication. Publishing alone does not change a number's assignment.
  5. Read the outcome. Follow the run and inspect its transcript, tool results and end reason. Retrieve recording and analysis separately when they are ready.

The tutorial walks through this sequence. Work with Studio and recover changes explains later edits, conflicts and interrupted operations. Studio is another way to inspect and edit the same agents.

Connect useful behavior

Get access

You need a Cumulus workspace, its API URL and an API key with permission for your operations. Package access installs the SDK; the workspace key authorizes requests. Keep both credentials on your server.

Use a development environment and synthetic records while building. A phone integration also needs an imported number and permission to dial. Your Cumulus contact provides workspace and package access; book a demo if you are getting started.

Content version 4fbba15fCustomer SDKMarkdown source
Overview · Cumulus developer docs