Control plane
Autopilot
Routines, the Teammate, and Ask — the three surfaces where Papervine acts on the docs.
Routines, the Teammate, and Ask — the three surfaces where Papervine acts on the docs.
The Autopilot rail groups the three surfaces where Papervine acts on the docs rather than just rendering them: Routines (scheduled and triggered agent runs), Teammate (the chat agent), and Ask (the in-docs reader assistant). All three are gated behind a per-org Trialing entitlement.
Routines are functional; Teammate is still a scaffold. Routines can be configured, toggled, and run — runs execute on the background executor and land through the shared authoring backend. The Teammate page (Slack + integrations) is UI only, and parts of the Ask page persist while others are scaffold (see below). Where the spec and the implementation diverge, the spec wins.
Routines, Teammate, and Ask all run Claude over the tenant’s content with tools, and all
three write through a single shared authoring backend: GitHub-App write credentials → a
session branch → a draft buffer → save as a commit or PR. This is the same pipeline as the
authoring MCP and the web editor — never a parallel write path. Under
the hood they share one run primitive — { trigger, context, prompt, applyMode, output } —
with three frontends: scheduled/triggered (Routines), interactive from chat (Teammate), and
in-docs Q&A (Ask).
Agent runs that keep the docs current on their own: each automation is a trigger, a prompt, and an apply mode. When it fires, an agent reads the site’s content and makes the required edits on a draft session branch — the same authoring pipeline a human editor uses. Depending on the apply mode, the result either commits directly or waits for your review in the editor.
The page has two tabs: Configure (the catalog below) and Runs (the run history — every run with its status, what fired it, its result, credits used, and the agent’s summary or the error). A run that finishes without needing any edits shows as no changes — a real outcome, not a failure; a run awaiting review shows review needed. Click a run to open its detail view: the exact instructions the agent received (the run keeps its own copy, so later config edits don’t rewrite history), the files it changed, the full agent summary, model and token usage, and the resulting commit — or, for a pending run, the review actions.
Both the run list and a run’s detail view update live as it progresses — queued, running, succeeded/failed/review needed — with no manual reload, whether you triggered it yourself or a scheduled/webhook trigger fired it while you were watching.
Two built-in families, plus custom:
Update from code changes (watch a source repo and draft doc updates when APIs or features
change), Draft changelog, Fill gaps from assistant conversations (feed the
analytics content-gap engine into PRs), and Improve docs from user feedback.
Translate content (keep configured locales in sync), Fix broken links, Fix SEO issues, Fix grammar & typos, and Enforce your style guide.
A custom automation is the same configuration with your own name and prompt. Flipping any card’s toggle on creates it with recommended defaults; the gear opens its settings.
Every automation — predefined or custom — shares one config schema:
Content update (fires when a sync publishes new content), Custom schedule
(a cron expression, with presets), or Code change (fires when a push lands on a trigger
repository — typically a product’s source repo whose merged PRs should update the docs).
Each catalog entry offers the triggers that make sense for it and recommends one.Code change only) — the owner/name source repos whose pushes
fire the automation. When one is pushed, the run is told which files changed and can read
them to update the affected documentation.Automatically commits changes directly to the deploy branch;
Require review holds the change as an in-app draft for you to review before it lands
(see Reviewing a change below).owner/name repositories the run may read (never trigger
it), so the agent can consult their code while writing docs.Code-change triggers and context repositories need the GitHub App. Push webhooks only arrive from the App, and the run reads other repositories with the App’s installation token — a personal-access-token or public connection has neither. Connect the site with the GitHub App to use these; the automation’s configuration form says so if it isn’t. The repositories are read-only to the agent: its only way to change anything is the documentation itself.
Enabled automations also expose Run now — a manual trigger, which is also how you test one.
Runs are queued in Postgres and executed by a background executor (Trigger.dev; configured via
TRIGGER_SECRET_KEY). Without an executor configured, the page says so and automations simply
don’t run — nothing else in the dashboard or renderer depends on it.
The executor is deployed separately from the web app. TRIGGER_SECRET_KEY only lets the app
enqueue runs; the tasks themselves run on the executor’s cloud and have to be published there
(npx trigger.dev deploy) — a release distinct from deploying the site. A run that is enqueued
but has no published version to pick it up stays pending. In this project’s hosting, a push to
the main branch deploys both halves together (the site build, and a CI job that deploys the
tasks), so the two never drift apart; running your own deployment means running that
release step yourself.
Because the executor runs in its own environment, it also needs its own copy of the server configuration — it does not inherit the web app’s. A run reaches the database, the draft storage, the model provider, and the connected repositories, so the executor’s environment must carry the same database URL, object-storage credentials, AI configuration, and GitHub-App keys the app uses. A missing value surfaces as a run that fails immediately on its first step rather than as a degraded feature. This project keeps the two environments in sync automatically at deploy time; an executor you run yourself is configured wherever its tasks are deployed.
Each run is metered: its model usage is recorded and debited against the plan’s AI credits, and the total shows in the run history. A run whose organization has no spendable credits fails immediately with “out of AI credits” — before any model call, so a drained account never accrues charges it can’t pay.
Scheduled automations register their cron expression with the executor when you save them, and re-register when you change the schedule. Each tick re-reads the automation from the database before doing anything, so an automation you disabled or re-triggered stops running even if its schedule outlives it. Ticks are deduplicated by their timestamp: a redelivered tick never runs twice.
When an automation runs with Require review, its edits don’t ship — they wait as a draft
for you to approve. The run lands as review needed in the history, with three actions:
Automatically run would).The draft lives in the authoring layer as an ordinary edit session until you decide, so a pending review is just a draft with your name not yet on it. Until then it hasn’t touched your published docs. (A pending review doesn’t block the automation’s next scheduled run — accept or reject it to keep the queue clear.)
An agent run is the expensive part of Papervine — it reads your documentation and reasons over it across many model calls. Three things keep that from turning into a surprise bill:
Clicking Run now always executes, even when a scheduled run would have been skipped — useful when you want to re-check a site you haven’t edited.
A content-update automation whose own commit re-syncs the site does not re-fire itself: runs are deduplicated per commit, which is also what makes webhook redeliveries harmless.
The open risk is the output quality and auditability of agent-authored changes. Every run
lands through the same authoring pipeline a human uses, so its changes are reviewable in the
editor and in Git history — but an automation that drafts low-quality updates at scale is noise.
Prefer Require review until you trust an automation’s output.
An interactive agent reachable from chat. The surface is Slack-centric: you invoke it with
@papervine <prompt> in a channel, and the teammate answers questions and opens doc changes on
request.
The Teammate settings page is where you wire it up. A Connect your Slack workspace banner installs the Slack app — the teammate’s home. Below it, Enabled integrations lists the connectors the agent can currently draw on (empty until you connect one), and Available to your team is the catalog of connectors you can add — Notion, Google Drive, Linear, Jira, Confluence, Salesforce, HubSpot, Intercom, Plain, and more — each grouped by what it brings (documentation, communication, project management, customer support, CRM). Connecting a source lets the agent reference it when it answers and authors.
It shares the authoring backend with Automations — the distinction is interactive (Agent) vs scheduled/triggered (Automations), over the same underlying tools.
Why Slack. The reference product treats Agent as “your docs teammate in Slack” — it lives where the team already works rather than as a separate console, and threads give it conversational context and an audit trail for the PRs it opens. Open question: whether to also offer Teams, Discord, or a web console, or keep Slack the canonical home.
The plumbing (none of it built yet) needs a Slack OAuth app and per-org install (bot token), the
channels:read and chat:write scopes, a channel allowlist, and an events endpoint for
app_mention.
The management page for the same in-docs AI assistant, surfaced under Autopilot. This is not a fourth system — it is the settings surface the assistant calls for. The layout:
The Assistant page mixes two kinds of setting, and they’re stored differently on purpose:
docs.json. They describe what readers see, so they belong in Git
and are edited through the authoring layer rather than written to a
database column. These controls are still scaffold on this page until that write path is
surfaced here.Running your own deployment gets the same split from configuration alone: the operational
state from environment, the published behavior from docs.json — no dashboard required.