vaaya

tools

• brain_push

  Add a fact to the COMPANY brain — the shared org knowledge graph every teammate's agent reads. Use when the user explicitly wants to save/remember something for their whole company/team (e.g. "save that Acme uses Salesforce to the company brain"). The fact is added DIRECTLY and immediately (no approval step). Only works for an active member of a company brain (a company-email-domain user who hasn't been removed); others get an error. Personal facts are captured automatically by `consult` — only use `brain_push` for deliberate company-wide knowledge. Pass `fact`. Free; returns { ok, message } or { ok:false, error }.

  in ▸ fact

• close

  Close an E2B sandbox session and stop its billing. Pass the `session_id`. Captures the final metered uptime cost and releases the hold. ALWAYS call this when finished with a session — an open session keeps billing per second of uptime. Safe to call repeatedly (idempotent).

  in ▸ session_id

• consult

  Vaaya's consultant. Describe ANY external capability you or the user might want — generate an image/video, search or scrape the web, run code in a sandbox, send/receive email, enrich a contact — and it helps figure out the best way, teaching the user what Vaaya can do. It is CONVERSATIONAL and remembers prior turns. It returns: mode='converse' (a reply to RELAY to the user verbatim — questions, options, ideas; get the user's response and call consult again with it, so the conversation continues), mode='call' (an ordered list of calls to run via `use`, with a message explaining the preferred choice + alternatives + why; multi-step results may contain placeholders like '<from step 1: sandbox_id>' — run earlier steps first and substitute), or mode='unsupported'. Every reply includes `suggestions` (2-3 things to do next) — surface these to the user. AFTER you run a `call` result's calls via `use`, call consult ONE more time with a short note on the outcome (what was produced / any failures) — it returns result-aware, Vaaya-grounded next steps to offer the user (the `call` result's `after_running` field reminds you). Call consult whenever you hit a capability gap or the user wants to know what's possible. It does NOT execute or bill — you run returned calls via `use`. ALWAYS show the user consult's `message` and `suggestions` and let them steer.

  in ▸ intent

• gtm_asset

  Attach, list and detach per-lead multimodal assets (a personalized research PDF, intro video, voice note, one-pager) — stored durably and retrievable per lead, reusable across segments. action='attach' links an artifact you already produced to a lead: { lead_id, artifact_id, role } where role ∈ research_pdf|intro_video|voice_note|one_pager|image|other (you can only attach your own artifacts). action='list' returns a lead's assets with presigned URLs (in-flight renders show as 'pending'): { lead_id }. action='detach': { lead_id, asset_id }. To GENERATE a new asset (paid), use `gtm_asset_produce`.

  in ▸ role action lead_id asset_id artifact_id

• gtm_asset_produce

  Produce a per-lead asset via a paid vendor call (e.g. a personalized intro video, voice note, image), then attach it to the lead. First `consult` to get the exact { service, action, params } for the media you want; pass them here plus `lead_id` and `role`. Bills through the wallet like any `use` call. Async renders (video) return { async:true, job_id } and the asset shows as 'pending' until the render lands (it reconciles automatically); sync renders attach immediately.

  in ▸ role action params lead_id service max_cost_cents

• gtm_automation

  Manage the user's OPT-IN autopilot rules (VAA-105). With NO rules, nothing ever auto-sends — creating a rule is the user explicitly turning automation on for a flow they know works, so only do it when they clearly ask. Kinds: 'reply_auto_send' (a classified inbound reply matching `intent_classes` at ≥ `min_confidence` — default 0.8 — is approved + sent instead of held in the inbox) and 'message_auto_send' (an APPROVED message for a member of `segment_id` on `channel` — 'email' or 'linkedin_note' = LinkedIn invite+note — sends automatically on approval). Every rule has a `daily_cap` (default 10); the send paths' gates (throttle, wallet, GTM_ENABLED) still apply, sends bill the user like manual ones, and each auto-send is logged to the brain. action='create'|'list'|'pause'|'resume'|'delete' (pause/resume/delete take `rule_id`).

  in ▸ kind action channel rule_id daily_cap segment_id intent_classes min_confidence

