Sourcing agent
Shapes the schema this campaign needs, then upserts a creator record for every handle it finds.
Brings its own discovery. We hold no creator database.
POST/v1/schema/objects
A creator is not a company, so give it its own object
Nothing in a standard CRM has a handle, a follower count and a rate. Add an object that does, give partnerships a pipeline of their own, and every other part of the product — timeline, tasks, lists, views — treats it exactly like a company.
Who this is for
If this is not you, one of the other workflows probably is — they share every primitive and differ only in what the agents are pointed at.
The team
A brand or product team seeding a product with creators and paying for what ships.
What they end up with
Every creator you approached, the fit you judged them on, what was agreed, and what actually shipped.
The agents, and what each one is responsible for
These are your agents, not ours. This product ships no model and makes no decisions; it is the workspace they share and the record they leave. Each of them reaches it through the same API a person’s dashboard uses.
Fit agent
Writes the audience and rate data onto each creator with the source it came from, and shortlists or rejects them.
Brings the platform numbers, from wherever it can honestly read them.
Outreach agent
Drafts the approach, queues it, sends it, and chains the nudge.
Brings the mailbox or the DM account.
Campaign agent
Moves each partnership through its stages and records every deliverable as it lands.
Brings whatever it watches to know a post went live.
The handoff, in the order it happens
Every call named here is one this API serves — a test reads them back against the operation table and fails on anything invented. What an agent does between two of them is its own business, and ours ends at the write.
Give the workspace a creator
Sourcing agent
A custom object gets its own table, its own natural key and its own fields, and behaves like a core object everywhere else: activities, tasks, lists and views all work on it. Register the words for what happens to it while you are here.
- POST /v1/schema/objects
- POST /v1/schema/activity-types
- A creator object keyed on the handle, with platform, followers, niche and rate
- A deliverable_posted activity type
- schema_changed carrying the diff and who made it
Give partnerships their own pipeline
Sourcing agent
Stages belong to a pipeline, so a partnership is never offered a sales stage and a deal can only move within its own. Naming the pipeline is what creates it; there is nothing to make first. Give it a stage for each status a deal can close on, or closing has nowhere to land.
- PUT /v1/schema/stages
- GET /v1/schema/pipelines
- A partnerships pipeline: sourced, contacted, negotiating, agreed, delivered, won, lost
Upsert every creator, and shortlist them
Sourcing agent
The handle is the natural key, so the same creator found on two platforms by two agents is still one record. A list member carries a status and a reason, which is where "we passed on them, and here is why" lives.
- POST /v1/objects/{key}/records
- POST /v1/lists
- POST /v1/lists/{id}/members
- Creator records, upserted on the handle
- A shortlist, all at candidate
Write the audience numbers, and where they came from
Fit agent
A follower count with no source is a rumour. Send the source and the confidence with the patch and the person approving the fee can tell a media kit from a screenshot from a guess.
- PATCH /v1/objects/{key}/records/{id}
- PATCH /v1/lists/{id}/members/{member_id}
- field_changed on the creator, carrying the diff, the source and the confidence
- Member status qualified or rejected, with the reason
Queue the approach as a task
Outreach agent
The task points at the creator record and carries the message. A record marked do_not_contact cannot be given a task on a channel that reaches anyone — the API answers 409 do_not_contact rather than leaving it to the agent.
- POST /v1/tasks
- An email task linked to the creator record
- task_created
Approve the terms before anybody agrees to them
A human
A review task is work for a person: no channel that reaches anyone, no draft to send, just the decision and the note explaining it. Assign it to a human principal and it sits in their queue rather than the agents'.
- POST /v1/tasks
- POST /v1/tasks/{id}/complete
- A review task assigned to a human
- task_closed carrying the decision and the note
Send it, close it, chain the nudge
Outreach agent
Claim before acting; exactly one caller wins. The nudge points at the message before it, so a creator who never replied has one thread rather than four unrelated tasks with the same title.
- POST /v1/tasks/{id}/claim
- POST /v1/tasks/{id}/complete
- POST /v1/tasks
- task_closed with the outcome
- A second task chained on parent_task_id
Open the partnership as a deal on its own pipeline
Campaign agent
Name the pipeline and the deal opens at its first stage. A deal's own attributes are patchable even though its stage is not, so a reference field added to deal is how the collaboration points back at the creator.
- POST /v1/schema/fields
- POST /v1/deals
- PATCH /v1/deals/{id}
- One deal on the partnerships pipeline at sourced
- A creator reference on that deal
Move it as the campaign moves, and record what shipped
Campaign agent
A stage move is an event with its own route and its own activity, so nobody has to reconstruct when a deal became agreed. Each deliverable is an activity on the creator rather than a checkbox that overwrites the last one.
- POST /v1/deals/{id}/stage
- POST /v1/activities
- stage_changed to negotiating, then agreed, then delivered
- One deliverable_posted per thing that actually went live
Close it, and say what it was worth
A human
won or lost, and a loss needs its reason. The value on the deal is what you paid. The timeline is why you paid it, and it is still there next season when the same creator comes round again.
- POST /v1/deals/{id}/close
- status_changed to won or lost, carrying the reason
GET/v1/activities
Every creator you approached, the fit you judged them on, what was agreed, and what actually shipped.
Where a person steps in
None of these is a setting somebody has to switch on. Most are enforced by the API itself; the rest are enforced by the fact that the work sits in a queue until somebody takes it.
Before money is promised
A review task assigned to a human is the only thing standing between a draft and a commitment. It has no channel that reaches anyone, so it cannot accidentally be sent.
Before the first approach
The outreach task carries the exact words. Read it, rewrite it, or cancel it — the creator does not hear from anyone until an agent claims that task and sends it with its own account.
When a creator asks not to be contacted
Custom object records carry the same status column as a company, so do_not_contact means the same thing on a creator that it means on a person, and the API enforces it the same way.
When the schema needs to change
Adding a field, an object or a stage is a write like any other, and it lands on the timeline as schema_changed with the diff and who made it. Standard fields can be hidden but never dropped; everything else soft-deletes and purges after thirty days.
GET/v1/schema
What the workspace looks like afterwards
Read it back and this is what is there. None of it was configured in a settings screen: every object, field, stage and activity type in this list was written through the API by an agent, and every change is on the timeline as schema_changed with the diff attached.
/v1/schema
- creator
- A custom object, keyed on the handle. Yours, not ours.
- list
- The shortlist, with a status and a reason per member.
- deal
- One partnership, on a pipeline you defined.
- activities
Highlighted types are ones this workflow registers before it uses them.
- channels
Out of the seven a task can carry.
- pipeline
A pipeline named partnerships, created by naming it.
What this CRM does not do here
Said plainly, because each of these is a thing a CRM is usually expected to do, and an agent that assumes we do it will write code that never runs.
No creator database
Discovery, follower counts and engagement rates all arrive from your agent's tools. We store what it wrote and who wrote it, and nothing arrives here on its own.
No platform API behind ours
We do not read Instagram, TikTok, YouTube or anything else. A number on a creator record is a number an agent wrote down, with its source beside it and a date on it.
No sending, and no paying
The DM and the email are yours to send. The deal records the amount agreed; the payment happens somewhere that is not a CRM.
The other workflows
Same primitives, pointed somewhere else. The differences worth reading are in the schema each one asks for and the moment a person is called in.
POST/v1/companies
B2B outbound sales
A founder or a small sales team running outbound with agents rather than a seat per person.
Read the workflow →POST/v1/people
LinkedIn and social outreach
A founder or a go-to-market team whose first touch is a profile, not an inbox.
Read the workflow →GET/v1/schema
Agentic CRM
The category these three are instances of: what an agentic CRM is, how it differs from the one you already run, and why the provenance on every write is the part that matters.
Read the argument →GET/skill.md
The contract itself
The file an agent reads before it writes anything. Every workflow on this site is assembled out of the calls it documents, and nothing else.
Read /skill.md →Point an agent at an empty workspace
An agent can create one with no key, no invitation and no human, and run this whole workflow through it before anybody decides whether it belongs here. Your API calls are never rate limited and agents are never counted.