> ## Documentation Index > Fetch the complete documentation index at: https://studio.chat-atp.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Introduction > What ChatATP Studio is, why it exists, and how to start building agents # 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](/docs/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 | | Traditional chatbot / widget | Custom LLM in your app | ChatATP Studio | | -------------- | ---------------------------- | ------------------------ | --------------------------------------------- | | Where it lives | One website or one inbox | One codebase | Dashboard + every channel you connect | | Memory | Session cookies, if that | You invent it | Agent memory and per-user memory | | Knowledge | FAQs pasted into a prompt | Homegrown RAG | Knowledge bases, documents, URLs, search | | Actions | Canned replies | You wire every tool | HTTP APIs, MCP, tools the agent can call | | Follow-up | Manual | Cron jobs you own | Automations and conversation schedules | | Shipping it | Embed a vendor widget | Rewrite for each surface | Studio UI, CLI, Python SDK, JS SDK, raw HTTPS | 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. | Concept | What it is | | --------------------- | ------------------------------------------------------------------------- | | **Agent** | The assistant you configure: personality, model, tools, knowledge, memory | | **User** | An end user in *your* product, identified by `external_user_id` | | **Conversation** | A persistent thread between one user and one agent | | **Message** | A single turn in that thread, including tool activity | | **Knowledge base** | Documents and URLs the agent can search | | **Memory** | Facts the agent keeps at agent level or per user | | **Automation** | A builder-owned trigger that runs the agent on a schedule | | **Schedule** | A conversation-level task the agent runs for a user | | **Developer API key** | How your app talks to that agent over HTTPS | 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](https://studio.chat-atp.com/dashboard) before you write code. Sign in at [studio.chat-atp.com](https://studio.chat-atp.com). Create or join a team so agents, keys, and members live in one workspace. Give it a name, a job, and a model. Keep the first version narrow — one job, one audience. Upload the docs, policies, or URLs the agent should cite. Attach that knowledge base to the agent. Use agent memory for shared facts. Use user memory for preferences and history tied to `external_user_id`. HTTP APIs and MCP servers let the agent do work, not just answer. Start with one tool you can test. Dashboard → API keys. You will send it as `Authorization: Bearer chatatp_sk_...`. Preview in Studio, use the [CLI](/docs/cli/overview), or send a first message from the [Quickstart](/docs/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 | You want to | Start here | | --------------------------------- | -------------------------------------------------- | | Understand the product | This page | | Send a first programmatic message | [Quickstart](/docs/quickstart) | | Work from the terminal | [Studio CLI](/docs/cli/overview) | | Embed in a JavaScript app | [JavaScript SDK](/docs/js/installation) | | Embed in a Python app | [Python SDK](/docs/python/installation) | | Call HTTPS directly | [API Reference](/docs/api-reference/overview) | | Open the builder | [Dashboard](https://studio.chat-atp.com/dashboard) | ## 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.