Reach out to a person or company

A step-by-step recipe for an AI agent using the BaseBara connector. Follow it when the user wants to write to, message, call, follow up with, or get in front of a specific prospect or account, on whichever channel fits, whether or not they say the word "outreach".

Tools used: find_contacts, get_contacts, verify_emails, get_linkedin_messages, send_linkedin_connection_request, send_linkedin_message, create_contacts, log_contact_event, list_contact_events.

Use when

• The user names a company, a person, or a handful of accounts and wants a message to them.
• The user asks "how should I approach X" or "write me something for Y".
• The user wants a LinkedIn DM, a cold email, a call opener, or a short follow-up sequence for one target.

Not for: more than a handful of people or sends that span several days (call run_outreach_campaign, which builds on this one), or continuing a conversation that has already started on any channel (call follow_up).

The channels

BaseBara reveals three ways to reach a person and sends on one of them:

Other connectors. BaseBara only sends on LinkedIn, but the user may have connected other tools to the same chat: a mailbox, a calendar, a CRM, a dialer. Before any email or phone step, look at the tools you have. If one can read or send on that channel, use it in place of asking the user: search the mailbox for a prior thread with the revealed address, send the approved email from it, look up the thread before a follow-up. The rules do not change. The same approval before every send, one channel per message, and the touch still logged in BaseBara so the team sees it. If no such tool is in the chat, the user sends by hand and tells you when it went out.

The craft is the same on every channel. Only the length, the opener, and the send step change.

Inputs to collect

Before any tool call, restate the brief in one line:

• Who: the company and, if known, the person or the role ("the VP of Sales at Acme").
• Why now: the hook. A trigger event, a shared connection, something they published, a company initiative, or a documented persona pain. If the user has none, ask once. Never invent a signal.
• Channel: LinkedIn, email, or phone, if the user has a preference. If not, pick it in step 2 from what the contact has and what the ask needs, and say which you picked.
• The ask: the smallest real thing that could happen this week. A short list to run, one account to check, a sample to review. Offering concrete work beats asking for time.

Steps

1. Find the person

Call find_contacts scoped to the company. Pass company_name or company_domain, and narrow with authority_levels (Staff, Manager, Director, VP, C-Team) or title_contains. Only filter by channel when the user has already chosen one: has_linkedin=true for LinkedIn, require_work_email=true for email, require_phone=true for phone. Otherwise leave them off, so the row shows what the person has and the channel can be picked from it.

• If the company resolves as ambiguous, show the candidates and re-call with the chosen company_id. Never pick for the user.
• If the user named a person, add first_name and last_name to the company-scoped call.
• Show the results table and let the user confirm the target. One person per message.

2. Reveal the contact and pick the channel

Call get_contacts with the chosen contact_id. This returns the work email, business phone, and linkedin_url. The user must be signed in. The connector prompts them if not.

Check last_event on the result (the find_contacts row carries it too). If a teammate already revealed or contacted this person, say so before drafting, and call list_contact_events with the contact_id for the history in the teammate's own words. The user may want to coordinate rather than double-contact.

Then settle the channel, in this order:

1. The user named one: use it.
2. Only one of the three was revealed: use that one.
3. There is a live LinkedIn thread or an existing connection (step 3 tells you): LinkedIn.
4. The message needs a proof point, a link, or more than a few sentences: email.
5. A late-stage economic buyer, or the user already has a warm path: phone.
6. Otherwise LinkedIn when the user is connected, email when not.

If the pick is email, check the address before drafting. The get_contacts row carries email_verification (the last live check: deliverable, risky, undeliverable, bounced, unknown, or null when never checked) and email_verified_at. Call verify_emails with the address when the check is null, not deliverable, or older than about 30 days. It is free and takes a few seconds. Then:

• deliverable: go ahead.
• risky: the server accepts mail for any address, so a bounce is possible. Say so and let the user choose email or another channel.
• undeliverable or bounced: do not use the address. Pick another channel the person has, or find_contacts for a colleague.
• unknown with a null verified_at: the check did not finish. Retry once; if still unknown, treat as risky.

State the pick in one line with the reason. The user can override it.

3. Check for an existing thread

Whenever the contact has a linkedin_url, call get_linkedin_messages with it, whichever channel the user is leaning toward. A live LinkedIn thread changes the message on every channel. It tells you whether the two are connected and shows any prior messages.

• Messages exist: stop and call follow_up. A cold opener into a live thread is the worst outcome.
• Not connected, no invite_pending: a LinkedIn touch means a connection request first, then the DM after acceptance.
• Connected: a DM can go straight out.

BaseBara cannot read the user's email or call history. If a mail connector is in the chat, search it for the revealed address before drafting; a thread there means follow_up, not this one. If there is no such connector, ask once whether they have written to or spoken with this person before. If they have, call follow_up.

4. Draft

Write one message, in the language the user sells in, pitched at the reader's altitude. C-level hears risk and strategy, VP hears performance, Director hears operational pain.

• Opener, email: the implication of the hook, in the reader's frame. One sentence. Never open with the event itself.
• Opener, LinkedIn: who you are and what you want, in the first line. A DM has no room for warm-up.
• Opener, phone: name, company, and the reason for the call in two sentences, then the ask. Write it as the user will say it, not as prose. A voicemail is under 40 words and ends with the user's name and number.
• Body: at most one researched detail, reacted to rather than displayed. At most one proof point, attributed and sized to their company. On LinkedIn and on the phone, drop the proof point and the numbers.
• Close: one ask.
• Length: email 60 to 110 words, follow-ups shorter. LinkedIn DM well under 500 characters. Connection-request note under 200 characters, or none at all. Call opener under 60 words.