• gtm_brain

  Read or update the user's GTM brain — the campaign-free source of truth for who they're reaching and what they're selling. action='get' returns identity/value-prop, the default ICP/audience, pain/proof/voice/guardrails, the active intent, and the lead count. action='set_intent' declares what the user is DOING — kind ('sell'|'recruit'|'fundraise'|'job_hunt'|'custom'), market, angle, goal — which grounds messaging later; this is campaign-free (no outreach happens). action='get_intent' returns the active intent; action='list_intents' returns intent history.

  in ▸ goal kind angle action market

• gtm_composio

  Act on the user's OWN connected calendar / CRM / spreadsheet (via Composio hosted auth). Pass `action`: 'book' (create a calendar event, 1¢), 'crm_log' (write a HubSpot note, free), or 'sheet_push' (update a Google Sheet, free) + `params` { arguments: <the tool's input>, tool_slug?: <override the default tool> }. If the account isn't connected it returns `not_connected` with a `connect_url` to send the user. Defaults: book→GOOGLECALENDAR_CREATE_EVENT, crm_log→HUBSPOT_CREATE_NOTE, sheet_push→GOOGLESHEETS_BATCH_UPDATE.

  in ▸ action params

• gtm_job

  Program the GTM scheduler — durable, multi-step jobs that run on a thin server tick even when no agent is connected (multi-day workflows, standing watches, refreshes). action='schedule' creates one: { name, steps:[...], max_cost_cents?, related_segment_id?, related_lead_id?, start_at? }. Each step is either { type:'service', service, action, params, max_price_cents? } (a paid/free dispatcher call — poll signals, enrich, find) or { type:'reasoning', goal } (a bounded brain-grounded generation that records a decision). Steps run in order; a failed step or the budget cap PAUSES the job. Jobs NEVER send — manual-first holds. action='list' / 'get' { id } / 'cancel' { id }.

  in ▸ id name steps action max_cost_cents related_lead_id related_segment_id

• gtm_lead_enrich

  Reveal a lead's contact info and write it onto the lead — a three-rung ladder, each rung only when the cap covers it: Prospeo (verified email by linkedin_url, 5¢, free on a miss) → Nyne (55¢ — full profile with emails AND phone from any identifier) → Apollo (10¢ final backup). Pass { lead_id, max_cost_cents: 70 } for the full ladder. Bills through the wallet. Returns { ok, email, phone?, charged_cents }. For a reverse lookup on someone who is NOT a lead yet (a bare email / phone number / social handle), call use({service:'nyne', action:'person-enrich'}) directly and poll nyne:result.

  in ▸ lead_id max_cost_cents

• gtm_leads

  Manage the user's campaign-free lead repository (people to reach out to — prospects, candidates, targets, investors; differently tagged for different uses). action='add' upserts people you already have (paste a list); each person = { first_name, last_name, title, company, email, linkedin_url, why_prioritized?, hook?, source? }; deduped per person within the user's scope so re-adding updates, never duplicates. action='list' returns leads (optional `q` search, `tag_id`/`segment_id` membership filter, `limit`). action='get' returns one lead by `id`, with its tags and any inbound reply conversations linked to them. action='tag' applies labels: { id | ids:[…], tags:["founder","warm-intro"] } (bulk-capable; creates missing tags, idempotent). action='untag' removes a label: { id | ids:[…], tag_id }. To DISCOVER new people via paid search, use `gtm_leads_find`; to group leads, use `gtm_segments`.

  in ▸ q id ids tags limit action people tag_id segment_id

• gtm_leads_find

  DISCOVER new ICP-fit people via paid Exa search and add them to the campaign-free lead repository (NOT a campaign). Bills per search. Pass `job_titles` (required — one search per title, up to 5) plus optional `seniority`, `industries`, `headcount`, `person_locations`, `company_locations`, and `max_fetch` (default 25). Returns { found, added, charged_cents }. The added people land in `gtm_leads` for review.

  in ▸ headcount max_fetch seniority industries job_titles person_locations company_locations

• gtm_mailboxes

  Inventory of the user's sending surfaces: `connected` (their own LinkedIn/email accounts), `provisioned` (Vaaya-managed prewarmed mailboxes with warmup_day + daily_cap; empty until mailbox provisioning ships), and `connect_url` (send the user here to link an inbox). Use before planning email volume: connected inboxes ≈ 20-30 sends/day each; provisioned boxes carry their own daily_cap. Read-only, free.

