Skip to main content
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. 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.

​
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.

​
Where to go next

The complete lifecycle

Every call in the order you use it. Each call shows the request, the success response, and every error with what to do.

Walkthrough 1: your first agent

The five calls above, one after another, with the responses.

Errors

Every error code, its cause, and what to do.

Call Priors from your backend

API keys, one agent per customer, and naming the person each request acts for.

Limits

Request rates, file sizes, images per message, agents per organization.

Credits

What a call costs and what happens when credits run out.

Terminology

Every word this documentation uses, defined once.