Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.octavehq.com/llms.txt

Use this file to discover all available pages before exploring further.

What is an Agent?

An Agent in Octave is a pre-built AI workflow that produces a specific GTM outcome — enriching a company, qualifying a person, generating a sequence, prepping for a call — grounded in your Library and your analytics findings. Agents are the fastest way to deploy AI into your GTM stack: each one encodes Octave’s best-practice prompting, context retrieval, and GTM logic for its task, so you don’t have to build that scaffolding yourself. Over time, teams typically graduate to building their own custom workflows on top of the raw primitives Octave exposes — the Library, Context Search, Findings, and Resources. Out-of-the-box Agents are the on-ramp.

Agent types

Octave ships with the following agent types. Each has its own input schema and is callable directly or through a saved Agent configuration:
AgentWhat it does
Enrich PersonBuilds a structured intelligence report on a single person
Enrich CompanySame, for a single company
Qualify PersonScores a person against your ICP / persona criteria
Qualify CompanyScores a company against your ICP / segment criteria
ProspectorFinds and qualifies prospects matching ICP criteria
SequenceGenerates a multi-touch outbound sequence (1–4 emails)
ContentGenerates LinkedIn, social, or short-form copy
Call PrepBuilds call-prep notes with talking points and objection handling
ContextSurfaces relevant Library context for an arbitrary query
Workspace BuilderBootstraps a workspace from a URL or short description
See the Agents API reference for the full request/response schema of each.

Ad-hoc vs Saved Agents

Every agent type can be called two ways:
  1. Ad-hoc — POST directly to the agent’s run endpoint with all inputs in the body. Good for one-off scripts and testing.
  2. Saved Agent — create an Agent in the dashboard or via POST /api/v2/agents/create, configure it (custom prompts, brand voice, default context), then run it later by passing its agentOId. Saved Agents are the right shape for production use because the configuration is versioned and shared across your team.
Saved Agents also support experiments via POST /api/v2/agents/experiment/create — branch a configuration, test it against the original, and pin the winner.

How agents use context

Every agent run pulls context from your Library at execution time. For most agents, the relevant Motion is selected based on the offering and the prospect’s persona/segment match, and the matched Motion ICP supplies the narrative, learnings, and recommended evidence (proof points, references, objections, alternatives) that ground the output. You can override the auto-selected context with customContext in the request body — pinning a specific playbook, product, persona, or segment when you want fully deterministic output.

Sync vs Async

Most agent endpoints expose both a synchronous variant (returns the result in the HTTP response) and an async variant via Async / callbacks. Choose async for batch operations, expensive agents (Enrich, Prospector), or any workflow that exceeds the sync timeout.

Workflows

For multi-step pipelines (enrich → qualify → generate → notify), use Workflows — graphs of agents wired together that you trigger as a single async job.

Managing Agents via API

  • GET /api/v2/agents/list — list saved agents
  • GET /api/v2/agents/get — get a specific saved agent
  • POST /api/v2/agents/create — create a saved agent
  • POST /api/v2/agents/update — update a saved agent
  • DELETE /api/v2/agents/delete — delete a saved agent
  • GET /api/v2/agents/types — list available agent types
  • GET /api/v2/agents/languages — list supported output languages
  • POST /api/v2/agents/experiment/create — branch a saved agent into an experiment
  • POST /api/v2/agents/{type}/run — run an agent of a given type (sync)
  • POST /api/v2/async/agent/run — run any saved agent asynchronously with a callback URL