Use Pioneer With Your Agent

Humans: tell your agent to read this page

Agents: follow these instructions

If you are an agent reading this page, this section is your setup procedure. Do not try to do it silently, and do not ask your user to read this page: explaining Pioneer to them in their own terms is your job.

a) Make sure your user has an account. Ask them to sign up at app.usepioneer.ai with Google or their work email if they have not already. Every plan, including the free tier, can use the API. Wait for them to confirm before continuing.

b) Ask for a connection. No agent can mint its own credential, so ask your user for one. Right after signup they land on a page with a label field and two buttons: Create an API key (for agents that run on a computer) and Create an MCP server (for chat assistants without one). Tell them which of the two you need and suggest a label (your own name is a good one, like "Claude Code"), then they press the button and paste the value back to you. Either value appears only when they press the button, and is shown once. The same two buttons live in the app for good, under the account menu, then API and MCP, where API keys and MCP servers are separate lists. If your user already pasted a credential, use it and do not ask for another.

c) Configure yourself. Store the key where your harness keeps secrets (an environment variable such as PIONEER_API_KEY, never a file you commit and never the chat transcript), read the API reference before making any call, and offer to save a skill so this setup survives past the current conversation. The section for your own harness is below.

d) Create their first pipeline. Setup is not finished until leads are coming in. Ask your user the one thing only they know, what they sell and who buys it, turn that into a goal, and create the pipeline yourself. Step by step in The first pipeline below.

e) Offer to connect their network. Pioneer can tell your user who they already know who could introduce them to a lead, but only once their network is in the product. Offer it, and follow Connect their network below if they say yes. Do not push: their contacts are private, and the feature is beta behind an allowlist.

Set up API access (agents with a terminal)

Claude Code, OpenAI Codex, Cursor, Devin, Hermes, OpenClaw and any agent you built yourself can call Pioneer directly. This is the simpler path: no extra process, and the full reference is one page.

1. Put the key in the environment your commands run in: export PIONEER_API_KEY=pioneer_sk_...
2. Send it as a bearer token against https://app.usepioneer.ai/api/v1, for example curl -H "Authorization: Bearer $PIONEER_API_KEY" https://app.usepioneer.ai/api/v1/pipelines
3. Save the skill file below so the next session starts already configured.
4. Create one pipeline per goal, then read leads back and work the board. The API reference has every route.

If a call returns 401 or 403, stop and ask the user to check the key in the app rather than guessing at the auth scheme.

Set up MCP access (chat-only assistants)

claude.ai, ChatGPT and other assistants without a computer of their own accept a connector instead. Pioneer's MCP server is a protocol adapter: every tool it exposes maps to one API endpoint, so there is no capability here that the API does not also have.

1. In the app, open the account menu, then API and MCP, then Create MCP server on the MCP servers box. Label it so you can tell your connectors apart later.
2. Copy the MCP URL shown right after creation. It looks like https://app.usepioneer.ai/api/mcp/pioneer_sk_.../mcp
3. Paste it into your assistant's connector settings. In claude.ai that is Settings, then Connectors, then Add custom connector. In ChatGPT it is the connector or custom tool section of settings.

MCP servers are listed separately from API keys on that page, and MCP URL on a row shows the URL again.

The MCP URL contains your API key. Treat it like a password: never paste it into a shared conversation, never commit it, and revoke it on the API and MCP page if it leaks.

The tool-to-route map, the inspector command, and the OAuth caveat live in the API reference.

The first pipeline

A pipeline is one research goal: who to find, and why they would buy. Do not hand this back to your user as a form to fill in. Write the goal from what they told you, create it, and show them what came back.

1. Ask what they sell and who buys it. One sentence is enough, and it is the only thing you cannot infer.
2. POST /pipelines { "goal": "..." }. Phrase the goal specifically (a segment, a geography, a trigger), never as "find customers".
3. Discovery runs in the background. Poll GET /pipelines/{id}/leads no faster than every two seconds, and expect it to fill in over minutes rather than instantly.
4. Read one lead in full with GET /leads/{entryId}, then summarize a handful in your user's own terms: who the company is, why it matched, who to reach there.
5. Record their judgment as they give it, with PATCH /leads/{entryId} (status, bucket). That judgment is what teaches the pipeline, and it is wasted if it stays in your chat transcript.

