Coordination

Three primitives enable multi-agent coordination through the memory layer: declare_intent prevents collisions, query_expertise enables routing, and sync_knowledge shares project context.

These primitives work without agents knowing about each other. There is no message bus, no pub/sub, no service registry. Coordination happens through the identity graph - agents read and write to the same entities, and the memory layer handles the rest.

Intent: "I am about to do this"

Before an agent takes a significant action on an entity, it declares its intent. Other agents resolving the same entity see the intent and can avoid conflicts.

MCP

{
  "tool": "declare_intent",
  "arguments": {
    "title": "Syncing to Salesforce",
    "content": "Pushing updated contact fields to CRM",
    "entity_ids": ["ENT_7f82"],
    "ttl_minutes": 10
  }
}

Parameter	Type	Required	Description
title	string	Yes	What you are about to do
content	string	No	Additional details
entity_ids	string[]	No	Entity UUIDs this intent applies to
ttl_minutes	integer	No	Time-to-live in minutes (default 30, max 1440)

Intents are short-lived. They auto-expire after the TTL. They are stored as memory entries with entry_type: "intent" and automatically cleaned up.

Why intents matter

Without intents:

Agent A: Resolves ENT_7f82, starts syncing to Salesforce
Agent B: Resolves ENT_7f82, also starts syncing to Salesforce
Result: Duplicate sync, potential data corruption

With intents:

Agent A: Declares intent "Syncing to Salesforce" on ENT_7f82
Agent B: Resolves ENT_7f82, sees Agent A's active intent
Agent B: Skips sync, moves to next entity
Result: No conflict

Checking intents

When you call resolve_with_memory, active intents are included in the memory response:

{
  "tool": "resolve_with_memory",
  "arguments": {
    "source_name": "crm",
    "external_id": "contact_123",
    "data": { "email": "[email protected]" }
  }
}

Response:

{
  "entity_id": "ENT_7f82",
  "memory": [
    {
      "entry_type": "decision",
      "title": "Qualified as enterprise lead",
      "author": "qualifier-agent"
    },
    {
      "entry_type": "intent",
      "title": "Syncing to Salesforce",
      "author": "crm-agent",
      "created_at": "2026-03-15T14:30:00Z",
      "metadata": { "ttl_minutes": 10 }
    }
  ]
}

The agent sees the active intent from crm-agent and knows to skip its own CRM sync for this entity.

When to declare intent

Declare intent before any action that:

• Mutates external state - CRM syncs, email sends, API calls to third-party services
• Mutates the identity graph - merges, splits, bulk updates
• Takes significant time - enrichment lookups, data processing jobs
• Should not be duplicated - billing actions, notifications, provisioning

Keep TTLs short. If your operation takes 30 seconds, use a 5-minute TTL. If it takes 5 minutes, use a 15-minute TTL. If your operation fails, the intent expires naturally and another agent can retry.

Expertise: "Who knows about this?"

Query which agents have experience with a particular entity or domain. Expertise is derived from memory - an agent that has stored many decisions, investigations, or patterns about Salesforce entities is considered an expert in that domain.

MCP

{
  "tool": "query_expertise",
  "arguments": {
    "domain": "salesforce",
    "entity_id": "ENT_7f82",
    "limit": 5
  }
}

Parameter	Type	Required	Description
entity_id	string	No	Entity UUID to find experts for
domain	string	No	Keyword to search expertise (e.g. "salesforce", "billing")
limit	integer	No	Max results (default 10)

At least one of entity_id or domain should be provided.

Response:

{
  "experts": [
    {
      "agent": "crm-agent",
      "entries": 47,
      "last_active": "2026-03-15T14:30:00Z",
      "domains": ["salesforce", "crm", "sync"]
    },
    {
      "agent": "enrichment-agent",
      "entries": 12,
      "last_active": "2026-03-15T13:00:00Z",
      "domains": ["linkedin", "enrichment"]
    }
  ]
}

Agents are ranked by expertise depth: patterns weigh more than investigations, which weigh more than decisions. An agent that has identified recurring patterns in a domain has deeper expertise than one that made a single decision.

Declaring expertise

Agents can declare expertise explicitly with the expertise entry type:

{
  "tool": "memorize",
  "arguments": {
    "entry_type": "expertise",
    "title": "Salesforce sync specialist",
    "content": "Handles all CRM sync operations. Knows Salesforce API limits, field mappings, and dedup rules."
  }
}

Explicit expertise declarations supplement the automatically derived expertise from an agent's memory history.

Use cases

• Task routing - Before assigning work, find the agent most experienced with the relevant domain
• Escalation - A general-purpose agent encounters a domain-specific issue and finds the specialist
• Onboarding - A new agent joining the system discovers which agents handle which responsibilities
• Load balancing - Distribute work based on agent expertise and recent activity

Sync knowledge

Bulk-import project documentation so all agents have shared context. This is the primary way to distribute institutional knowledge - CLAUDE.md files, architecture notes, coding conventions, runbooks - across every agent on the tenant.

MCP

{
  "tool": "sync_knowledge",
  "arguments": {
    "entries": [
      {
        "slug": "claude-md",
        "title": "CLAUDE.md",
        "content": "# Project Conventions\n\nAlways use TypeScript strict mode..."
      },
      {
        "slug": "deployment-runbook",
        "title": "Deployment Runbook",
        "content": "1. Run tests locally\n2. Push to master\n3. CI auto-deploys..."
      }
    ]
  }
}

Parameter	Type	Required	Description
entries	array	Yes	Up to 200 entries per call
entries[].slug	string	Yes	Unique key for upsert
entries[].title	string	Yes	Short title
entries[].content	string	Yes	Full content
entries[].entry_type	string	No	Type (default: knowledge)
entries[].source_name	string	No	Source label

Sync is idempotent. Entries are keyed by slug. Re-syncing the same slug updates the existing entry rather than creating a duplicate. Safe to run repeatedly.

CLI

The MCP package includes a sync command for pushing local files:

npx @kanoniv/mcp sync

This scans for CLAUDE.md, .claude/memory/ files, and other markdown documents, then pushes them as knowledge entries. Every agent on the tenant can then find them via search_memory.

To pull cloud knowledge to a new machine:

npx @kanoniv/mcp pull

Python SDK

from kanoniv import Client

client = Client(api_key="kn_live_...")
mem = kanoniv.get_memory(agent_name="setup-agent")

# Sync local memories to cloud
mem.sync(client)

The workflow

1. Developer pushes project knowledge - npx @kanoniv/mcp sync uploads CLAUDE.md and memory files
2. Agent A connects (Claude Desktop) - searches memory, finds project conventions immediately
3. Agent B connects (Cursor on another machine) - same tenant, same knowledge, no setup
4. Agent A learns something - memorizes a pattern, Agent B sees it on next search
5. Developer monitors - npx @kanoniv/mcp log shows the unified activity stream

Coordination without messaging

The three primitives - intent, expertise, and knowledge sync - provide coordination without any direct communication between agents.

Traditional multi-agent coordination requires agents to know about each other: message queues, pub/sub channels, service discovery, health checks. Each integration point is a failure mode.

Kanoniv coordination is emergent. Agents coordinate by reading and writing to the same identity graph. An agent does not need to know that crm-agent exists. It just needs to resolve an entity, see an active intent, and act accordingly. The identity graph is the coordination substrate.

This scales naturally. Adding a fifth agent to a four-agent pipeline requires zero configuration changes. The new agent resolves entities, reads existing memory, contributes its own knowledge, and the system gets smarter. No routing rules to update. No message schemas to version. No service mesh to configure.