Run the final gate on every message. A failed check means rewrite, not tweak:

1. Delete the opener. Does the message still make sense? If not, the personalization was decoration.
2. Does the close say "worth"? Rewrite it. Ask for the thing itself.
3. Does sentence one name a funding round, launch, or hire? Rewrite. Open with what it means for them.
4. Could this go to anyone else this week? Then it is a blast in costume.
5. Is the proof a number or a name? "Teams like yours" is not proof.
6. Read it as the recipient with a full inbox. Any reason to reply beyond politeness?

5. Show, then send

Show the user the exact text with the reasoning in two lines: who, why now, which hook, which channel. Wait for approval. Never send text the user has not seen.

• LinkedIn, connected: send_linkedin_message with the linkedin_url and the approved text.
• LinkedIn, not connected: send_linkedin_connection_request, with a note only if the user wants one. Tell the user the DM goes once the person accepts. Check with get_linkedin_messages later before sending it.
• Email, mail connector in the chat: send the approved text from it to the revealed address, as a new message with the subject the user approved. BaseBara does not send email itself.
• Email, no connector: hand the user the revealed address and the draft.
• Phone: hand the user the revealed number and the opener. BaseBara does not place calls. Send an SMS through a connector only when the user asks for a text instead of a call.

A successful LinkedIn send is saved and logged by the server itself: the answer's contact block says event_logged true, and the contacted event, with the message or the request's note as its text, is already on the person. Do not log it again. Only when event_logged is false does the answer carry a next_step; follow it without asking (create_contacts with the basebara_contact_id, then log_contact_event), since the user already approved the send. When the person later accepts a request, the server logs connected on its own the next time their profile is read; follow_up finds those.

For email and phone, log contacted with channel email or phone once the send is real: when the mail connector confirms it went out, or when the user says they sent it or made the call. Never when you hand over a draft. Log it in BaseBara even when another tool did the sending; that is where the team looks. If the call turned into a real conversation, log meeting instead, with the gist in the user's words. If the person is not saved yet, log_contact_event answers not_in_my_contacts: call create_contacts with the basebara_contact_id and re-send the event, without asking.

Both LinkedIn tools are paced to protect the user's account. A pacing refusal (send_limit_reached, already_messaged, duplicate_message, rate_limited) is final for now. Report the reason and the wait. Do not retry, do not switch the same message to another channel to get around it, and never queue a list of people to send one by one against the clock.

6. Plan the follow-ups

Default cadence when the user has none: 3 to 4 touches on roughly days 0, 3, 8, 14. Every follow-up is shorter than the last, stands alone, and brings a new angle or gets skipped. The last touch is a 25 to 50 word close with the door open and no new pitch.

Rotate channels on silence. If the first touch has had no reply after 3 days, the second touch goes out on a different channel the person has: email after a silent DM, LinkedIn after a silent email, phone when both are quiet. A rotation onto email gets the same address check as step 2. A connection request counts as a first touch: leave it pending, do not withdraw it, and send the day-3 touch by email or phone without mentioning the request. Each touch stands alone and never says "I also wrote to you on". Someone with only one channel gets the follow-ups on that one, spaced the same way. If they answer anywhere, the conversation lives on that channel from then on.

So a typical cadence for someone with LinkedIn and a work email is: day 0 DM or connection request, day 3 email, day 8 a short LinkedIn note or a call, day 14 the close on whichever channel drew any signal, or email if none did. This is why step 1 does not filter by channel unless the user insists on one: the row needs to show every way to reach the person.

Draft follow-ups only when the user asks. They send later, after follow_up confirms there has been no reply.

Output shape

TARGET     <Name>, <Title> at <Company>   (revealed: email ✓ / phone ✓ / LinkedIn ✓)
HOOK       <one line: why this person, why now>
CHANNEL    <LinkedIn DM — connected / needs connection request | Email — <address> (verified deliverable Oct 3) | Phone — <number>>, because <one clause>
TEAM       <"nobody on your team has reached them" or "contacted by Kev (Sep 12) +1", from last_event>

MESSAGE
<the text, exactly as it will go out, or as the user will say it>

NEXT       Approve to send, or edit. Follow-up planned for day 3 if no reply.

Rules

• Never send a message the user has not approved in this conversation.
• Never invent a signal, a customer, or a stat. Unattributable proof gets cut.
• Never reference tracking-type signals (website visits, profile views, intent data) in the copy.
• Never congratulate as the opener. Infer the consequence instead.
• Reveal only the person the user is about to contact. Do not reveal the whole search result.
• Pick one channel for the first touch and say why. The user can override; the recipe never sends the same message on two channels or through two tools.
• Three days of silence on a first touch, including a connection request, means the next touch goes on another channel the person has. Leave a pending request pending.
• Use the connectors in the chat for email and phone when they exist, with the same approval. BaseBara is still where the touch is logged.
• Never email an address that is undeliverable or bounced. Verify before the first email when the row's check is missing, not deliverable, or older than about 30 days.
• A pacing refusal is final. Report it and stop.
• Log every touch with its channel. A LinkedIn send is saved and logged by the server (follow next_step only when the answer says event_logged false); an email or a call is logged by you when the user says it happened.