What is Pillar?

Pillar is an open-source copilot SDK that turns user requests into completed actions inside your app. Users say what they want, and the copilot navigates pages, pre-fills forms, and calls APIs on their behalf — using their existing session and permissions.

You install the SDK, define tools in your frontend code, and point Pillar at your docs. The copilot handles the rest.

The core mental model has three parts:

• Tools — Actions the copilot can execute in your app. Navigate to a page, open a modal, fill a form, call an API.
• Knowledge base — Your indexed docs and content. The copilot searches this when answering questions so responses come from your actual documentation.
• Context — The SDK automatically tracks the current page. You can optionally pass user role, app state, and custom data via setContext to make responses and tool suggestions even more relevant.

What Pillar replaces

Building a copilot yourself means stitching together several systems:

Pillar replaces all of these with one install. Four layers:

Use cases

Setup and configuration

Most products have an onboarding phase where users click through a lot of forms. Connect an integration, create categories, set thresholds, map fields, repeat. The more powerful the product, the more setup it needs, and the more users drop off before they finish.

With Pillar, users describe their configuration in plain text and the copilot does the rest.

Take a conversation analytics platform. A new user needs to create intent categories (bug reports, feature requests, billing questions, refund requests), add example phrases for each one, set up guardrails to flag when their AI gives pricing info, and connect their data source. That's maybe 20 minutes of form-filling across several pages.

With the copilot, they type:

"Set up intents for bug reports, feature requests, billing questions, and refund requests. Add a guardrail that flags when the agent shares pricing info."

The copilot creates four intents with example phrases, then creates the guardrail. One message, done.

This applies to any product where users configure a lot of things before they get value: alert rules in a monitoring tool, pipeline stages in a CRM, permission structures in an admin panel, tagging taxonomies in a content platform. The copilot turns a tedious multi-step setup into a conversation.

In-app task execution

"Invite sarah@acme.com as an admin." The copilot finds the invite tool, extracts the email and role, and opens the form pre-filled. The user confirms and it's done.

This works for any action your app exposes as a tool. Create a report, change a setting, archive a project. Users skip the navigate-find-fill-submit loop and just say what they want.

Support deflection

Users ask "how do I update my billing?" and the copilot navigates them to the billing page instead of generating a support ticket. It pulls the answer from your docs, then takes the user directly to the right place in the app. Questions that would have become tickets get resolved in seconds.

Why client-side execution

The AI reasons on Pillar's server, but actions run in the user's browser with their session. No credentials leave the browser. If the app requires 2FA, so does the copilot. The copilot can't do anything the user can't do.

You define tools as functions in your frontend code. They use the user's auth tokens and hit your APIs directly. No credentials pass through Pillar's servers.

Architecture

┌──────────────────────────────────────────────────┐
│                  USER'S BROWSER                   │
│  Your App + Pillar SDK                            │
│  • Tools execute in the user's session            │
│  • No credentials leave the browser               │
│  • Calls your backend with user's auth            │
└────────────────────────┬─────────────────────────┘
                         │
                         ▼
┌──────────────────────────────────────────────────┐
│                  PILLAR CLOUD                     │
│  • Reasoning engine (plans, chains tool calls)    │
│  • Knowledge base (RAG over your docs)            │
│  • Tool registry (synced from your code)          │
│  • MCP server + WebMCP (agent-ready integrations) │
└──────────────────────────────────────────────────┘

Your frontend renders the chat panel and executes tools. Pillar's backend handles AI reasoning and knowledge retrieval. Your backend is called by your tool handlers using the user's existing auth.

The SDK never talks to your backend directly. Your tool handlers do.

Pillar vs. alternatives

Next steps

Get started with the Quickstart, or read about the core concepts to understand how the pieces fit together.