If they would rather steer it themselves, the same thing is a form at app.usepioneer.ai/pipelines, which also suggests niches based on what Pioneer already knows about them.

Connect their network

My Network is your user's own private, researched network, and it is what turns a lead into a warm introduction: the lead, then the person behind the deal, then whoever your user already knows who can reach them.

Check access first. GET /network/docs returns the full agent guide for the feature as Markdown, or 403 forbidden if the account does not have it. The feature is beta and allowlist-gated, so a 403 is a normal answer: say it is not enabled for their account yet and move on. If you do get the guide, read it before calling anything else under /network.

Then fill it, source by source. Nothing enters the network unless your user hands it over, so your job is to name the sources they have and offer to do the work. Every source ends the same way: one line per person, into POST /network/contacts { "input": [...] }, which answers 202 with { added, duplicates, enriched, invalid }. Read invalid back to them (dead links, shared mailboxes like info@), then follow progress with GET /network/contacts and its summary block rather than asking them again.

A line identifies a person: a LinkedIn or X profile, any page they are identifiable from (own site, GitHub, Substack, a bio page), or an email address, bare or named (Jane Doe <jane@acme.com>). Names alone are weak; always pair a name with a link or an address.

Below are the sources worth offering, strongest signal first. They are prompts your user can paste to you, or you can offer them in your own words. Only ever send Pioneer the people. Never the message bodies, never the meeting contents, never the files.

1. LinkedIn connections export. Their whole graph, in one file, and the single highest-volume source.

I exported my LinkedIn connections. Read Connections.csv from my
Downloads folder and add every person to my Pioneer network.

Tell them where to get it: LinkedIn, then Settings & Privacy, then Data privacy, then Get a copy of your data, then Connections. The mail arrives within minutes. The CSV has First Name, Last Name, URL, Email Address, Company, Position: send the profile URL as the line, and the email when the URL is missing.

2. Sent mail. Who they actually email is stronger signal than who they are connected to.

Go through the last two years of my sent mail, pull out the people I
emailed personally, and add them to my Pioneer network. Send Pioneer only
names and email addresses, never the contents of any email.

Skip automated senders (noreply@, notifications@, ticketing, newsletters) and shared mailboxes. Someone they emailed more than once, by hand, is a real tie.

3. Calendar. Meeting someone is a stronger tie than emailing them.

Look through my calendar for the last two years, list everyone I have
actually met with (skip internal-only and all-day blocks), and add them
to my Pioneer network. Only the attendees, not the meeting titles or notes.

External attendees of small meetings are the gold here. Drop invites they declined, recurring internal standups, and anything with more than ~20 attendees.

4. Phone contacts. The address book is usually their oldest, most trusted layer.

Export my phone contacts and add the ones with a real name and an email
or LinkedIn to my Pioneer network. Skip businesses and services.

5. WhatsApp, iMessage, Telegram, Signal. People they text are close ties, and the export is contacts-only by design.

From my WhatsApp chats, list the individual people I message (not groups,
not businesses) and add the ones you can match to an email or a LinkedIn
profile to my Pioneer network. Do not read or share any message contents.

6. X / Twitter. Mutuals and DMs, not followers.

Add the people I follow who also follow me on X, plus anyone I have DMed,
to my Pioneer network as their X profile URLs.

7. Slack workspaces they share with outsiders. Community and partner Slacks are dense with warm ties.

Go through the shared and community Slack workspaces I am in, list the
external people I have DMed, and add them to my Pioneer network.

8. CRM and investor tools. Anything already curated is a clean import.

Export my contacts from HubSpot (or Salesforce, Attio, Affinity, Pipedrive)
and add every person to my Pioneer network.

9. GitHub, Discord and other work communities. For technical users this is often where the real network lives.

List the people I have collaborated with on GitHub (co-authors, reviewers,
maintainers of repos I contributed to) and add their GitHub profiles to my
Pioneer network.

10. Alumni, cap table, cohort and Notion lists. The lists they already maintain by hand.

Here is my angel investor list / my YC batch directory / my university
alumni spreadsheet. Add everyone in it to my Pioneer network.

