Your brief, your account, and the workspace

Since the settings page was split, three screens do what one used to: Your brief (/settings/brief), Your account (/settings/account) and Workspace settings (/settings/workspace). The split is by owner: the brief is the workspace's working document, the account is yours and follows you between workspaces, and the rest is administration. The old /settings address still works and opens Your brief.

The brief

Your brief holds the brief: the facts, voice, guardrails and banned terms every pitch is drafted against, plus what the studio has learned from your team's edits. The studio writes to the brief while it is still researching a new workspace; saving the brief yourself takes it over for good: the studio stops writing to it, and later research is dropped rather than merged over a human's corrections.

Two kinds of block, and you can tell them apart by looking. What the studio knows is the brief itself, a green line down its edge, nothing to type into, and the percentage beside its heading says how much of what the studio asks for it has. What you can tell it is a grey panel with a box in it, and it holds one question at a time: answer it and the answer goes into the brief in your own words. Edit my brief turns the first block into the second, which is the moment saving takes the brief over.

Under it sits Your standing deck, and under that the rest as two lines you open when you want them: every other question the studio would ask, and a rescan of your site.

Your standing deck

A pitch deck is mostly about you: what you do, the proof it works, how an engagement runs, the ask. Those slides do not change from one prospect to the next, so the studio writes them once for the workspace instead of inventing them again for every company you look at.

Write it on Your brief drafts it from your brief: six to eight slides, one call, about half a minute. Read it, fix any slide with its pencil, and it is saved for good; the deck a pitch shows is the deck you approved, not one a model wrote while you were not looking. Writing or replacing it needs the admin or owner role, because every deck the workspace sends after it is built from those slides; anyone in the workspace can read it.

What each pitch adds is one slide. The studio inserts a slide about that company (the one thing the pitch rests on, the evidence behind it, and what they will say back in the speaker notes) straight after your opening slide, and fills in your prospect's name and business wherever a slide left a gap for them. Nothing else about the deck is rewritten, and no separate call is made to build it, so a deck now appears the moment you open its tab.

