Configure Docs

Configure gives your agent a user-approved Memory Profile: identity, preferences, connected app context, imported memories, and memories written by other agents. Users connect with Configure OAuth or from inside chat. Your server reads approved context securely through the Configure server, exposes Configure tools to the model, executes Configure tool calls, and writes back bounded memory after the turn. Every call is gated by what the user approved, and users can revoke access from their Configure profile page at any time.

Fastest path: give your agent the skill. Paste this into Claude Code, Codex, or Cursor in your app's repo:

Read https://configure.dev/skill.md and follow it to add Configure to this app.

That line is the whole instruction: the skill walks your agent through the entire Quick Start end to end, and your only step is approving one browser sign-in and reviewing the diff. Details at Set up with your coding agent.

What every path builds is the same loop: read the profile every conversation, use the tools in the turn, write back after; see The loop.

All docs pages, indexed for agents: https://docs.configure.dev/llms.txt (add .md to any page URL for plain markdown).

Want to see it work before creating an account? Test mode (sandbox) gives you a synthetic user plus test keys, no signup: curl -X POST https://api.configure.dev/v1/sandbox/provision and every example in these docs runs.

Start here

Find your row. Each one is a complete path, and the first two need no integration code at all.

You are	Start	Why
An agent or client that speaks MCP	Connect https://mcp.configure.dev: Set up MCP	The configure_* tools appear natively, sign-in included. This is the ideal integration.
A coding agent working in a repo	Paste the line above: Set up with your coding agent	The skill runs the whole setup for you.
Shipping a product on the Vercel AI SDK	Configure with the Vercel AI SDK	One adapter import, one route handler.
Shipping a product, own model loop	Quick Start	Sign-in, then the loop in your chat route.
Building in Python	Python SDK	Same loop, Python surface.
A product with no sign-in flow	Users without sign-in	App-local profiles, no OAuth.

Still unsure, or pairing two of these? Choose your integration has the five-minute recipe for each shape. Most teams add Configure to an agent they already have; build a new Configure agent only when you want the packaged chat shell.

Integrate an existing agent

Use this when your product already has an agent, chat UI, or model loop.

1. Install and run setup:

npm install configure
npx configure setup

2. Add Configure OAuth to the app's existing sign-in options.
3. Store Configure OAuth tokens server-side (on the Link fallback, listen for configure:linked and send the returned token to your backend).
4. On the backend, create configure.profile({ token }) and read the profile at the start of each conversation.
5. Expose profile.tools() in your existing model loop and route configure_* calls through profile.executeTool().
6. Commit bounded memory with profile.commit() after read-backed turns.
7. Give users a place to manage permissions after sign-in (settings page or integrations list).

Build a new agent

Use this only when you want a fresh Configure-backed chat shell.

npm install configure
npx configure setup
cp -R node_modules/configure/template ./my-agent

Then customize .env, public/brand.css, public/brand.js, and server.mjs.

Server flow

npx configure setup asks for a target: set up Configure for yourself, or for your users. The personal target configures a personal MCP client and writes no .env. The developer target (npx configure setup --users for non-interactive runs) opens the Configure dashboard, provisions your account, and writes five values to .env: CONFIGURE_API_KEY (your sk_ secret key), CONFIGURE_PUBLISHABLE_KEY (pk_, browser-safe), CONFIGURE_AGENT (your agent handle), and the CONFIGURE_OAUTH_CLIENT_ID/CONFIGURE_OAUTH_CLIENT_SECRET pair behind the sign-in button.

import { Configure } from "configure";

const configure = new Configure({
  apiKey: process.env.CONFIGURE_API_KEY,
  agent: process.env.CONFIGURE_AGENT,
});

const profile = configure.profile({ token });
const tools = [
  ...yourTools,
  ...profile.tools({
    connectors: ["gmail", "calendar", "sheets"],
  }),
];
const executeTool = (toolCall) =>
  toolCall.name.startsWith("configure_")
    ? profile.executeTool(toolCall)
    : executeYourTool(toolCall);

const response = await model.run({
  messages,
  tools,
  executeTool,
});

await profile.commit({
  messages,
  response,
});

Host-side reads are available when your app deliberately owns a preloaded approved context slot:

const read = await profile.read({
  sections: ["identity", "preferences", "summary"],
});
const approvedContext = read.profile.format({ guidelines: false });

Configure does not mutate your system prompt. Keep Configure tools available in the same turn: the model reads and searches the profile with configure_profile_read and configure_profile_search, and saves and deletes memories with configure_profile_remember and configure_profile_forget.

Default model tools (the six profile.tools() returns with no options):

• configure_profile_read
• configure_profile_search
• configure_profile_remember
• configure_profile_forget
• configure_profile_import
• configure_connect

Connector and action tools are opt-in per turn and should match the capabilities your hosted/product surface requested and your app supports:

const tools = profile.tools({
  connectors: ["gmail", "calendar", "sheets"],
  actions: ["email.send"],
});

Action tools change external state. Listing a tool is capability, not permission: execution fails closed when linked state, connector state, permissions, scopes, approval state, clear user intent, or runtime policy are missing.

Run your product confirmation or hosted approval path before dispatching the final external write.

Gmail, Outlook, Calendar, Drive, Notion, and Google Sheets are connectors, connected securely through Configure; every connector call runs through the Configure server under the user's grant. Model-callable functions are tools.

Key Boundaries

• Secret keys (sk_) stay server-side.
• Publishable keys (pk_) are for browser Link and hosted UI.
• OAuth access and refresh tokens stay server-side.
• Link fallback tokens go to your backend. Do not place them in the model prompt.
• The model receives Configure tool definitions and Configure tool results. If your app explicitly preloads approved profile context, keep that path app-owned and keep Configure tools available.
• API keys resolve the acting agent for writes. Do not let request bodies, display names, or user input choose storage locations.