Quiver

System documentation

Operate Quiver.

Learn how to initialize the context, run developer marketing work through explicit states, connect your agents and feed measured results back into the next decision.

New to Quiver? Follow the focused first-30-minutes guide before using this page as the full system reference.

Bootstrap

Start with the system, not a blank prompt.

Quiver is an agentic developer marketing system. It keeps product context, customer evidence, active work, shipped output and measured results connected so people and agents operate from the same approved state.

  1. 01

    Create the workspace

    Name the organization and choose its slug. Hosted workspaces get a shared address at your-slug.quivergtm.dev.

  2. 02

    Choose the team size

    Founder includes up to three seats. Team includes unlimited seats. Both hosted plans include the current hosted feature set.

  3. 03

    Connect a model account

    Add Anthropic, OpenAI, Google, OpenRouter or another OpenAI-compatible endpoint. Your account determines model cost and usage policy.

  4. 04

    Initialize the context

    Paste the website or describe the product. Quiver drafts the starting model; you review assumptions before relying on it.

  5. 05

    Take an agent key

    Onboarding ends by handing you an MCP key, shown once, plus your workspace MCP URL. Browser clients can sign in with OAuth instead.

  6. 06

    Run the first session

    Choose Strategy, Create, Feedback, Analyze or Optimize. Every session starts from the active approved context.

  7. 07

    Close the loop

    Save the work, move it through production states, log the result and review what should change before the next cycle.

Architecture

The system model

Quiver applies familiar engineering properties to developer marketing. These are product behaviors—not a metaphor layered over generic chat.

Source of truth

The active marketing context gives people and agents one approved model of the product, audience, positioning, proof and hypotheses.

Version history

Context and artifacts keep their history. You can inspect changes, restore earlier versions and prevent silent drift.

Explicit states

Artifacts move through Draft → Review → Approved → Live → Archived. Generated output does not become published truth by accident.

Interfaces

The Content API serves approved content to websites. MCP lets external agents operate the system through structured tools.

Observability

Campaigns connect the context, evidence, sessions, content, tasks and outcomes behind an initiative.

Feedback loops

Results can produce proposed context changes. A human reviews what the system carries into the next cycle.

Team boundary

Workspaces and team access

  • Each hosted workspace has its own subdomain, context, team, provider keys, tokens and tenant-scoped data.
  • Admins manage billing, provider keys, tokens and team access. Members operate the product. Other workspace users are read-only.
  • Invite teammates from Settings → Team. Founder supports three seats; Team supports unlimited seats.
  • People can belong to multiple workspaces and switch from the sidebar. Each workspace keeps its own operating state.

Model layer

Models and keys

  • Quiver sends model calls directly through the provider account you connect; Quiver does not resell or meter model usage.
  • Add providers in Settings → AI providers. Keys are encrypted at rest and are never displayed again.
  • Set one default model or select different models for session modes, research processing, performance synthesis and utility jobs.
  • OpenRouter can provide access to multiple model families through one account. OpenAI-compatible endpoints can use their own model identifiers.
  • Test connection sends a small request so you can verify the key and model before saving.

Agent runtime

Session modes

Modes give the agent a job boundary and load the context most relevant to that job. Pick one directly or describe the outcome you need and let Quiver route the session.

Strategy

Use for positioning, ICP, message architecture, campaign planning and decisions that shape what the team should do.

Create

Use for production work. Choose the artifact type and build from approved context, relevant evidence and earlier work.

Feedback

Use for qualitative input such as call notes, objections and reactions. Turn raw evidence into findings, next steps and proposed context changes.

Analyze

Use for interpreting campaign, content or channel results. Separate observations from conclusions and preserve what the team should learn.

Optimize

Use for improving existing pages, copy, signup flows and onboarding. Evaluate the current work against the active audience and positioning.

Source of truth

Marketing context

