Skip to main content

​
ChatATP Studio

ChatATP Studio is an Agent OS. You design an agent once — its knowledge, memory, tools, schedules, and channels — then run that same agent in WhatsApp, your product, your docs, or any app that can call an API. This documentation is for builders who want agents that remember users, take actions, and stay under their control. The SDKs and HTTP API come after the model. If you only need a code snippet, skip to the Quickstart.

​
Why Studio exists

Most teams still assemble agents from pieces that were never meant to work together:
  • A chatbot plugin that can talk, but cannot remember
  • A helpdesk bot that can deflect tickets, but cannot call your APIs
  • An LLM wrapper in application code that works in one product surface and dies when you need WhatsApp
  • Automation tools that fire messages on a schedule, with no conversation and no user memory
Studio puts those layers in one control plane. You configure the agent in the dashboard. You attach knowledge, memory, tools, and schedules. Then you deploy the same agent to a channel or embed it with the SDK.

​
How Studio is different

The difference is ownership of the agent, not ownership of a chat box. Change the model, the tools, or the prompt in Studio and every surface updates.

​
The mental model

Everything in Studio maps to a small set of objects. If you remember only one thing: the agent is the product. Conversations, SDKs, and widgets are how people reach it.

​
What you can build

  • A support agent that answers from your docs and remembers the customer
  • A sales or ops agent on WhatsApp that can look up orders or create tasks
  • An in-product copilot (the same pattern this documentation site uses)
  • Scheduled check-ins: follow up, remind, or run a workflow without a human in the loop

​
Get set up

Do this in the Studio dashboard before you write code.
1

Create an account and a team

Sign in at studio.chat-atp.com. Create or join a team so agents, keys, and members live in one workspace.
2

Create an agent

Give it a name, a job, and a model. Keep the first version narrow — one job, one audience.
3

Add knowledge

Upload the docs, policies, or URLs the agent should cite. Attach that knowledge base to the agent.
4

Turn on memory if the agent should remember people

Use agent memory for shared facts. Use user memory for preferences and history tied to external_user_id.
5

Connect tools only when talk is not enough

HTTP APIs and MCP servers let the agent do work, not just answer. Start with one tool you can test.
6

Issue a Developer API key

Dashboard → API keys. You will send it as Authorization: Bearer chatatp_sk_....
7

Talk to the agent

Preview in Studio, use the CLI, or send a first message from the Quickstart.

​
How teams usually adopt it

  1. Build in Studio until the agent is useful in the preview chat.
  2. Put it on one channel — WhatsApp, web, or your own UI.
  3. Integrate with the Python SDK, JavaScript SDK, or raw HTTPS when you need the agent inside an existing product.
  4. Operate with automations, schedules, usage, and the CLI so the agent keeps working after launch.
You do not have to use the SDK on day one. Many teams never leave the dashboard and CLI until they embed.

​
Choose an integration path

​
Production notes

  • Base URL: https://chatatp-agent-builder-backend.onrender.com
  • Auth: Authorization: Bearer chatatp_sk_...
  • Keep keys on a server when you can. Docs widgets and public embeds should use a restricted key.
  • Self-hosted or staging hosts go in baseUrl / base_url on the client.
The Copilot on these docs is a Studio support agent on the same stack. Ask it how a feature works, then confirm against the page.