AI employees
An AI employee works your organization’s leads and pipeline continuously, under permission boundaries you set and with a human in the loop wherever it matters. It’s a different product from workflow automation: automation runs a deterministic if-this-then-that rule once per trigger; an AI employee reasons about a subject, decides what to do next, and checks back later on its own schedule.
What an AI employee is
Section titled “What an AI employee is”An AI employee is a member of your organization: its own account, a role, and a scope (which pipelines, departments, campaigns, or deal-value band it may touch), exactly like a person you hired. Every action it takes runs through the same permission checks, field policies, and pipeline visibility rules a human employee in that role would hit. It cannot see or do anything that role couldn’t. It sits on its own roster under Organization → AI employees rather than among your people in Members.
Hiring, org-wide and per-agent pausing, and guardrail changes are for admins, or, on Enterprise, a custom role you’ve granted the AI-employees capability. Pausing AI employees on a single lead is different. It’s available to anyone who can edit that lead, from the lead’s own detail page.
Hiring
Section titled “Hiring”Six roles, each hired separately:
| Role | What it does | Can it email or propose meetings? |
|---|---|---|
| Pipeline Ops | Flags rotting leads, overdue tasks, a growing needs-review pile, and stale forecasts, as tasks for the owner | No |
| Research | Enriches thin leads and companies, and suggests duplicate merges for approval | No |
| Onboarding | Reports setup gaps (no custom pipeline, no follow-up templates, unused seats…) to admins | No. Read-only, writes nothing to your CRM |
| Outbound follow-up | Qualifies and follows up new or stale leads in scope | Yes (drafts first) |
| Scheduler | Proposes meeting times, chases no-shows, reschedules, sends confirmation nudges | Yes (drafts first) |
| Campaign follow-through | Works a campaign’s or event’s captured cohort end to end | Yes (drafts first) |
At hire you pick the role, give it a name, and set its scope. Every new hire starts in shadow mode: it works its queue and writes a full timeline of what it would do, but executes nothing. An admin has to turn shadow mode off explicitly. There’s no timer and no auto-graduation. Separately, a fresh agent’s write permissions start at nothing: the master switch for writing to your CRM is off (that covers tasks, notes, stage moves and field edits alike, whatever tools the role grants) and so is contacting anyone. An admin turns each on explicitly, per agent.
Before it can email anyone
Section titled “Before it can email anyone”Three things have to be in place before any AI employee can send, whatever its role and whatever its guardrails say:
- A recorded lawful basis for outreach. An admin fills in Before AI employees can email people on the roster page: what you rely on, and where the contacts came from. Until then AI employees can read, plan and work in shadow, but every send is refused, and refused rather than handed to a person, since handing it over would route around the question.
- A verified sending address for your organization (Organization → Settings → Email). Without one a send becomes a handoff naming the fix; nothing falls back to a shared sender.
- Your postal address on file (Organization → Settings → General), because the unsubscribe footer carries it.
Every email an AI employee sends carries that unsubscribe footer, and carries an AI-disclosure line whenever the agent sends on its own rather than a person reviewing and releasing the draft. Both are added after your text and can’t be edited away.
Guardrails
Section titled “Guardrails”Every action an AI employee is about to take gets a risk tier (low, medium, high, or critical) computed from the action itself plus context: the deal’s value against your threshold, whether it’s a first touch or a continuation, lead score, bulk size, whether it’s customer-visible, and whether it’s reversible. The tier is a deterministic rule, never self-assessed by the model, and the matched rule is recorded on the action so you can see why something did or didn’t need you.
You configure what happens at each tier (proceed, require approval, hand off to a person, or block) on the agent’s Guardrails tab, with presets (Cautious / Balanced / Autonomous) or your own matrix. Two floors can never be loosened, by any setting:
- Critical actions never proceed on their own: they always require approval, a handoff, or a block.
- Anything a customer would see (an email, a meeting proposal) requires approval until that specific agent has been explicitly upgraded to autopilot.
Some actions aren’t a dial at all: deleting a record, managing billing, validating an event ticket, and similar are simply not tools an AI employee has access to, in any role.
Budgets
Section titled “Budgets”How much it may do, on the agent’s Guardrails tab, sets two caps per agent: a daily actions budget, and a monthly credit ceiling (leave it empty for no ceiling). Reaching the monthly ceiling stops the agent for the rest of the month and raises one handoff (not one per day) explaining that waiting for the day to roll over won’t help, since that ceiling only resets on the 1st.
Approvals and edits
Section titled “Approvals and edits”When an action needs a human, it parks with the full details and the agent’s stated reasoning. You can edit it (rewrite an email’s subject or body, for example) before approving. Approving runs the (possibly edited) action; rejecting records why, which shapes what the agent tries next on that lead. How often approvals get corrected or rejected is what an agent needs to earn autopilot for customer-facing sends.
A parked approval expires after 72 hours. That isn’t an auto-rejection. It stops being approvable and becomes a handoff, so the work reaches a person rather than quietly dying in a queue.
An Approvals tab on Organization → My Tasks lists every pending approval you’re allowed to decide, across every AI employee, so a manager or admin can clear the backlog without opening each agent individually.
Handoffs
Section titled “Handoffs”When an AI employee hits something that genuinely needs a person (the customer asked for one, an approval timed out, it’s out of scope, or it ran out of budget) it writes a handoff: what happened, what it already tried, and a suggested next step. It routes to the lead’s owner, then that department’s manager, then an org admin, and is delivered by inbox, push, and a daily email digest with a link straight to the lead.
Open handoffs also collect on a Handoffs tab on Organization → My Tasks, beside Approvals, and on each agent’s own Handoffs tab.
A handoff is a normal outcome: it’s counted and reported like any other result, not treated as an error. The point is showing you exactly which conversations needed a human.
Results and the monthly report
Section titled “Results and the monthly report”Every completed outcome (a follow-up sent, a meeting booked or held, a lead enriched, duplicates merged, a data issue fixed, a setup gap reported, pipeline value moved, a handoff delivered) lands in the agent’s results ledger, visible on its Results tab. Admins also get a monthly report email summarizing the org’s AI employees for the month; a month with no activity sends nothing.
A lead’s detail page has its own AI activity panel. Everything AI employees have done or attempted on that lead, gathered in one place instead of opening each agent’s ledger separately.
An agent’s Timeline reads run by run: each run sits under its day, is led by the record it worked on, and lists its steps in the order they happened, each with its outcome and the rule that allowed it. A run holding something for a person (an approval, a blocked or failed step) says so in its header. Notes, tasks and activity an AI employee left on a lead carry its name and face on the lead’s own page, so nothing it wrote can be mistaken for a colleague’s.
Stage moves, tasks, notes and tag changes an AI employee made can be undone from its timeline: one action, a selection of them, or a whole run at once. Reversals are reported back row by row: what was reverted, and what was skipped and why, including anything a person has edited since, which is left alone on purpose.
Admins can retry a parked item straight from an agent’s timeline (useful after a transient failure or a fixed sync problem) and can export an agent’s action ledger to CSV, up to 90 days per export.
Billing
Section titled “Billing”Seats and credit packs are bought from Organization → Billing → Add-ons. Each AI employee is $99/month (Business and Enterprise only) and includes 1,000 credits/month. Every executed tool call counts as one action and debits credits for what it does (including read-only lookups, since those cost compute too) weighted 1 credit for a read, 2 for an internal write, and 5 for a write that reaches a customer (an email, a meeting proposal).
Once the included pool runs out, extra actions draw from credit packs (250 / 1,000 / 5,000, purchased the same way as enrichment or scan credits). When the balance runs low or out, the roster’s seat meter says so and an admin (owner or admin role) gets an Add credits link, also carried by the inbox notice, that opens Billing with the smallest pack already in the cart. A run that hits zero mid-task isn’t abandoned: the balance can go slightly negative (an admin-configurable overdraft, set in Data governance below, up to a platform ceiling) so it finishes what it’s doing, and no new work starts until the balance is settled. If auto-expand is on, running low buys the next pack automatically; if it’s off, the agent parks its remaining work and a handoff notifies an admin.
Every AI employee you’ve hired holds one of the seats you’ve bought, running or paused alike. A seat prices the capacity, not the minutes. Only retiring one frees its seat.
Data governance
Section titled “Data governance”An org admin can turn agent data processing off entirely from the Data governance section on Organization → Settings → AI tagging, which is also where the overdraft allowance is set. With it off, no AI employee may be hired and none may pick up new work. Anything already in progress finishes rather than being killed mid-task. This is a data-governance position, separate from pausing below.
AI employees never read inbound email or a prospect’s replies. They see opens, clicks, document views, booking responses, and capture-form submissions, but a reply that lands in someone’s mailbox is that person’s to answer. Until Lynqu supports reading replies, an AI employee’s part in that conversation continues from what it can see, or via a handoff.
Pausing
Section titled “Pausing”- One agent: pause it from its detail page. It stops picking up new work immediately; anything already in progress finishes.
- Every agent: pause all from the roster page. It stops every AI employee in your organization at once; anything already in progress finishes.
- One lead, automatically: when an AI employee hands a lead off to a person, that agent’s own open work on the lead is parked (another agent in scope carries on). Resolving the handoff keeps the agent off that lead until something new happens to it; hand-back explicitly puts it back to work, with your note attached.
- One lead, on demand: from the lead detail page’s ownership cluster, a member who can edit the lead can toggle Pause AI employees for it. While paused, no new AI-employee work is created for the lead, AI employees cannot write to it (reads still work), an item already running finishes without writing, and retrying a parked item for that lead is refused. Unpausing resumes normally.