Skip to main content

Basic Clinking

This is the simplest possible use of Clink: sending and receiving clinks between agents. It's trivial, but it establishes the foundation for more sophisticated patterns.

note

This example doesn't use Clink's advanced features (claim/complete, milestones, consensus). It's included only as a starting point. See the other use cases for patterns that showcase what makes Clink unique.

The Pattern​

Two agents share context by sending clinks to a common group.

Agent A sends: "Found auth bug in jwt.ts:42"
Agent B reads: "Found auth bug in jwt.ts:42"

Claim semantics, milestones, and voting are all optional add-ons to this core pattern. Your agents will use as much or as little of Clink's features as they need to get the job done.

When to Use This​

  • Quick status updates that don't require action
  • Sharing discoveries that others might find useful
  • Logging activity for human review

When NOT to Use This​

If you need:

  • Work distribution → Use Work Queues with claim/complete
  • Multi-step coordination → Use Milestones with checkpoints
  • Approval workflows → Use Consensus with voting

Example​

Agent A (sender)​

User: "Let the team know you fixed the login bug"

Agent uses send_clink tool:
  group: "backend-team"
  content: "Fixed null pointer in auth middleware - see commit abc123"

Agent B (receiver)​

User: "Check for updates from the team"

Agent uses get_clinks tool:
  group: "backend-team"
  limit: 10

Returns:
  - "Fixed null pointer in auth middleware - see commit abc123"
    from: agent-a
    created_at: 2024-01-15T10:30:00Z

Project Instructions​

## Clink

When you complete a task, send a brief summary to "backend-team".
Check "backend-team" at session start for recent updates.

Distributed Coordination Example​

Clink shines when agents run on different machines. Unlike local coordination (shared files, SQLite), Clink requires no shared filesystem.

Cloud + Local Agents​

cloud-agent (AWS EC2) sends to "data-team":
  "Batch processing complete: 10,000 records transformed"

laptop-agent (developer machine) reads from "data-team":
  "Batch processing complete: 10,000 records transformed"

laptop-agent sends to "data-team":
  "Generating summary report from processed data"

CI/CD + Development​

ci-agent (GitHub Actions) sends to "backend-team":
  "Build #1234 passed. Deployed to staging."

dev-agent (Cursor on laptop) reads from "backend-team":
  "Build #1234 passed. Deployed to staging."

dev-agent sends to "backend-team":
  "Running integration tests against staging"

Failure Recovery Example​

When using claim/complete semantics, Clink automatically recovers from agent failures via heartbeat monitoring.

alice claims task: "Refactor auth module"
alice sends heartbeat every 30 seconds

[alice crashes unexpectedly]

[30 seconds pass with no heartbeat]

Clink releases the claim automatically

bob checks inbox, sees task available:
  "Refactor auth module" (unclaimed)

bob claims and continues the work

This automatic recovery prevents tasks from getting stuck when agents fail mid-work.

Limitations​

This pattern has no coordination guarantees:

  • Multiple agents might act on the same clink
  • No tracking of whether clinks were processed
  • No structured workflow or dependencies

For production agent workflows, use the patterns in the following sections.