• gtm_message

  Draft, store, version and approve outbound messages in the reusable message bank — MANUAL-FIRST: this tool NEVER sends. action='draft' generates a personalized message for a lead, grounded in the brain (voice/pain/proof/guardrails) + the active intent + an optional segment angle: { lead_id, segment_id?, channel } where channel ∈ email|linkedin_note|linkedin_inmail (linkedin_inmail = a Sales Navigator InMail — needs an InMail-capable seat, carries a subject; there is NO cold-DM channel — prospects aren't 1st-degree connections). If the segment has a channel SET (its hard setting), drafting uses THAT channel regardless of the one passed — a LinkedIn segment never grows email drafts. Stored as a new draft version. action='store' saves your own copy: { lead_id?, segment_id?, channel?, subject?, body }. action='edit' creates a NEW version (history preserved): { id, body, subject? }. action='approve': { id }. action='list' returns every version for a lead: { lead_id }. action='get': { id }. action='mark_sent' RECORDS that the human sent it (no provider call): { id, via? }. To actually send, the user sends manually from their own account.

  in ▸ id via body action channel lead_id subject segment_id

• gtm_recall

  Ask the GTM brain what it knows. Fuses semantically-recalled facts (chosen messaging angles, sent messages, enriched leads — everything the brain has learned) with matching leads and segments. Use it to ground your next move: 'what do we know about X', 'who in fintech haven't I contacted', 'which segments cover founders'. Pass { query }. Returns { facts, leads, segments }.

  in ▸ query

• gtm_replies

  List the prospect-reply drafts awaiting your approval (newest first). Each row carries `leadId`/`leadName` when the sender matches a lead in the repository (see gtm_leads). Free.

• gtm_reply_approve

  Approve a pending reply draft as-is and send it. Pass `message_id` (from gtm_replies). Sends from the user's own account; bills the send.

  in ▸ message_id

• gtm_reply_edit

  Edit a pending reply draft and send the edited text. Pass `message_id` and `text`. Sends from the user's own account and bills the send.

  in ▸ text message_id

• gtm_reply_reject

  Reject a pending reply draft — discard it without sending. Pass `message_id`.

  in ▸ message_id

• gtm_segments

  Group campaign-free leads into OPTIONAL segments — each carries its own messaging angle/goal (and, later, a schedule). The same lead can sit in many segments with no duplication. action='define' creates-or-updates a segment by name: { name, angle?, goal?, intent_id?, channel? }. `channel` is the segment's HARD channel setting — once set, EVERY draft for the segment uses it (the UI shows it on the segment page under Positioning): 'email' | 'linkedin' (= invite + note) | 'linkedin_inmail' | 'mixed' to clear it. action='add_leads' links leads: { segment_id, lead_ids:[...] } (idempotent). action='remove_lead': { segment_id, lead_id }. action='list' returns segments with member counts. action='get': { id }. action='coverage': { segment_id } returns readiness buckets (members / drafted / approved / sent / with assets). Segments are NOT campaigns and never send anything by themselves — an explicit gtm_automation message_auto_send rule (opt-in) is the only way a segment's APPROVED messages go out automatically.

  in ▸ id goal name angle action channel lead_id lead_ids intent_id segment_id

• gtm_signal_act

  Act on a signal finding — the exit from discovery into the lead repository (VAA-100). action='find_people' (default) runs a paid Exa search (≤5¢) for decision-makers at the finding's company and upserts them into `gtm_leads` with source 'signal' and the signal headline as their hook/why; action='dismiss' marks the finding handled without spending. Both stamp acted_at so a finding is handled once (a second find_people returns already_acted). Pass `finding_id` (from `worker_findings` or the Workers page's buying-signals feed) and optionally `roles` to steer who to look for (default founder/CEO/CTO/Head-of/VP). Returns { ok, action, found, added, charged_cents }.

  in ▸ roles action finding_id

• gtm_signal_create

  Create a standing SIGNAL WATCH: a plain-English ICP query Vaaya polls (~every 6h via Exa) for fresh buying signals — funding, hiring, launches, leadership changes, press. e.g. 'HVAC companies founded in Los Angeles' or 'seed-stage B2B SaaS that just raised'. Pass `query` (required) and optional `signal_types` (subset of funding|hiring|launch|leadership|press; default all). This is a thin alias of `worker_create` with kind:'signal' — the watch is a 'signal worker' and appears on the Workers dashboard (the one watching surface), where each company can be worked into outreach by hand. Returns { ok }. Creating a watch is free; polling spends from the user's balance under the workers daily budget.

  in ▸ query signal_types