The active context stores the product model agents should use: positioning, ICP, messaging, customer language, proof, hypotheses and brand voice.

  • Make a direct edit when the new fact is already confirmed.
  • Use proposal review when research or performance suggests a change that still needs judgment.
  • Proposals add to lists rather than rewrite them. A new proof point, customer quote, hypothesis or competitor is appended and every existing entry stays as it is. Only something shown to be wrong is corrected: one entry, or one field, with what is wrong stated next to it. Entries already in the context are dropped before you see them.
  • Proof points, customer quotes and hypotheses keep their sources: a quote is verbatim with who said it and where, a proof point names where it can be checked, and a hypothesis starts as untested with what would validate it.
  • Every save creates a version. Inspect the history or restore an earlier state when needed.
  • The active version is injected into every session automatically.
  • Assumption marks context drafted without direct evidence. Confirming or correcting the field clears the marker.

Production state

Artifacts and explicit states

  • Artifacts move through Draft → Review → Approved → Live → Archived.
  • Revisions preserve version lineage instead of overwriting the decision history.
  • Link artifacts to campaigns so later sessions can see the initiative they belong to.
  • Moving work to Live creates a later reminder to record results and close the loop.

Operating scope

Campaigns connect the work

A campaign is the scope that connects an initiative's sessions, evidence, artifacts, content, tasks and performance. It is how Quiver keeps the plan, execution and outcome traceable.

  • Use status, priority, owner and dates to distinguish planned work from active execution.
  • Attach new sessions and artifacts to a campaign when they serve an existing initiative.
  • Use campaign performance summaries to review linked outcomes without reconstructing the work from separate tools.

Content infrastructure

Content, with an interface

Content in Quiver keeps markdown, production state, SEO and social metadata, authorship, tags, repurposing lineage, distribution records and metric snapshots together.

  • Use All, Calendar and Drafts views to inspect the editorial system from different operating perspectives.
  • Link derivative content to its source so repurposing preserves lineage.
  • Log metric snapshots over time instead of replacing the last known result.
  • Record a distribution for every place a piece went live. The URL is required, because it is what later matches analytics data back to the piece.

Live URLs are recorded for you

