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 Continue with Configure or from inside chat. Your server reads approved context, exposes Configure tools to the model, executes Configure tool calls, and writes back bounded memory after the turn.

Most teams should start by integrating Configure into an existing agent. Build a new Configure agent only when you want the packaged chat shell.

Choose a path

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 Continue with Configure to the app's existing sign-in options.
3. Add inline Configure inside the chat + menu or integrations list.
4. Store Configure OAuth tokens server-side. If using Link fallback, listen for configure:linked and send the returned token to your backend.
5. On the backend, create configure.profile({ token }).
6. Expose Configure tools in your existing model loop and route configure_* calls through profile.executeTool().
7. Let the model call Configure tools for profile reads/searches, then commit bounded memory after read-backed turns.

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

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,
  memories: response.memoryCandidates,
});

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: configure_profile_read and configure_profile_search are the model-driven paths for overview, concrete memory retrieval, source-specific views, and exact attribution.

Default model tools:

• configure_profile_read
• configure_profile_search
• configure_profile_remember

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. Tool visibility is capability; execution still fails closed when linked state, connector state, permissions, scopes, approval state, clear user intent, or runtime policy are missing:

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

Gmail, Calendar, Drive, Notion, and Google Sheets are connectors. 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 paths.