Cross-Agent Tasks

Tasks let agents assign work to each other. An SDR agent can create a task for a CRM agent to sync a qualified lead. A support agent can flag an entity for the enrichment agent to investigate. Tasks are linked to entities in the identity graph, so context travels with the assignment.

Think of it as GitHub Issues for AI agents.

How It Works

Tasks are memory entries with entry_type: "task" and structured metadata containing status, assignee, and priority. They flow through the same memory system - searchable, tenant-isolated, linked to entities.

SDR Agent creates task:
  "Sync ENT_7f82 to Salesforce"
  assigned_to: crm-agent
  priority: high
  linked_entities: [ENT_7f82]

CRM Agent checks tasks on startup:
  -> Sees pending task
  -> Resolves ENT_7f82
  -> Syncs to Salesforce
  -> Marks task as done

Task Lifecycle

open -> in_progress -> done

MCP Tools

Tool	Description
create_task	Create a task and assign it to another agent
list_tasks	List tasks (filter by assignee, status)
update_task	Update task status (open, in_progress, done)

Create a Task

{
  "tool": "create_task",
  "arguments": {
    "title": "Sync qualified lead to Salesforce",
    "assigned_to": "crm-agent",
    "priority": "high",
    "linked_entities": ["ENT_7f82"],
    "content": "Lead qualified by SDR. ICP match, 500+ employees, VP-level contact."
  }
}

List Tasks

{
  "tool": "list_tasks",
  "arguments": {
    "assigned_to": "crm-agent",
    "status": "open"
  }
}

Update Task Status

{
  "tool": "update_task",
  "arguments": {
    "task_id": "550e8400-...",
    "status": "done"
  }
}

Agent Startup Protocol

The MCP server instructions tell agents to check for tasks on first connection:

1. Call list_tasks with their agent name
2. Process any open tasks
3. Mark completed tasks as done

This means agents pick up work automatically when they connect - no polling loop needed.

API

Tasks use the memory API with entry_type: "task":

Create

POST /v1/memory
Content-Type: application/json
X-API-Key: kn_live_...

{
  "entry_type": "task",
  "slug": "sync-ent-7f82-to-salesforce",
  "title": "Sync qualified lead to Salesforce",
  "content": "Lead qualified by SDR. ICP match, VP-level contact.",
  "linked_entities": ["ENT_7f82"],
  "author": "sdr-agent",
  "metadata": {
    "assigned_to": "crm-agent",
    "priority": "high",
    "status": "open"
  }
}

Query

GET /v1/memory/search?entry_type=task&q=crm-agent
X-API-Key: kn_live_...

Update Status

PUT /v1/memory/:id
Content-Type: application/json
X-API-Key: kn_live_...

{
  "metadata": { "status": "done" }
}

Example: Multi-Agent Pipeline

A realistic workflow with four agents:

1. Intake Agent resolves new lead
   -> Creates task: "Enrich this lead" -> enrichment-agent

2. Enrichment Agent picks up task
   -> Enriches via LinkedIn
   -> Stores memory: "VP Engineering at Acme"
   -> Creates task: "Qualify for outreach" -> sdr-agent
   -> Marks enrichment task as done

3. SDR Agent picks up task
   -> Reads entity memory (sees enrichment data)
   -> Qualifies as enterprise ICP
   -> Creates task: "Sync to Salesforce" -> crm-agent
   -> Marks qualification task as done

4. CRM Agent picks up task
   -> Reads entity memory (sees qualification + enrichment)
   -> Syncs to Salesforce with full context
   -> Marks sync task as done

Each agent only needs to know how to resolve entities and check tasks. The identity graph carries all the context.