Documentation
How the workers, integrations and scheduled pipelines actually work. This page describes what is built and running — where something is narrower than it looks in the interface, that is written down here rather than left to be discovered.
Getting started
Your workspace has six AI workers. Three of them run on their own schedule and need to be connected to your Gmail to do anything useful. The other three work on request, inside the chat. The worker reference below sets out which is which and why it matters.
Connecting Gmail
Open Integrations in the workspace sidebar and choose Connect Gmail. You will be sent to Google’s consent screen, where the platform requests three scopes:
gmail.send— so workers can send from your address rather than a shared one.gmail.readonly— so the sequence engine can search your inbox for a reply before it sends the next follow-up, and detect bounces.userinfo.email— to record which address the connection belongs to.
The connection is requested with offline access, so scheduled work continues when you are not signed in. Tokens are stored against your user and refreshed automatically when a send needs them.
Reconnect and connection status
Reconnectruns the same consent flow as the first connection. It is not a separate repair action — there isn’t one. Use it after changing your Google password, after revoking access from your Google account, or when sends begin failing.
The connected indicator checks whether a stored token exists for your account. It does not test that the token still works. A connection can therefore read as connected while the underlying grant is dead.
Refresh failures are recorded against the account when they happen, but nothing currently acts on that record automatically. If scheduled sends stop arriving, reconnect first — that resolves it in almost every case.
How each worker operates
The six workers are not equivalent, and the difference matters for what you can rely on. Alex, Jordan and Taylor run on a schedule, hold state in the database, and keep working when nobody is watching. Morgan has one document tool on top of chat. Sam and Casey have chat and nothing else.
All six are also available as chat specialists in the workspace — that is the floor every worker shares, and for Sam and Casey it is the whole of what they are. What separates the others is what they have in addition: a schedule, a queue, or a tool.
ALAlex — Sales Development
Alex is the most complete of the workers and the only one that runs an end-to-end outbound sequence. Give him a name and a company and he researches the prospect on the web before writing anything, then resolves a contact address, drafts, and sends from your Gmail.
Drafting runs hourly in batches. Sending is capped per workspace — the default is 50 emails a day, counted across every step of every sequence, so one busy workspace cannot spend another’s allowance. Follow-ups are timed from the first email:
- Day 3Second email, if no reply. Where an alternative angle exists, it is picked 50/50 against the primary.
- Day 7Voice call step, only where a phone number is on the record and there has been no reply.
- Day 10Third email.
- Day 21Fourth email.
- Day 35Fifth and final email.
Your inbox is checked for replies every five minutes, and again immediately before any follow-up goes out, so a prospect who has just answered is never sent the next step. Replies are classified and handled differently:
| Classification | What happens |
|---|---|
| Interested | Your booking link is sent, and a reply is drafted for your approval. |
| Objection | A reply is drafted against the matching objection script, for your approval. |
| Wrong person | A referral request is drafted, asking to be pointed to the right contact. |
| Not now | Parked for 90 days, then re-engaged automatically. |
| Out of office | The return date is read from the reply and the sequence resumes then. Falls back to seven days. |
| Unsubscribe | The sequence stops permanently and the prospect is marked unsubscribed. |
Every reply classification that produces a response produces a draft awaiting your approval, not an outbound email. Alex sends the opening sequence on his own; he does not answer a human on his own.
JOJordan — Data Analyst
Jordan reports on outbound performance. He sends a brief every Monday morning, runs an anomaly check every morning, and answers questions on demand. Reports arrive by email and WhatsApp.
The daily check looks for five specific conditions:
- Rejection spike — more than 40% of drafts reviewed today were rejected, once at least three have been decided.
- Inactivity — no new prospects added in 48 hours.
- Pipeline drought — fewer than five prospects active.
- Outbound stalled — no emails sent in 72 hours.
- Reply handling failed — a reply was picked up but processing stopped part-way. Flagged high because a send may already have happened.
Reply-time statistics are withheld until at least five replies exist, so a single fast answer cannot present itself as a trend.
Jordan analyses the outbound prospect data Alex produces. He is not connected to your finance system, your CRM or general business metrics, and does not read any data source outside the platform.
TATaylor — Content & Marketing
Taylor writes LinkedIn posts. Once a week he drafts new content, drawing topics from the buying signals Alex has picked up, and puts the result in a queue. Posts wait there for your approval — nothing publishes automatically. Approving a post publishes it to LinkedIn.
Prospects you are actively tracking must not appear by name in a public post. Taylor checks generated copy against the watchlist and regenerates up to twice if a tracked name appears; if it still appears, the post is refused rather than queued. The same check runs again when you edit a post by hand, because an edit can reintroduce a name the original draft correctly avoided.
Taylor’s scope is LinkedIn posts. Ad copy, email campaigns and SEO content are not built.
MOMorgan — Document analysis
Morgan answers questions about a financial document you upload. Attach one PDF, CSV or TXT file up to 4 MB, ask a question, and he answers from the contents of that document — citing the figures and line items he used, and saying plainly when the document does not contain enough to answer.
This is a single-shot tool. Nothing is stored, nothing is scheduled, and each question is independent of the last — Morgan does not remember the previous document or build a picture over time.
Morgan is also one of the six chat specialists in the workspace, where he works on figures you paste into the conversation and answers in tables. That is a separate surface from the document tool: the chat cannot read an uploaded file, and the document tool cannot search the web. Neither is connected to an accounting system, a bank feed, or any company data.
SACASam and Casey — chat specialists
Sam (customer success) and Casey (operations) work only inside the workspace chat — they are the two workers with nothing beyond it. It is worth being precise about what chat gives you, because the interface presents all six workers identically, and because this section describes the shared floor the other four stand on too.
A conversation with any of the six is a conversation with a role-specific specialist that can:
- Search the web, up to three searches per message.
- See the company context and notes you have written into the workspace yourself.
- See facts carried over from your own earlier conversations with the team.
That is the whole of it. In chat, no worker can:
- Read your prospect records, your inbox, or your CRM.
- Read anything the scheduled workers write — Sam cannot see Alex’s pipeline.
- Run on a schedule, hold a queue, or continue working after you close the tab.
This is the point most easily misread: talking to Alex in the chat is not the same as Alex the scheduled worker, and neither is talking to Jordan or Taylor. The chat persona and the scheduled worker share a name and a speciality, nothing else. What each worker has beyond chat is what the sections above describe.
Sam has one capability Casey does not. Because he writes outreach, his drafts carry your booking link, and his outputs get a Review & Send action that opens your connected Gmail with the draft loaded. You type the recipient and you press send. Casey has chat and web search only.
Sam is a customer success specialist you talk to. He is not part of the autonomous outbound sequence — the emails that go out on a schedule are researched, written and sent by Alex.
How pipelines work
Three different things get called a pipeline, and they behave nothing alike. One runs on a clock without you. One runs when you click and produces email drafts. The third passes a worker’s output to a colleague inside the chat and sends nothing at all.
Scheduled work
Scheduled jobs are the autonomous half of the platform. They run on a fixed schedule whether or not anyone is signed in:
| Worker | Job | When |
|---|---|---|
| Alex | Follow-up sequence | Hourly, on the hour |
| Alex | Drafting batch | Hourly, at half past |
| Alex | Reply check | Every 5 minutes |
| Alex | Buying-signal monitor | Daily, 06:00 |
| Taylor | Weekly content | Mondays, 07:00 |
| Jordan | Weekly brief | Mondays, 08:00 |
| Jordan | Anomaly check | Daily, 09:00 |
How workers build on each other
Scheduled workers do not message each other. They build on each other by reading the same records: Jordan’s reports are computed from the prospect rows Alex creates and updates, and Taylor draws his weekly topics from the buying signals Alex’s monitor records. Alex is the source of both.
The practical consequence is that Alex working is a precondition for the other two producing anything useful. An empty pipeline gives Jordan nothing to report on — which is exactly why his daily check treats a drought as an anomaly.
Click-run pipelines
The workspace offers three multi-step workflows you start yourself: outbound sales, inbound lead response, and a weekly business report. Each one researches, writes, and then queues every email it produces as a draft. Nothing is sent by running the pipeline.
Drafts appear under Awaiting your approval, one per recipient, so a report going to four people can reach two of them and not the other two. You can edit the subject and body before approving; approving sends from your connected Gmail, and discarding closes the draft. A draft that has already been approved or discarded cannot be actioned twice.
None of the three is scheduled. They run once, when you start them. Only the jobs in the table above run on their own — if you want the weekly report to arrive weekly, that is not what this is.
Handoffs in the workspace
A handoff is the interactive counterpart. On any worker’s output, choose Hand offand pick a colleague: their output is carried into the next worker’s conversation as context, along with a briefing describing what is being passed and why. Alex can hand a qualified lead to Sam for onboarding, Jordan can hand an analysis to Morgan, and so on.
A handoff happens there and then, in the chat. It does not create a queue entry or scheduled work, and nothing continues once you close the tab. If you want work that carries on without you, that is the scheduled half above.
Contact resolution
Before Alex can write to a prospect he needs a deliverable address. If you supplied one, it is used as-is. Otherwise two providers are tried in order:
- Hunter is tried first, and its result is accepted only above a confidence threshold.
- Apollo is tried only if Hunter returns nothing, so a successful Hunter lookup never spends an Apollo credit.
If neither resolves an address the prospect is marked needs contact and the sequence stops there rather than proceeding without a recipient. Add an address by hand and it resumes.
Where Apollo returns a phone number, it arrives asynchronously — minutes after the match, not in the initial response. A record can gain a number some time after it was first resolved.
The workspace identifier is mid-migration from an email-based key to a stable identifier, so a small amount of the surrounding behaviour is in flux.
Note also that the natural-language prospect search uses a third provider for enrichment. That provider is not part of the sequence path described above, which is Hunter then Apollo only.