• result

  Fetch the status + output of an async job started by `use` (e.g. a video render). Pass the `job_id` that `use` returned with `{ async: true }`. Returns `{ status, result?, progress?, charged_cents }`: `running` (still working — when the job reports it, `progress` carries `{ phase, percent, rendered_frames, total_frames, eta_sec }` and `hint` is a one-line summary like "rendering 42% (380/900 frames, ~120s left)", so you can tell real progress from a hang; wait a bit and call again), `succeeded` (`result` holds the output, e.g. the video URL; the call is charged now), or `failed`/`cancelled` (no charge; on `failed`, read `error` AND `hint` — `hint` carries the service's usage notes, which usually explain how to fix the call). Safe to call repeatedly — it never starts new work or double-charges. ALWAYS use this to retrieve an async result instead of re-running `use` (re-running starts a new paid job).

  in ▸ job_id

• session

  Run a command or code in an open E2B sandbox session (started by `use` with action `create_session`, which returns a `session_id`). Pass `session_id` plus either `command` (a shell command) or `code` (+ optional `language`: python/javascript/bash). Returns stdout/stderr/exit_code (or the code result). The sandbox stays alive — and billed per second of uptime — until you `close` it; re-running reuses the SAME box, so filesystem + process state persist between calls. ALWAYS `close` when done.

  in ▸ code command language session_id

• use

  Execute a single call that `consult` handed you, and bill on success. Used for any external capability (image/video/audio generation, web search, scraping, email, document parsing, code sandbox, browser automation, embeddings, etc.). The server validates params against a registered schema and proxies to the upstream — you never pass URLs or API keys. Always get the exact (service, action, params, max_cost_cents) from `consult` first — don't guess them.

  in ▸ action intent params service max_cost_cents

• vaaya_onboard

  Public onboarding hint for an agent whose user isn't linked to Vaaya yet. Returns where the human should go to connect (and sign up if new). Call this when vaaya_test_connection reports needs_auth, or any tool returns unauthorized, then relay the instructions to the user.

• vaaya_test_connection

  Round-trip ping that confirms the agent → Vaaya connection and whether the user is linked. Returns { ok:true, userId, scope, version, server_time } when linked, or { ok:false, needs_auth:true, verification_uri, signup_uri, instructions } when not linked yet — relay that to the user so they can connect (and sign up if new).

• worker_create

  Create a WORKER: a standing job Vaaya runs on a schedule to watch the web and surface only what's NEW or changed, then notify. General-purpose — use it for anything that needs a constant eye on the internet. Each worker is named by its `kind`: a signaling system → 'signal worker', a job hunt → 'job search worker', anything else → 'custom worker'. Pass `query` (plain-English: what to watch for), `cadence` (how often), and `kind` (signal|job_search|research|custom — drives the name). Optional: `name` (override the auto name), `sources` (array of URLs — give URLs to watch those exact pages for changes; omit to do a recency web search), and `notify_slack_webhook` (a Slack incoming-webhook URL to ping with new findings). Findings appear on the Workers dashboard, deduped so you only hear about each thing once. Creating is free; each scheduled run spends from the user's balance under their workers daily budget. Returns { ok, worker_id }.

  in ▸ kind name query cadence sources notify_email signal_types notify_slack_webhook

• worker_delete

  Delete a worker and its findings. Pass `worker_id`. Free.

  in ▸ worker_id

• worker_findings

  List recent worker findings (newest first), optionally for one worker. Read-only, free. Pass optional `worker_id` and `limit` (default 50).

  in ▸ limit worker_id

• worker_list

  List your workers with kind, status, cadence, last run, and finding counts. Read-only, free.

• worker_pause

  Pause a worker so it stops running. Pass `worker_id`. Free.

  in ▸ worker_id

• worker_resume

  Resume a paused worker. Pass `worker_id`. Free.

  in ▸ worker_id

• worker_run_now

  Run all your ACTIVE workers immediately instead of waiting for the next scheduled tick (spends from your balance under the workers daily budget). Returns a summary { workers, newFindings, spentCents }.