> ## Documentation Index > Fetch the complete documentation index at: https://www.sapientpriors.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Start here > What Priors does, the three words you need, and the five API calls that most products use. This page is for a developer who has never used Priors. After you read it, you know what an agent is, what the five main calls do, and which page to read next. It takes about five minutes. You call Priors from your own backend, with an API key. Your own users never hold a credential of ours. ## What Priors does Priors gives your product a memory. You send Priors the things that happen: messages, notes, documents. Priors turns them into memories. Later you ask a question, and Priors answers from those memories. You do not manage the memories yourself. You do three things: 1. Create an agent. 2. Send the agent observations. 3. Ask the agent questions. ## Three words The API uses three words on every page. Learn them here. | Word | Meaning | | - | - | | **Agent** | One memory with a purpose. You create it, and you own it. Everything the agent learns stays in the agent. | | **Thread** | One conversation with an agent. A thread gives the agent recent context. The memory belongs to the agent, not to the thread. | | **Observation** | One thing for the agent to learn from: a message, a note, or a piece of a document. | The most important rule follows from these words: **a fact learned in one thread is available in every thread of the same agent.** Threads keep conversations separate. Memory keeps facts together. ## The five calls The table below lists the calls that most products use. Each row says what the call does and what the response contains. | Call | What it does | What the response contains | | - | - | - | | `POST /v1/agents` | Creates an agent. You become the owner. | Status `202` and `"status": "initializing"`. Check again until the status is `ready`. | | `POST .../threads` | Opens a conversation. | Status `201` and a `thread_id`. | | `POST .../observe` | Sends observations to learn from. The agent does not answer. | Status `202` and an `observation_id`. Check again until the status is `committed`. | | `POST .../observe-and-enrich` | Sends a message, then returns the memories that relate to it. | Status `200` and `response_context`, which is text for your own model. | | `POST .../observe-and-respond` | Sends a message, then writes an answer. | Status `200` and `response_context`, which is the answer. | ### Which answering call to use Choose one of the three ways to ask an agent: * You have your own language model: use `observe-and-enrich`. Priors gives you the memories. Your model writes the reply. * You want Priors to write the reply: use `observe-and-respond`. * You build a chat screen and want the reply as it is written, with links to source files: use `chat/stream`. Every answering call also learns from the message you send. A question becomes a memory too. ## Two calls do not finish right away Two calls return before the work is done. For these calls you **poll**: you call `GET` again every second until the status changes. * After `POST /v1/agents`, poll `GET /v1/agents/{agent_id}` until `status` is `ready`. * After `POST .../observe`, poll `GET .../observe/{observation_id}/status` until `status` is `committed`. All other calls return when their work is done. ## One agent for each of your customers Give each customer their own agent. An agent has its own memory and its own storage, so nothing crosses between two of them. Keep your own record of which `agent_id` belongs to which customer. Inside one agent, send `X-SP-End-User` with your own identifier for the person a request acts for. That keeps one person's conversations separate from another's on the same agent, while the memory stays shared across the agent. See [Call Priors from your backend](/docs/walkthroughs/call-from-your-backend). ## Where to go next Every call in the order you use it. Each call shows the request, the success response, and every error with what to do. The five calls above, one after another, with the responses. Every error code, its cause, and what to do. API keys, one agent per customer, and naming the person each request acts for. Request rates, file sizes, images per message, agents per organization. What a call costs and what happens when credits run out. Every word this documentation uses, defined once. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.