Three gaps a slide can leave for the studio to fill: [company], [what they do] and [the wedge]. Anything else you leave in brackets stays in brackets (the studio's mark for a word it did not write) for you to fill before you send.

Remove it and every pitch goes back to writing its own deck from scratch, one call at a time. Write it again replaces it, and loses your edits to it.

Two lines in the brief are not yours to type. Who can sign in (allowedEmails:) is set in Workspace settings, and how the workspace pays (plan:) is set by how it was created. Edit either and the save still succeeds; the line is simply rewritten back to what is true.

Three parts of the brief the editor does not own. The brief is a text box every member of the workspace can reach, so the lines that decide what the workspace is allowed to do (and anything nobody else should read) are not one edit away from anybody who can type:

• allowedEmails: who can sign in. Changed on the access list in Workspace settings → Workspace, never by typing in the brief: an edit that changes those lines saves everything else and leaves the list where it was.
• agency: whether this workspace may create client workspaces of its own. That is your plan, and only Prospektor sets it (a workspace whose brief is a committed file says it in the file). An edit that adds the line saves everything else and quietly drops it, so the brief never claims a plan the workspace does not have.
• integrations: a CRM or enrichment slot names a provider, and nothing else. API keys do not go in the brief: everyone who can open this page could read one. A save that types a key is refused and says so; name the provider here, and the key is asked for by the integration that needs it.

Saying no: the suppress list and your standing rules

Everything else in the studio is a way of asking it to find companies. The Suppress list (the second tab on Your brief) is the one screen that tells it who not to. It has two halves, and most workspaces need both.

Never these: the standing rule

One disqualifier per line, in your own words:

`` Mostly remote workforce No public-facing brand Anyone already using a competing platform ``

The box offers that example, marked For example, until you save something of your own, and the line under it always says how many rules are actually being checked, or that nothing is ruled out yet. A saved rule is your own text, in ink; the example is grey and says so. The two can never be confused.

These go into your brief, so they are checked everywhere the studio decides who is worth approaching: the Leads shelf, its refills, and the fit score on every run. A rule outranks a good score on every other dimension: where a target meets one, the pitch says so in its first line and scores the company down rather than talking itself round.

This is the half that keeps working on companies nobody has named yet, which is why it is worth writing even if your list is empty.

Never them: the named list

Add a company or a person, with a reason and one line of context. Most teams start with the same three: existing customers, our own competitors, and anyone who asked us to stop.

• A company entry is enforced before anything is spent. Starting a pitch against it is refused, a Beast Mode batch skips that row and says why, and the company never reaches the Leads shelf, including a card that was already sitting there before you added the entry.
• A person entry never blocks their employer. One person saying no is not their company saying it, so the pitch still runs; the studio is told not to name them as a decision-maker, address a draft to them or route an introduction through them, and if their name appears in the finished draft anyway the pitch carries a blocker saying so.
• Adding a company that is already on the list updates the reason and the note, and keeps the original attribution: who first said no is the fact worth keeping.

A website is worth adding on a company entry. Names get typed differently ("Acme", "Acme Ltd", "Acme Logistics") and the domain is what matches without anyone having to guess the spelling. Company names match with the legal form stripped, so Acme Ltd and Acme are the same entry.

The company box suggests as you type: pick a company and the website box fills itself, which is the fastest way to get an entry that actually matches. It goes quiet while you are adding a person; a colleague's name is not a company, and the studio never sends one anywhere to look it up.

Who added it, and taking one off

Every entry records who added it and when, and the screen shows both. So does the refusal when somebody tries to run a pitch against it; the person meeting the rule is usually not the person who wrote it, and lifting it is a decision they can only make knowing whose decision they are reversing.

Anyone in the workspace can remove an entry. The exception is an entry whose reason is asked not to be approached: that record is the studio's own proof the request was honoured, so removing it takes a second confirmation. Removing it does not un-send anything; it only means nothing stops the next pitch.

This is not the same as the "ruled out" companies on a finished pitch. Those are the studio's own working-out (same name, different company) shown so you can check which business it actually researched. The suppress list is your instruction, and the studio obeys it without arguing.

If saving your rules is refused

Your rules are kept in two places that have to agree: your workspace's record, and the negativeCriteria: block in your brief's frontmatter. The brief is what every run and every suggestion is actually scored against, so if the studio cannot write your rules into it, it will not tell you they were saved but refuses the save and says which part of the brief it could not edit.

That normally means the brief's frontmatter has been hand-edited into a shape the studio cannot safely rewrite, most often the same key written twice. Open the brief editor, fix the negativeCriteria: block so it appears once, and save your rules again. Nothing is lost in the meantime: until the save succeeds, the rules already in force stay in force.

If your brief lives in the repository

A workspace whose brief is a committed file is edited there and deployed, so the standing rules are read-only on this screen. The named list still works normally: it is stored per workspace, not in the brief.

Appearance: light, dark, or your machine's

Where it is: click your workspace's name at the top of the sidebar (the same menu that holds your other workspaces, Your account and Sign out) and Appearance is at its foot. That is the only place it lives; it used to be repeated at the bottom of the settings page as well.

The menu stays open while you click, so you can try light against dark with the studio visible behind it.

Three settings:

• System follows whatever this computer is set to, and keeps following it. A machine that switches to dark at sunset switches the studio with it, with no reload. This is the setting you start on.
• Light: always light, whatever the machine says.
• Dark: always dark.

Two things worth knowing:

It is saved on the device you set it on, not on the workspace. Your colleagues are not affected, and neither are your other workspaces; switching between clients never changes the studio's colour. Set it again on your laptop and your desktop if you want it in both places. A browser in private mode forgets it when the window closes.

Deliverables stay on white paper in either theme. A deck, one-pager, proposal or email is what your client will be looking at, so it is rendered the same way in both: a white sheet inside the dark studio. Shared links are all deliverable, so a share page is always light, whatever the person reading it has their machine set to. Printing is light for the same reason.

Your account: how you sign in, and your recovery number

Your account (/settings/account) is yours rather than any workspace's: it follows you into every workspace you belong to, and your colleagues each keep their own. Open it from the workspace menu at the top of the sidebar (the menu about you) rather than from the sidebar itself.

How you sign in. Every passkey on your account, what each one is, when it was added and when it was last used, with Add a passkey to make another and Remove to forget one. A passkey is Face ID, Touch ID, Windows Hello or a security key; the secret half never leaves your device and it only ever works on this site, which is what makes it impossible to phish. Add one per device you use. Removing one stops it opening the studio; you can still sign in with Google or an emailed link. Full explanation in Getting started.

Recovery phone number. So we can get you back in if you lose access to your email, and so there is a way to reach you about the account itself. Pick your country, then write the number the way you normally would. It is used for nothing else unless you allow it below (never sent to a model, never in a deliverable) and you can clear it here whenever you like.

Emails about your work. Four switches, all on from the start: these are reports on your own workspace rather than news about us, so nobody is asked permission for them. Each goes only to the person who started the work, never to the rest of the workspace.

• When a run finishes. A run takes two to five minutes and keeps going whether or not you stay on the screen, so when it lands the studio emails you, with the fit score, the angle it chose and the opening lines of the draft in the mail itself, not just a link.
• When a batch finishes. The runs inside a Beast Mode batch are not emailed one by one; fifty targets would be fifty emails. Instead one mail at the end names the companies that scored 75% or higher with their own scores, links to each, and says how many of the runs landed. Nothing over 75% is reported too, with what the closest actually scored.
• When fresh suggestions land. The Leads list refills itself when it runs short, and the search lands minutes after the look that fired it, usually after you have moved on. One mail per refill names the companies that landed, with their scores where the search scored them, and nothing more: a refill that found nothing sends nothing, and neither the opening suggestions you watch arrive during setup nor the search their hand-over starts is mailed; you are on the screen for both.
• When the studio starts writing in your voice. One email, once in the life of a workspace, the only one here that is not about a piece of work finishing. It arrives when three or more companies are on your Outcomes record with something on them the studio can actually read, which is the point at which what you have written down starts steering every pitch, call prep and inbound evaluation after it. It names the companies it read and where each one stands, says how many more are on record than one run reads, and tells you whether your saved edits are yet teaching it how you write. It never repeats your notes back at you; those stay in the record. After it, nothing like it is sent again, whatever else you record.

Any of them can be switched off here, or from the unsubscribe link at the foot of any one of them, whenever you like, one switch at a time, so stopping the batch mail leaves the run mail alone. Turning one back on is done here, never from a link.

Sign-in links, receipts and service notices come with having an account, so they are not on that list and cannot be switched off.

If your email provider starts rejecting mail to your address, or one of our emails is reported as spam, the studio stops sending anything but those sign-in links and service notices, and this block says so, rather than showing you a switch nobody touched in the off position.

How we may reach you. The four contact permissions, exactly as the first card asked them: product email, account texts, product texts, phone calls. Every one is off unless you turned it on, and unticking one here takes it back straight away. Account email (sign-in links, receipts, service notices) is not on the list, because it is part of having an account.

Neither of these is deleted when a workspace is: how you sign in to your other workspaces is not one workspace's to take away.

What this workspace is called

The name at the top of your brief goes on everything the workspace produces. If your workspace was created from a checkout, by an agency, or from an uploaded list, the first owner or admin to sign in is asked once to confirm it. Confirming rewrites the brief itself, so every pitch afterwards is composed under the name you agreed to.

To change it later, open Workspace settings → Workspace → Name, the field is there for the workspace's owner and admins, and saving it rewrites the brief the same way confirming did. Members see the name and who can change it. There is no need to edit the name: line in the brief editor by hand, and it is better not to: a hand-edited brief is treated as yours from then on, and the studio stops writing research into it.

The website this workspace is built on

Everything the studio writes comes from one site: the one it read when the workspace was created. Renaming a workspace does not change it (the name is a label, and the site is what the model reads) so a workspace relabelled for a different company will go on finding companies for the old one.

To point it somewhere else, open Workspace settings → Workspace configuration → Website, type the new address, and press Change. The studio reads the new site and rewrites your brief from it. That takes about a minute, and the dashboard says so while it runs.

More than one website

Some companies publish on several addresses, a product site beside a corporate one, a second-language domain, a brand mid-rebrand. Press Add another site, type it, and press Change. The studio reads them all and writes one brief: one set of facts, one voice, one fit thesis, one workspace. Four sites is the limit.

The first field is the primary: the address the rest of the studio uses, and the one the shelf and every run resolve to. ✕ removes a site, and Change then reads what is left. Every site is read again on each press, so this is the same minute of research either way.

Say it when you create the workspace, not after. If you already know a company has two addresses, the agency's New client workspace form has the same Add another site button; press it before you create them and the very first research reads both. Adding the second address afterwards works and costs you nothing but time: it is another minute of research, on a workspace that has just spent one.

Changing companies, not just addresses

The confirmation asks one more thing: whether to clear what the old site taught this workspace. The two cases are different and only you know which one you are in.

• Same company, new address. Leave it unticked. Your saved pitches, outcomes, voice examples and setup answers stay, and only the site reading is replaced.
• A different company. Tick it. Every finished run, saved pitch, voice example and your setup answers are deleted, and the brief goes back to a blank one the new research fills in. Type the workspace name to confirm. There is no undo.

The second one is what to use when a workspace is becoming something else. Leaving the old work in place is what makes a repointed workspace keep suggesting the old company's prospects: your setup answers say what to hunt for, and edited drafts are what the studio learned your voice from.

Some things survive either way, and deliberately. Who has access and everyone's role. Your suppress list, including anyone who asked not to be approached, which is a record Prospektor does not delete quietly. Networks your team imported. Your deliverable stylesheet. Your subscription: this changes the work, never the bill.

Your workspace keeps its name. If you have named it yourself, that name stays; changing the website does not rename anything you decided. If you have never named it (it is still called whatever was typed at checkout or by the agency that set it up), clearing lets the studio name it from the new site. Either way the name is one press away in Workspace name, just above.

Only the workspace's owner can do it. An admin can rescan the site the workspace already has, but not change which company it is. If your workspace is committed to the repository, its website is changed there and deployed.

The language the studio writes in

Every pitch, deck, email, prep sheet, intro draft and support answer comes out in one language: English, Spanish, German or Dutch. The studio sets it from your browser when the workspace is created (or from the language you bought it in, if you checked out on prospektor.ai in Spanish, German or Dutch) so most people never touch it.

To change it, open Workspace settings → Workspace → Language and press the one you want. It applies from the next run; nothing already written is translated.

Three things stay as they are whatever you pick. Company and product names, people's names and titles, and anything you quote. Your own words in the brief; the studio never translates what you wrote. And the brief's section headings, which stay English because the studio reads them by name.

Whichever you pick, the screens follow: every button, label and message in the studio and on a shared pitch, and the cookie notice with them.

The help you are reading follows too, article by article: one that has not been translated yet is served in English rather than going missing.

How the studio addresses a reader in what it writes (usted or tú, Sie or du, u or je) is yours to state under Brand voice in your brief; where you say nothing, it writes formally. The screens address you as tú, du and je.

Connect your apps

Workspace settings → Connect your apps. One grid holds every door out of your workspace and into it: Slack, HubSpot, Affinity, Close, your own Claude or ChatGPT, and a token for anything else. Each tile says what it is and where it stands: Connect, Connected, Reconnect. Press one and its panel opens underneath.

Only the workspace's owner sees this section. Each of these acts as the whole workspace from outside it, which sits with the owner beside deleting the workspace, not with administration.

A greyed tile is what is coming. Salesforce is next and there is nothing to press on it yet. Request an integration, top right, is how you say which app should come first: name it, press Send, and it is read when we pick the next one to build.

API tokens: letting another system call your workspace

A token lets something that is not a browser talk to your workspace: your CRM, an agent you are building, a script. Open Workspace settings → Connect your apps → Your own agent → New token, give it a label saying what will hold it, tick what it may do, set when it expires, and press Mint.

The secret is shown once. Copy it then; nothing can show it again. Losing it costs one revoke and one mint.

Only the workspace's owner sees it. A token acts as the whole workspace with nobody watching, so it sits with the owner beside deleting the workspace and changing roles, not with administration.

What a token may do

You tick these at mint, and a token never gains one later.

work:run and library:read are what your own Claude uses. Mint a token, press Copy setup for your agent, and paste it into Claude Code, Cursor or Claude Desktop; the Connect your Claude page has the whole of it.

claude.ai and ChatGPT need no token at all. Add https://studio.prospektor.ai/api/mcp in their own connector screens and press connect: Prospektor asks what the app may do, mints the token itself, and puts it on this card labelled with the app's name. See Connect your Claude.

Recording outcomes from a system that already knows them is the highest-value thing on this list. Every outcome you record sharpens the next pitch, prep sheet and inbound judgment this workspace writes, so a CRM that posts a closed deal here is teaching the studio in a way nobody has to type.

When it expires

Never, unless you pick a date. That is the default because an integration nobody wants to re-wire annually is the ordinary case, and a credential that stops at 3am is worse than one you can revoke in one press.

Pick 30 days, 90 days or a year at mint for the ones you want to end on their own: a contractor's script, a trial integration, anything a security review asks about. The row then says when it expires, and an expired token is refused from that date with no press from anyone. It stops counting towards your ten, so the slot comes back on its own.

An expired token's calls get a 401 naming the date, so whoever holds it knows to mint another rather than hunting a credential that looks fine.

Calling it

Send the token as a bearer header against /api/v1. Start with whoami, which costs nothing and tells you what the token holds:

`` curl https://studio.prospektor.ai/api/v1/whoami \ -H "Authorization: Bearer psk_…" ``

Record an outcome:

`` curl https://studio.prospektor.ai/api/v1/outcomes \ -H "Authorization: Bearer psk_…" -H "content-type: application/json" \ -d '{"company":"Northwind","stage":"meeting","note":"Booked from the CRM."}' ``

Start a pitch. It answers 202 and a poll URL; poll it until status is done (several minutes) and the answer carries the whole pitch, sources included. POST /api/v1/prep and POST /api/v1/paths work the same way, POST /api/v1/crm sends a finished pitch to the CRM you have connected ({"pitchId":"…"}, or company), and GET /api/v1/library reads a saved pitch by id or company:

`` curl https://studio.prospektor.ai/api/v1/pitch \ -H "Authorization: Bearer psk_…" -H "content-type: application/json" \ -d '{"company":"Northwind","website":"northwind.com"}' ``

Scan a company. It answers 202 and a poll URL; the reading arrives on that URL a few seconds later:

`` curl https://studio.prospektor.ai/api/v1/scan \ -H "Authorization: Bearer psk_…" -H "content-type: application/json" \ -d '{"website":"acme.com"}' ``

The version is in the path on purpose: /api/v1 shapes do not change under you. Everything else in the studio is free to.

Taking a copy out

export:workspace hands back your work: the brief, every run, the library, outcomes, the shelf, and the companies you ruled out with the reason each one was. Call it bare for a manifest: what is here, how many of each, and what is not in an export:

`` curl https://studio.prospektor.ai/api/v1/export \ -H "Authorization: Bearer psk_…" ``

Then one kind at a time, following next until it comes back null:

`` curl "https://studio.prospektor.ai/api/v1/export?kind=library" \ -H "Authorization: Bearer psk_…" ``

Three things an export never carries: your API tokens, your share links, and your members. Those are ways in and lists of people, not work. The manifest names everything it left out, so nothing has to be guessed at.

Twenty export calls a day, counted per workspace rather than per token, and each one is written down: which credential, when, how many records. Ask whoami to see what is left.

Limits, and what happens at them

A token makes 1,000 calls a day. Exports have a tighter day of their own: twenty, shared across every token the workspace holds, so minting a second token does not buy a second allowance. Recording outcomes and asking whoami are free of both counts: a write only makes the studio better, and a client that has to spend a call to find out how many it has left will spend them finding out. Scans draw on a separate daily budget of their own, one per token, so a script in a loop refuses itself and nothing else.

Past a limit you get a 429 saying which one, and the day rolls at midnight UTC.

Revoking

Workspace settings → Connect your apps → Your own agent → Revoke. It stops working immediately, for everything holding it. The row stays, showing when it was revoked and by whom, because that is the record you want if a key has leaked. Each row also says when the token was last used, how many calls it has made and when it expires, which is how you tell a dead credential from a live one (or a runaway from a quiet one) before pulling it.

A workspace holds ten tokens at once. Revoke one to mint another.

Slack: finished work, posted where the team already is

Workspace settings → Connect your apps → Slack. Paste an incoming-webhook URL from Slack and press Connect. A hello line lands in the channel straight away, so you know it works before the first pitch does.

From then on, every finished pitch, prep sheet and warm-intro search posts one short message there: company, fit score, the angle, the opening lines, and a link back into the studio. A batch of runs posts one summary, not one message per company.

Getting the URL takes a minute in Slack: Apps → Incoming WebHooks → Add to Slack, pick the channel, copy the URL it shows. It starts with https://hooks.slack.com/services/. Nothing else is accepted, and the studio never reads anything from Slack through it; a webhook only lets us post.

Only the workspace's owner sees this card, for the reason tokens are the owner's: the URL lets something post as your workspace. It is stored to post with and shown to nobody; the card names its last four characters, who connected it and how many posts have landed.

Disconnect stops it immediately. Nothing posted is copied here; what is in your channel stays under your Slack's own retention.

Reading your channels in: "monitor my Slack"

When the Slack panel shows Connect Slack instead of a field, the studio's own Slack app is available: press it, pick the channel in Slack, and you are back on the card connected. That kind of connection can also read.

Invite @Prospektor to a channel. That is the whole setup. It reads the last 90 days of that channel in and then reads along as your team writes; public channels it has been invited to, and only those. No picker: the invitation is the choice, and removing the bot from a channel forgets that channel. The card says what is being read (Reading #sales (412), #deals (38)): names and counts, never a message.

If the panel shows a Read channels button instead, reading is on demand for now: press it, and it takes the last 90 days of every channel the bot is in. Press Read again whenever you want the window moved forward.

What it is for. When you run a pitch or a prep sheet on a company your team has talked about, the messages that mention that company ride into the prompt as context (who already knows them, what was tried, what somebody heard) under the same rules as your recorded outcomes: never repeated in a deliverable, never searched, never treated as instructions. A company nobody mentioned gets the same run it always did.

What is kept, and for how long. The message text, who wrote it (their display name, not their Slack id), when, and the channel name. No files, no reactions, no direct messages, no private channels. It is a 90-day window, not an archive: a message older than that drops out as newer ones arrive, and Disconnect deletes everything read in, in the same press.

CRM: a finished pitch, pushed into HubSpot, Affinity or Close

One CRM at a time. A workspace pushes to a single CRM, so pressing another CRM's tile while one is connected says so and offers Disconnect rather than connecting a second. Nothing already pushed is touched by disconnecting.

Workspace settings → Connect your apps → HubSpot, or Affinity, or Close. For HubSpot and Close, press Connect HubSpot or Connect Close, approve Prospektor on their screen, and you are back, connected, with your portal or organization named. For Affinity, paste the key and press Connect. The panel says in one line what a push writes before you connect anything. Either way the account is named back straight away, so you know it works before the first pitch does. One CRM per workspace: connecting a second replaces the first, so only the one you are using says Connected on the grid.

Only the workspace's owner sees it, for the reason keys are the owner's: the connection writes into your CRM as your workspace. It is stored to push with and shown to nobody; the panel names the account, who connected it and how many pushes have landed.

Pushing a pitch. Open a finished pitch. Its Summary has Push to HubSpot, Push to Affinity or Push to Close beside Share. One press writes the company (found by its web domain if it is already there), the named decision-makers, and a note with the fit, the angle, the sources and a link back to the pitch. The deliverables stay here, where they stay current. Pushed, the button becomes Push again, with the link into your CRM beside it. Pushing the same pitch again updates those records rather than making new ones, keeps any address you added to a contact there, and if you deleted the lead in your CRM, the same press puts it back.

Disconnect stops it immediately. Nothing pushed is copied back here; what is in your CRM stays yours, under that CRM's own retention.

HubSpot

One press. Connect HubSpot opens HubSpot, which asks you to pick a portal and approve Prospektor for companies, contacts and deals. Approve, and you are back on the card, connected. Nothing to copy. If the card ever says Reconnect: the app was removed from your portal, or the person who approved it left. Press it and go round once more.

Connected with a token before? It keeps working; there is nothing to redo. Where the button is not offered yet, the old way still is: Settings → Integrations → Private apps → Create a private app in HubSpot, read and write on Companies, Contacts and Deals, and paste the token it shows. It starts with pat-.

A push writes a Company, the named decision-makers as Contacts, a Deal in your default pipeline's first stage, and a Note.

Affinity

Getting the key takes a minute: Settings → API, create a key, copy it. Affinity records everything the key writes as the person who made it.

Then choose the list. Affinity has no fixed deal, so a pushed pitch lands as a row on one of your own lists; the card asks which, and offers the company lists that key can write to. Change it any time on the same card; pitches pushed before the change stay where they went.

A push writes an Organization, a row on that list, and a note on the company holding the fit, the angle, the sources and the link back.

Only people we found a work email for become Persons. Affinity matches people by address, so creating one without an address would leave a duplicate behind on every push. The rest are named in the note instead, with their roles. Someone already in your Affinity keeps the companies and addresses they already had: a push adds, it never replaces.

Close

One press. Connect Close opens Close, which asks you to approve Prospektor for your organization. Approve, and you are back: connected, with your organization named, and nothing to copy. Your access is renewed quietly in the background; if the card ever says Reconnect, press it and go round once more.

A pasted key still works, and a workspace already connected by one stays connected; nothing asks you to redo it. To make one: in Close, Settings → Developer → API Keys, create a key and copy it. It starts with api_.

A push writes a Lead (found by its web domain if it is already in your Close, so nothing is created twice), the named decision-makers as that lead's Contacts, an Opportunity carrying the fit score as its confidence, and a Note on the lead holding the fit, the angle, the sources and a link back to the pitch. A person already on the lead is matched by address, then by name, and keeps every address they already had.

Then choose the status. Close opens a new opportunity in your organization's first status when nobody says otherwise, and the first status is simply whichever one your pipeline happens to list first, which can easily be something like Demo Completed, filing a company nobody has spoken to as a finished demo. So the card asks once, under New opportunities open in, and offers your own statuses with the active ones first. Change it any time on the same card; opportunities pushed before the change stay where they went. Until you choose, pushes keep working on Close's default.

One thing the Opportunity cannot have is a name. Close's opportunities carry a note, a confidence, a value and a status (there is no title field) so the deal name rides in the note, and Close's own screens show the opportunity as Unknown. That is Close's shape, not a failure of the push.

Members and access

Access is the workspace's email allowlist, managed from Workspace settings by its owner or an admin, named addresses only. Removing an address takes effect immediately, and takes that person's role with it. Sign-in is Google SSO or an emailed magic link; there are no passwords to reset.

Who added whom, and when

Every entry on the access list carries a line saying who put it there and on what date. It is there because "there is an address on this list and I cannot tell whether I added it" is a question the product should never make you guess at.

Three things worth knowing about that line:

• It starts from when we built it. Anything that was already on your list says added before Prospektor recorded this, and nothing can fill it in after the fact. Inventing a plausible name would be worse than the gap.
• A whole-company entry (one that looks like @yourcompany.com) shows the door it came through and no person, because nobody chose it: buying with a company address puts that company's domain on the list, which is how your colleagues walk in without being invited one at a time. Once an owner has settled it (below) the line also says kept by them, and the date.
• Some entries name a door instead of a person: by Prospektor when we put an address on by hand, or by their agency when the agency that set the workspace up did. We do not show you an address belonging to somebody who is not on your own list.

Everyone at your company can sign in: keep it, or narrow it

If you bought with a company address, your access list carries an entry like @yourcompany.com as well as your own address, and the list now says in words what it means: everyone at that company can sign in, including addresses that do not exist yet. That is how it has always worked; what is new is that the product says so, and that you get to decide about it.

Two answers, and only an owner may give either:

• Keep: you are happy for the whole company to walk in. Nothing changes except that the list stops asking, and records that you decided it.
• Narrow: the grant comes off, and from then on only the named addresses on your list can sign in. Everyone else at your company is signed out immediately.

Narrowing cannot be undone from inside Prospektor. Nothing in the product grants a whole company again: not settings, not us. If you narrow and then want a colleague back, add their address by name. Keeping, on the other hand, is not a lock: you can narrow a grant you kept, later, whenever you like.

Somebody from another company needs the owner's yes

Adding a colleague (anybody at a company already on your access list) works the way it always has: type the address, press Add, done.

Adding somebody from a different company is different if you are an admin rather than the owner. It becomes a request: the address is not added, that person cannot sign in, and the owner sees it on their own access list with Approve and Decline beside it. You will see it on yours too, marked as waiting for them.

This exists because letting a fourth party read every pitch a workspace has run is the owner's call; most often it is the agency that administers a workspace asking the client who owns it. An owner adding somebody from another company just adds them; there is nobody for them to ask.

Approving lets that person in exactly as an ordinary add does, and the access list then shows both names: who asked, and who approved. Declining leaves nothing behind: the person was never able to sign in, and is never told they were asked about.

A request goes when the person who asked does

A request belongs to whoever asked for it. If that person is later removed from the access list, their unanswered requests go with them, in the same act: the rows disappear from the list, and nobody named on them is let in.

This is what a request is. It is a question, and it needs somebody there to answer for it: an owner deciding on a request from a person the workspace no longer knows is being asked to vouch for a reason nobody can now give them. Left standing, that is exactly how it read: a row with no name beside it, waiting on an owner who had already removed the only person who could explain it.

Nothing else moves. Requests somebody else asked for stay exactly where they are, still waiting; so do requests we staged for you from our side. Nobody is emailed, because nothing was refused and nobody's access changed. And if you still want that person let in, ask for them again yourself; the request then carries your name, and you are there to answer for it.

Detaching from an agency follows the same rule. Their unanswered requests go with them; a request somebody else asked about one of their people stays, still waiting, because a request belongs to whoever asked it.

You are told when access changes

If you own or administer a workspace, you get an email whenever an address is added to it, removed from it, or given a role, saying what changed, who did it, and linking straight to the access list. A role change also emails the person whose role moved, which matters most when it moved down: losing a role is otherwise invisible until you try to use it.

You get one when a member asks to be an admin, headed approval needed because nothing has moved, and the person who asked is emailed if you decline. You also get one when an admin asks to add somebody from another company, headed approval needed, because nobody has been let in, and the admin who asked is emailed if you decline. Keeping a whole-company grant emails nobody: nothing about who can sign in changed.

You are not emailed about your own clicks, and somebody you have just added gets the invite instead of this notice. If nobody is recorded as the workspace's owner (which is true of a few of the oldest workspaces) the notice has nobody to go to and none is sent; ask us and we will set an owner.

Telling somebody they have access

Type the address, pick what they may do, and press Invite: one press puts them on the list, sets their role and emails them. The mail says what the workspace is, who set it up, and carries a sign-in link with their address already filled in.

Every named entry also keeps an invite link beside it, for sending the same mail again: a client who says the first one never arrived, or anyone added before this was one press. Sending it twice is fine. Whole-domain entries (@example.com) have no single inbox behind them, so the button reads Add and nothing is sent.

Did they ever arrive?

Beside each name, one clause answers it:

• joined 12 Aug: they signed in. Nothing more to do.
• invited 3 days ago · not yet arrived: the email went and nobody came. Send it again.
• not invited yet: they are on the list and nobody has told them.

Owners and admins see it; whoever can press invite is who needs to know whether it landed. Nothing else about anyone is shown: not when they were last here, not how often, not which door they signed in through. A whole-domain entry has no person behind it, so it carries no line.

Roles: owner, admin, member

Every named address on the access list holds one of three roles, shown beside it on the list. Your role on that same page says which one is yours and lists what it lets you do, and what it does not, with the role that would.

The short version: the ladder is about who joins, who administers and who destroys. It is not a read/write split. A member runs pitches and call preps, reads every run in the workspace, edits any deliverable, edits the brief's prose, mints share links and imports their own network. None of that changes with your role.

• Member: everything in the paragraph above. This is what everybody is unless somebody says otherwise.
• Admin: a member, plus the workspace's configuration: adding and removing people on the access list, sending invites, uploading the deliverable stylesheet, accepting or dismissing a rescan of the brief, managing a run or a share link somebody else started, and (in an agency workspace) creating client workspaces.
• Owner: an admin, plus the things nobody else may do: delete the workspace, change roles, settle a whole-company grant (keep it, or take it off the list for good), and approve or decline somebody from another company that an admin has asked to add.

The account that created a workspace is its owner, with one deliberate exception, which is the whole of the next section: when an agency creates a workspace for a client and names the client's email address, that client is the owner and the agency is an admin.

Changing somebody's role

Only an owner can. On the access list, each named address has a small role picker under it; choosing a role applies it at once, and everybody who owns or administers the workspace is emailed about it, including the person whose role changed.

Handing the workspace over is the same picker: choose owner for somebody else and you step down to admin in the same act. You keep members and the stylesheet; you lose deletion and roles. It is one action rather than two, so the workspace is never briefly owned by two people or by none.

A workspace can never be left with no owner. Demoting the last one, removing them from the access list, or asking us to free their address is refused with a message saying so, because appointing an owner is itself an owner's job, so there would be no way back. Give somebody else the owner role first.

Asking to be an admin

A member who needs more can ask for it. Your role on the access-list page carries one line, Ask to be an admin, and pressing it emails the owner. Nothing changes when you press it: no rung moves, nothing new opens, and the line then reads Asked to be an admin with the owner's address beside it, so you know who has it.

The owner sees the ask on their own access list and answers with one press; Make admin, or Decline. Declining tells you so, and leaves everything exactly as it was.

Two things worth knowing. Only the owner sees a request: a colleague's ask is between them and the owner, not something the rest of the workspace reads. And there is one rung to ask for: a member asks to be an admin, and nobody asks to be the owner, because owning a workspace is something its owner hands over rather than something anyone can request.

What an admin cannot do to an owner

An admin adds and removes members. They cannot remove an owner, and they cannot remove another admin; only somebody above a person can take their access away. Removing yourself always works, whatever your role.

Adding somebody back

A role is not restored by being let back in. Take an admin off the access list, add the same address again a month later, and they come back as a plain member; if they need the role again, an owner gives it to them again. This is deliberate: a role that came back on its own would be a power nobody granted and nobody saw granted, on a day nobody was looking.

That includes the person who set the workspace up. Being its original creator is not a role, and it does not survive being removed from the list either.

This holds however long ago they left, and however old the workspace is. A role recorded before this rule existed used to sit on the workspace unseen and come back on the day somebody was let in again; now it comes off as they arrive. The same goes for the workspace's original creator, on workspaces old enough that nobody wrote that down at the time.

One exception, and it is an old one. On a workspace created before roles existed (August 2026 and earlier) nobody on the list holds a recorded role, and everyone on it counts as an owner. There is nothing to take away and nothing to restore there, so anybody added to one of those arrives an owner, whether or not they have been on it before. Setting any role on such a workspace records everybody's current standing first and ends that, once.

One thing this is not. Writing out the name of somebody your @yourcompany.com grant already lets in is not adding them (they were already here) so it changes nothing about their role. If they are an owner, they stay one. Adding only ever clears a role where the person was genuinely outside.

The same is true the moment somebody is removed, and it matters most where a whole-company grant is on the list as well. Taking a named address off does not sign that person out if @yourcompany.com still admits them, but it does take their role, so what they come back as is a plain member, holding nothing above that. If you meant them to be out altogether, narrow the company grant too (above).

If an agency set your workspace up

Some workspaces are created by an agency or consultancy that runs Prospektor for their clients. If yours is one of them, Workspace settings carries a card called The agency above this workspace: who they are, which addresses on your own access list are theirs, and how either side ends the arrangement.

The workspace is yours

When the agency named your email address as they created the workspace, you own it and they are an admin of it. In practice that means they keep doing everything they do for you (running pitches, adding your colleagues, uploading your deliverable stylesheet, settling a rescan of your brief) and there are exactly two things they cannot do:

• They cannot delete your workspace. Deletion is the owner's, and the owner is you.
• They cannot remove you from it. An admin removes members, never an owner.

You can also do everything an owner does anywhere else: change roles, approve somebody from another company, settle a whole-company grant, and hand the workspace to a colleague.

Two honest limits:

• A workspace created without your email address on the form belongs to the agency, because at the moment it was made there was nobody else to give it to. That includes every row of a portfolio upload. The agency hands it over when you are on the list; see below.
• Workspaces created before 23 August 2026 were not changed. Nobody's ownership moved because we shipped a release. If your agency owns your workspace and you would rather own it, ask them to hand it over, or ask us.

Who pays for it

Nobody, during the beta: creating a client workspace is free, and the create form says so. Per-workspace billing exists and is switched off; when it is switched on, the agency answers one question as it creates the workspace, and the answer decides only who is billed, never who owns it.

• Bill me: one more workspace on the agency's own subscription. You never see a checkout. The agency can pause your workspace over its bill, and reopen it; it cannot delete it. While it is paused you see a locked screen with one button, Re-subscribe: pay with your own address and the same workspace opens as yours on the bill too, with the agency's unit released.
• They pay: the workspace is created locked and your invite says so. Sign in, press Subscribe, and it opens the moment payment clears. Everything the research found while it waited is there.

If the agency's own subscription stops, every workspace it was paying for pauses with it and reopens when it does. If you and the agency detach while the agency was paying, the workspace pauses until you subscribe yourself. Nothing is deleted in any of these; pausing is the only lever billing has.

Hand over to the client

An agency that owns a client's workspace hands it over from the same settings section: Hand over to the client, which makes the named client address the owner and steps the agency down to admin in one action. Nothing is briefly owned by two people or by none, and nothing about the work changes.

If the client's own address is not on the access list yet, the section says so instead of offering a button that cannot work: add them, then hand over.

Detaching: either side, immediately

Either side can end the arrangement, at any time, without the other side's agreement and with no waiting period:

• The client's owner presses Detach from ⟨agency⟩, and the agency comes off the access list.
• The agency presses Detach from this client from inside that workspace, and does the same to its own side.

Off the list means their whole-company grant too. If the access list carries @theiragency.com as well as their named people, that grant is what lets the rest of the agency sign in, so a detach takes it with the names, and the confirmation says so before you press. That is the one part of a detach that cannot be undone by repeating the opposite action: nothing in the studio can grant a whole company again, so putting the agency back means naming their addresses one at a time.

The screen tells you which entries are theirs before you decide: Theirs on this list names each one, and marks a whole-company grant as admitting everyone there, named on your list or not.

Nothing is deleted, on either side. Every pitch, call prep, share link, saved edit, network import and outcome stays exactly where it is, in the workspace, with whoever keeps it. Detaching removes access and the connection between the two workspaces; it removes no work.

Three things worth knowing:

• It takes effect at once, and both sides are emailed. There is no window in which the other side can stop it. If somebody can veto your leaving, you have not really been able to leave, so nobody can.
• The agency cannot detach from a workspace it is the only way into. That would leave a workspace nobody can open. The message says the way out: hand it over to the client first, then detach. This counts a whole-company grant as a way in: a workspace whose only access-list entry is @theiragency.com is refused the same way.
• A grant for a webmail domain is not the agency's to remove. If the access list carries something like @gmail.com, that admits everyone with an address there rather than one company, so a detach leaves it alone and tells you it did. Anyone from the agency using such an address keeps signing in until an owner uses Narrow on that grant.
• A client whose agency was paying will be asked to pay. If the agency's subscription stops covering the workspace it will pause, and the lock screen's Re-subscribe button reopens the same studio, everything kept, against your own card. Nothing is deleted while it is paused. A paused workspace cannot be detached from until it is reopened, because a paused workspace answers nothing: re-subscribe first, then detach.

If a detach happened in error, the two halves go back separately: the workspace's owner adds the addresses again from the access list, and we can re-seat the connection between the two workspaces. Ask support.

More than one workspace

An account can belong to several workspaces; the switcher at the sidebar's head (your workspace's name) lists them all and switches between them.

An agency workspace (one that can create workspaces for its clients) is marked (Agency) in that list, and the client workspaces it created are indented beneath it. With ten workspaces on one account, the one that runs the others is the one you can find at a glance.

Agency-flagged workspaces additionally get New client workspace in that menu, for the agency's owner or admins: name the client and a live, researched workspace exists before the next screen. A plain member of an agency workspace cannot create client workspaces: each one is a workspace that will be billed, with your agency's name on somebody else's screen.

Who owns what that form creates. Name the client contact's email and the workspace is theirs: that address is its owner and you are its admin, so you run it for them but cannot delete it or remove them. Leave the contact field empty and the workspace stays yours until you hand it over (Hand over to the client, on its settings screen). Either way you can end the arrangement later, and so can they: see If an agency set your workspace up above, which is written for the client and is worth reading before you explain it to one.

Name the client contact's email and they also get an invite email: it says your agency set the workspace up for them, names you, says in plain words that the workspace is theirs and what you can and cannot do with it, and links straight to sign-in with their address prefilled. The tick-box is on by default; untick it to set things up quietly and invite them later. Whether the invite was sent (or could not be) is shown the moment you land in the new workspace. That invite belongs to this one-at-a-time form; a portfolio upload mails nobody.

A whole portfolio at once

Below that form, Portfolio upload points the same act at a list. Paste one company per line (Company name, website, the website optional) or choose a CSV and it is read into the box. Extra columns are ignored, and a header row is recognised as the format rather than treated as a company. Every row becomes its own client workspace with the research already reading that company's site. A portfolio row names no contact, so each of those workspaces is owned by your agency until you hand it over; there is nobody else to give it to at the moment it is made.

• The agency's owner or an admin presses it, the same rule as the one-at-a-time form beside it. Anyone in the workspace can open the results screen and watch.
• Up to 50 companies per upload, three researched at a time. A longer list is refused with the number in the message rather than quietly cut short; split it and upload the rest as a second portfolio.
• Rows that cannot be used are named, one by one: a line that is neither a company name nor a website, the same company twice, or a company your agency already has a workspace for.
• You stay where you are. Creating one workspace moves you into it; creating forty cannot, so the switcher gains them and you stay in the agency. A results screen shows every row filling in, and it has an address: /portfolio reopens your newest upload and lists the ones before it. Leave it and come back; the upload keeps going with the tab closed.
• Nobody is emailed. Each new workspace starts nearly empty on the completeness bar on its own Your brief screen, and that bar is the list of what its company still needs to answer. Send them their workspace link when you are ready for them.
• Each one opens on work rather than on a spinner. When a row's research lands, the three companies that workspace would have been shown are read (a glance each, scored against the brief the research just wrote) so its Library already holds three fit scores under the tag Opening leads before anybody signs in. The Suggested shelf counts those three as already researched and finds three more, so nothing is offered twice. This is the portfolio door only: a workspace somebody made for themselves has a person in it pressing things already.

Creating client workspaces (one at a time or a portfolio at a time) is free during the beta. Per-workspace billing arrives later: at creation you will choose whether it bills your agency or your client pays to unlock their workspace.

The deliverable stylesheet

Workspace settings → Brand → Deliverable stylesheet (owner or admin): upload a CSS file and every deliverable (on screen, on shares, in print) is styled with it. The studio's own chrome never changes; the stylesheet reaches your work and nothing else.

What Prospektor can see about your workspace

Prospektor keeps an operator view of every workspace as a record, so accounts can be set up, paused and supported without anybody at Prospektor being added to your allowlist. It holds the workspace's name and id, who it was provisioned for, its plan, whether it is paused, the addresses on its access list, and, since 23 Aug 2026, how much it is used: when somebody was last signed in, how many sign-ins there have been, how many pitch runs, call preps and other research the workspace has run, and what those cost Prospektor to run.

Those are counts and dates only. Nothing records your navigation: no page views, no searches, no dwell time, no analytics and no session recording of any kind. And the operator view does not open your work: pitches, your brief's prose, share links and your voice examples still need to be on this workspace's own access list, which nobody at Prospektor is unless you put them there.

Two things are deliberately outside that rule and are named here because they are. Feature requests you send through the composer, and support chat conversations, are both read by the Prospektor team: the first is a message to them by definition, the second so that a question that keeps coming up becomes a fix. Each of those records the studio screen you were on when you wrote it, because "where were they when this went wrong" is most of what makes a bug report useful. That is the only place a screen is ever recorded, and only for something you deliberately sent.

Billing, pausing, deleting

• The subscription is $999/month per workspace, taken by Stripe through prospektor.ai; the studio itself holds no card details.
• A paused workspace means the subscription behind it is not being collected; the lock screen's button reopens the same studio with everything kept. If you paused it yourself the button says Resume the subscription and starts the same subscription again; if a payment failed or was disputed it says Re-subscribe and opens a fresh checkout.

Pausing or cancelling your subscription

In Workspace settings → Plan, one card above the danger zone. Only the owner can use it; it stops the bill for the whole team.

• Pausing stops the bill and changes nothing else. The brief, every pitch, the library, the network and everything the studio has learned about your voice stay exactly where they are, and one press brings them back. Use it for a quiet quarter rather than starting again later from nothing.
• Cancelling ends the subscription. Your work is not deleted; the workspace locks and stays as it is until you delete it separately.
• We ask one question first, and it is multiple choice. There is no box to fill in: pick the answer that fits and that is the end of it. It is the only thing we ask, and it is how we find out what to fix. If you picked "something is broken" or "the work is not good enough", the screen offers a support conversation before you go; a fault is usually fixable the same day, and cancelling stays one press away either way.
• Afterwards you may get one email from us asking why, in your own words. It comes from a person, it is not a form, and ignoring it is a perfectly good answer.
• If your workspace was set up by an agency, or is comped, or lives in the repository, there is nothing here to cancel; the panel says which of those applies and who to ask.
• If Stripe cannot be reached when you press the button, the studio stays open rather than locking you out of something you are still paying for, and tells you so. Your answer is recorded and a person stops the bill by hand.
• Changed your mind while paused? The lock screen has both doors: Resume the subscription starts billing again on the same subscription, and Or cancel it outright ends it without you having to resume and pay first.

• Workspace deletion lives in Workspace settings' danger zone, and only an owner may use it, not an admin, deliberately: it is the one act in the product that cannot be undone. Deleting does not cancel the subscription (they are two separate things, in two separate cards): cancel first, then delete if you also want the work gone. Deletion removes the workspace's records; there is no undo. A handful of workspaces are set up by Prospektor from the codebase rather than through the product; those say so and cannot be deleted from the danger zone at all; nothing is removed and support does it for you.
• Deleting an agency workspace does not delete the client workspaces it made. Every one of them keeps its own brief, its own pitches, its own library and everyone who could sign in to it, including you, because your address is on each client's own list rather than borrowed from the agency. The danger zone counts them before you press anything. One thing does stop: those workspaces read the agency's shared network, so once the agency is gone they see only their own imports and warm paths no longer reach across the group. If you want a client's own data gone as well, delete that workspace from inside it.
• What a deletion leaves behind: one unlinked row, and it names nobody. Prospektor keeps a single bookkeeping record per workspace so it can measure how many customers stay and how many leave. It holds no email address, no company name and nothing you or your team wrote: a signup date, whether the workspace was paid or comped, how it was created, when a deliverable was first saved in it, the dates it was paused or closed, and, if you were asked and answered, which option you picked from the cancellation list. That last one is a token from a fixed list, never anything you typed, because there is nothing to type. When a workspace is deleted, the identifier on that row is replaced with a one-way hash, so what remains cannot be linked back to you. Everything else (every pitch, prep, share, import, note and setting) is removed.
• Billing disputes and refunds are handled by a human over email; the support chat can gather the details but never touches money.

Who we hunt

/settings/hunt is the one screen that answers it. Everything deciding which companies the studio puts in front of you, in the order you would ask:

What we are looking for: your own sentence, the one every prospect is scored against.

Where, and how big: plain words, not filters. "DACH", "English-speaking countries", "anywhere" are all real answers, and so is "startups under 50". The studio weights towards them and tells you when something good sits outside.

Who already works, and why: the customers you named at setup and the reason each is a good one, plus which way you want to hunt from them. The strongest evidence on the screen: the studio weighs it above everything else when it goes looking.

The market around us: the competitors you named. The studio reads them as a map and hunts the territory around them rather than suggesting them to you.

What we keep looking for: anything you kept from the Leads screen's Describe the leads you want box. Every later search reads these.

What you have corrected us on: what you typed when a fit score was wrong. These overrule what the studio would otherwise assume about you.

Never these: your standing disqualifiers, shown here and edited on Suppress list, where the named companies they sit beside live.

Nothing on this screen is a separate copy of anything. Each part is the same field the brief already held, and every screen that changes one of them (onboarding, a fit-score correction, a lead search you kept) writes here.

The first three are editable in place, unless you have taken your brief over yourself; the studio stops writing to a brief somebody has rewritten, so it stops offering the boxes too.