Set your public site once in Settings → API tokens: the site address (for example https://www.example.com) and the path your content lives at (for example /blog/{slug}, which defaults to /{slug}). From then on, publishing a piece records a website distribution with its live URL automatically, and renaming the slug of a published piece updates that same record instead of adding another. Nothing is duplicated if you publish twice, and a workspace with no public site configured is unaffected.

Content API

Public interface

Published content is available as structured JSON with its markdown body and SEO/social metadata. Quiver remains the editorial source of truth while the website controls presentation.

GET https://quivergtm.dev/api/public/content
GET https://quivergtm.dev/api/public/content/[slug]

Release notes

Changelog, drafted from merged pull requests

A changelog is a content type, not a separate product. Entries are content pieces with contentType: changelog, so they move through the same draft and published states, carry the same SEO and tags, and are served by the same public Content API as everything else.

  1. Your agent drafts. Point it at the pull requests you merged since the last entry. The changelog-drafting skill tells it how to turn them into release notes: grouped by user-visible change rather than by commit, leading with what someone can now do, internal refactors left out, one short paragraph each. It saves the result through MCP as a draft.
  2. You review and publish. The draft lands in Content like any other piece. Edit it, tag the release (a tag such as v2.4.0 becomes the release label), and publish when it reads the way you want it to. Nothing is published on your behalf.
  3. It appears on your site. Published entries are served by /api/public/content?contentType=changelog, so your site renders them wherever you want. Quiver’s own changelog, at /changelog, is that API rendered — full entries inline, newest first, grouped by month, with its own RSS feed.

Quiver never talks to GitHub. Your agent already has whatever repository access you gave it; Quiver’s job is to store the entry, keep its history and publish it.

Evidence layer

Customer research

Store calls, interviews, surveys, reviews, forums, support tickets, social posts, community exports and field notes beside the work they should influence.

  • AI processing extracts summaries, themes, sentiment, Voice of Customer quotes, product signals and hypothesis evidence.
  • Star important quotes so approved customer language can inform Strategy and Create sessions.
  • Track whether evidence validates, challenges or is neutral to an active hypothesis.
  • Generate a Linear-ready clipboard payload when needed. Quiver does not currently write directly to Linear.

Competitive layer

Competitors, watched on a schedule

A workspace can watch up to three competitors, and up to fifteen pages for each one. Quiver re-reads those pages on your schedule, notices what actually changed, and writes what it means for you against your own marketing context.

Who pays for what

Read this first

Fetching the pages is Quiver’s cost. Reading a competitor’s page and hashing it to see whether it moved is on us, and a page that did not move costs nothing beyond that fetch — no analysis, no model call.

Analysing what changed is your cost, through the provider key you connected. Only pages whose content actually moved are analysed: one small call per changed surface, then one call that pulls those findings together against your context. Nothing sends fifteen pages to a model in one prompt. This is why the cadence is yours to set, and why an agent connected over MCP can pause scanning or change how often it runs but can never switch it on: starting to scan is the workspace agreeing to spend its own tokens, and that is a person’s decision.

The surfaces

Eleven named surfaces, read in this order so that if a run runs short the pages a positioning argument turns on are already in hand: Homepage, Pricing, Product, Changelog, Blog, Reviews, Careers, About / profile, Docs, GitHub and Social. Every field in every surface is optional, and each surface shows a coverage figure, so a thin reading is shown as thin rather than presented as a complete picture. Changes are reported per field with the old and new value, not as an opaque “something changed”.

The cadence is the only clock

  • Set it in Settings → Competitors: off, monthly or weekly. Only an admin can change it. Workspaces created now start on monthly; an older workspace that has never touched the setting reads as off.
  • There is no “scan now” anywhere in the product. A competitor is re-read when its own clock says it is due, so nothing can be made to scan more often than you asked for.
  • off does not mean unmapped. Adding a competitor still reads their homepage once to learn which surfaces they have, whatever the cadence — you just get no scans until scanning is on.
  • Pausing a single competitor leaves it and its history alone and stops it being scanned, without changing the workspace cadence.

Adding one, and switching scanning on later

  • Adding a competitor reads their homepage to discover their other surfaces, then — if scanning is on — captures one baseline immediately rather than leaving an empty profile until the next daily run.
  • Adds are capped at five per rolling 24 hours per workspace, because each one spends fetches. Editing a competitor and removing one cost nothing and are never refused, so correcting a mistyped URL never costs you an add.
  • If you added competitors while scanning was off, turning it on catches up: anything still watching only its homepage has its surfaces discovered, and anything never scanned gets its baseline. That spends fetches and your tokens on purpose — it is what you just opted into — and it runs once, on the real transition, not every time you save the same cadence.

Baseline first, comparison afterwards

The first reading of a competitor is a baseline: a profile, not a change report. There is nothing behind it to compare against, so claiming a diff would be inventing one. A baseline is still read against your own context — where you overlap, where they claim what you claim, where they claim something you cannot match, and what that implies — but it proposes no context changes, because one reading of one competitor is not evidence to change your source of truth.

From the second scan onward you get the change-over-change brief: threat assessment, positioning, content and product opportunities, the change log and the watch list. Each brief is saved as an artifact of type competitor_analysis, and any context changes it suggests arrive as proposals you accept or dismiss on the Context page. A competitor is also re-baselined if Quiver changes how it reads pages, rather than reporting every page as changed on the strength of a technical difference.

The watch list

Nothing to configure. Each brief ends with up to eight standing things to re-check for that competitor — “watch for a freemium tier”, “track hiring in enterprise sales” — and that list is fed into the next scan, so the model has to say whether each item moved. It is how a one-off report becomes a standing watch. You can edit the list by hand, and anything you added is kept ahead of model-generated items when the list is full.

The score, and what it cannot tell you

The 0–100 number beside a competitor’s name, with its sparkline, is a momentum reading: how much is happening over there. It is explicitly not a judgement about how good they are, and a higher number does not mean a better competitor. It is four observed signals, weighted:

  • Momentum, 35% — how many tracked fields moved on this scan. Twenty or more scores full marks.
  • Review standing, 25% — the rating on their reviews page, rescaled, nudged by the balance of praise and complaint themes.
  • Publishing, 20% — blog posts plus changelog entries seen on this scan. Twelve or more scores full marks.
  • Hiring, 20% — open roles on their careers page. Twenty-five or more scores full marks. It is the cheapest available proxy for where they are investing.

Read it as a trend for one competitor, not as a ranking across them. Only signals Quiver actually observed are scored, and the weights are shared out across those — a surface it could not read is left out rather than counted as a zero, so a competitor with no careers page is never confused with one that is hiring nobody. A baseline has no earlier reading to compare against, so momentum is not scored at all on a first scan; the score comes from whatever else was read. When nothing at all could be read there is no score, and Quiver shows none rather than a number that would mean nothing. Two competitors are still only comparable when their coverage is.

Over MCP

Read: list_competitors, get_competitor, get_competitive_intel

Manage: add_competitor, update_competitor, remove_competitor

Operate: run_competitor_scan, set_competitive_intel

An agent gets the same rules you do, not a back door. run_competitor_scan runs the schedule early and scans only what is already due; calling it again costs nothing and answers with when the next scan lands, rather than failing. add_competitor shares the same five-adds-a-day cap. And an agent may move between monthly and weekly, or turn scanning off, but it cannot turn scanning on when it is off: that is the decision that commits your model tokens, so it stays with an admin in Settings → Competitors.

What is stored. A competitor’s raw page text is never persisted, returned by the API, or written to a log. Quiver keeps a content hash per page — enough to tell whether it moved — and the structured extraction for the fields each surface declares. Briefs and watch lists are written from those extractions, never from a copy of their site.

Feedback loop

Performance changes what happens next

  • Log quantitative metrics and qualitative observations in the UI or through MCP.
  • Use synthesis to capture what worked, what did not and what the evidence can actually support.
  • Review proposed context updates as pending, approved or rejected.
  • The close-the-loop queue surfaces shipped work that is still waiting for results.
Quiver does not silently train on your company or rewrite its own source of truth. The loop improves future work by carrying approved evidence and decisions forward.

Work layer

Hosted plans

Tasks turn recommendations into owned work

The built-in task system is part of hosted Quiver and is not included in the open-source edition.

  • Attach tasks to campaigns, artifacts, content, research and sessions.
  • Strategy, Feedback, Analyze and Optimize sessions can propose next steps. Select the useful ones, assign an owner and create them in the system.
  • Use assignees, due dates, reminders and dashboard queues to keep work accountable.
  • Moving an artifact to Live creates a “Log results” task due in 14 days for the person who shipped it.
  • Operate tasks over MCP with list_tasks, create_task, update_task and complete_task.

Feedback

Reporting a bug or requesting a feature

The speech-bubble button in the workspace header, next to notifications and the theme toggle, opens the feedback form from anywhere in the app. One form covers both — it asks whether you are reporting a bug or requesting a feature, so there is nothing to choose before you start typing.

The form can also receive three optional fields describing the situation, so nobody has to ask what you were doing: userEmail, replayUrl — a link to your PostHog session replay, so the exact session can be watched back rather than reconstructed from memory — and quiverContext, a single line holding your workspace, plan, user id and role, the page you were on and the id of the object it shows, the deploy’s git commit and environment, your browser, viewport, timezone and locale, and the last few JavaScript errors your browser raised.

Those three are sent on every submission but are only recorded if the form declares a hidden field with the matching name; Fillout ignores the rest. So a form that declares none of them still works perfectly, and adding one starts capturing it immediately with no change to Quiver.

Nothing you wrote is attached automatically. No prompts, session messages, artifact, content or research bodies, context values, object titles or API keys are ever included — only what you type into the form itself.

Agent interface

MCP server

MCP lets compatible agents read and write Quiver through structured tools. Your agent environment can keep its broader context and connections while Quiver remains the system of record for developer marketing work.

Connect Claude.ai

Open Settings → Connectors → Add custom connector and paste the full workspace MCP URL:

https://<your-workspace>.quivergtm.dev/api/mcp

Keep the detected OAuth settings: Sign in now, automatic client registration and no custom request headers. Approve the connection after Quiver sign-in. The workspace comes from the URL and actions are attributed to the signed-in member. Add and approve each workspace separately.

Connect a local client with a token

For clients that support a static authorization header, create an API token with the mcp scope in Settings → API tokens.

{
  "mcpServers": {
    "quiver": {
      "type": "http",
      "url": "https://<your-workspace>.quivergtm.dev/api/mcp",
      "headers": { "Authorization": "Bearer qvr_..." }
    }
  }
}

Tokens are workspace-scoped and revocable. OAuth-capable local clients can use the browser sign-in flow instead of storing a static token.

Example operations

  • “Save this draft as content and attach it to the launch campaign.”
  • “Log this customer call as research and show which hypotheses it challenges.”
  • “Show shipped work still waiting for results.”
  • “Propose a positioning update from this week's approved evidence.”

Tool surface

Context: get_context, get_context_history, propose_context_update, apply_context_update, restore_context_version

Campaigns: list_campaigns, get_campaign, create_campaign, update_campaign, update_campaign_status, delete_campaign

Artifacts: list_artifacts, get_artifact, save_artifact, update_artifact, update_artifact_status, archive_artifact, delete_artifact. update_artifact can also move an artifact to a different campaign.

Performance: log_performance, get_performance_log, get_close_the_loop_queue, list_proposals, action_proposal

Content: list_content, get_content, save_content, update_content, add_distribution, log_content_metrics, get_content_metrics, get_content_calendar, archive_content, delete_content

Research: list_research_entries, get_research_entry, save_research_entry, update_research_entry, delete_research_entry, list_quotes, update_quote, delete_quote, get_linear_payload

Sessions: list_sessions, get_session, delete_session

Tasks: list_tasks, create_task, update_task, complete_task

Workspace: get_dashboard_summary

Agents write drafts; people publish

An agent cannot publish content, and there is no setting that lets it. save_content always creates a draft, and neither it nor update_content accepts a status at all, so an agent cannot even ask. Content is publicly readable through the Content API the moment it is published, so promoting a piece — or taking it back down — is something you do in Quiver. An agent can still edit a piece that is already published; that does not unpublish it, and publishing from the Quiver app is never restricted.

Propose before applying

Use propose_context_update when a change needs human review. Use apply_context_updateonly when a person explicitly asks to change the active context immediately.

Each proposal has an op. add sends only the new items for a list field (proofPoints, customerLanguage, activeHypotheses, competitiveLandscape, messagingPillars, wordsToUse, wordsToAvoid). correct fixes one list item, named by its current text in replaces, or one other field, and says what_is_wrong. A correction of icpDefinition sends only the sub-keys it changes, never text. A proposal that would rewrite a whole list, repeats an existing entry, or leaves out a quote's source or a proof point's evidence is refused with a message saying why.

Packaging

Deployment and billing

Open source

MIT licensed and free to self-host. A strong fit for technical founders and startups comfortable running the application, database, authentication and updates. The built-in task system is not included.

Hosted Quiver

Ready-to-use shared workspaces, simple team invitations, managed infrastructure and hosted-only features such as tasks. Founder supports three seats; Team supports unlimited seats.

  • Both hosted plans include the current hosted feature set and differ by seat allowance.
  • Annual billing costs ten months—two months free compared with monthly billing.
  • The hosted trial lasts 14 days, requires a card and can be canceled at any time.
  • Manage cards, invoices, plan changes and cancellation through Settings → Billing.