Whatever else they have access to counts too: Google Contacts, Superhuman, Luma or Partiful guest lists, Substack subscribers, a conference attendee list, an old CRM export. The rule is the same: one line per person, only the people.

Then use it. Once contacts are researched, ask the network plain questions on their behalf ("who can introduce me to battery OEMs?"). Warm paths on specific leads additionally need the connect_to_leads preference, which is off by default: ask before turning it on, never quietly.

They can do all of it by hand instead: My Network in the sidebar, then Add contacts. My Network is the human version of this section.

A user's network is theirs alone: never per organization, never visible to teammates, never exported anywhere by you.

Claude.ai in a browser, step by step

If you use claude.ai (the web app), Pioneer connects as a custom connector. No API calls, no terminal, no skill file needed.

Claude in a browser cannot install itself, so this is the one path a human has to click through. Create the MCP server, copy the MCP URL beside it, then in claude.ai open Settings, then Connectors, then Add custom connector, and paste the URL. Claude can then create pipelines, read leads, and work your board on your behalf. Claude Code, which runs on your machine, uses the API path above instead.

Which agents work

Whatever agent you already use is supported. The only requirement is an HTTP request with a bearer token, or a settings field that accepts a connector URL.

• API path (agents with a terminal): Claude Code, OpenAI Codex, Cursor, Devin, Hermes, OpenClaw, and anything you built yourself
• MCP path (chat-only assistants): claude.ai, ChatGPT, and other tools that only accept connectors

If yours is not named here it is still supported: the list is examples, not a compatibility matrix. Both paths use the same key, and there is nothing Pioneer-specific to install.

Best practice: put Pioneer in a skill

Do not re-explain Pioneer to your agent every session. Save it once as a skill, the reusable instruction file most harnesses support (.claude/skills/, .agents/skills/, AGENTS.md, a custom prompt library, whatever yours uses), and the agent picks it up automatically from then on.

A good Pioneer skill does four things:

1. Says where the key lives. Read it from an environment variable such as PIONEER_API_KEY. Never paste a key into the skill file itself, and never commit it.
2. Tells the agent how to get a key when there is none. If the user pasted one, use it. Otherwise walk them through creating one in the app (account menu, then API and MCP), because no agent can mint one.
3. Points at the API reference. /docs/api is the whole contract: base URL, auth, endpoints, conventions. The skill should say to read it rather than guess routes.
4. Names the job. "Find and qualify leads matching X, keep the board current, report new relevant leads" beats a generic "use the Pioneer API".

Here is a skill you can copy as-is:

# Pioneer (lead research)

Use Pioneer to find and qualify leads: https://usepioneer.ai/docs/api is the
full API reference. Read it before calling anything.

## Auth
Send `Authorization: Bearer $PIONEER_API_KEY` against https://app.usepioneer.ai/api/v1.
If `PIONEER_API_KEY` is unset, or a call returns 401/403, stop and ask the user
to create or fix the key in the app: account menu, then API and MCP, then
Create API key. The key is shown once, and every plan including the free tier
can create one. Never print the key back to them.

## How to work
- One pipeline per goal, phrased specifically: POST /pipelines { "goal": "..." }.
- Read results with GET /pipelines/{id}/leads, and one lead in full with
  GET /leads/{entryId}.
- Act on leads with PATCH /leads/{entryId} (status, bucketId). That judgment is
  what teaches the pipeline, so record it rather than keeping it in chat.
- Wrong researched value: POST /leads/{entryId}/mark-inaccurate.
  Missing value: POST /leads/{entryId}/search-more.
- Warm introductions: GET /network/docs first, and treat 403 as "the account
  does not have My Network". Contacts only ever enter the network from a
  paste the user hands over: POST /network/contacts { "input": [...] }.
- Async endpoints return 202. Poll the matching GET, no faster than every 2s.
- Explain results to the user in their terms. Do not make them read the docs.

Once that file exists, "check Pioneer for new leads on the EU climate pipeline" is a complete instruction.

What to hand your agent, and what to keep

Give your agent the API key and the goal. Keep the judgment: which leads are worth pursuing is the part Pioneer is built to hand back to you, and every approval or rejection your agent records on your behalf should be one you would have made yourself.

Start with the API reference. If you want to understand what your agent is actually doing, Your Pipeline & Board explains the product it is driving.