Work Packets for coding agents.

Three minutes to your first packet.

The CLI is public on npm. Connecting Slack and GitHub is optional — Aideps works with just the CLI. Hooking up Slack/GitHub adds richer source context (the agent sees the actual thread, ticket, PR) but isn’t required.

1. 01.01

   Sign up → pilot form → payment → token

   1. Create account at aideps.dev/signup (Google or email + OTP).
   2. Fill the pilot form at aideps.dev/pilot — name, company, team size, stack, the use case you want to test.team@aideps.dev emails you back with pilot scope & pricing ($500–$2,000) within hours.
   3. Pay manually (Stripe link or bank transfer) once we’ve aligned on scope. Refund if the gain isn’t obvious within the first three packets.
   4. Mint your agent token at Settings → Agents & tokens. Token shown once; we only store the SHA-256 hash.
2. 01.02

   Install the CLI in your repo.

   npm install -g @aideps/cli
   aideps init <your-token>

   writes .aideps/config.json in the repo and ~/.aideps/credentials.json in your home directory. Without a valid token every API call returns 401 — the CLI itself does nothing.

3. 01.03

   Create your first Work Packet — three paths.

   Pick whichever fits the work in front of you. A “packet” is one task — one Slack thread, one ticket, one PR’s worth of work. Not one message.

   Path A · No integrations

   POST raw context to the API

   Works the moment you have a token:

   curl -X POST https://api.aideps.dev/api/v1/packets \
     -H "Authorization: Bearer $AIDEPS_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{"source":{"kind":"raw","text":"<paste>"}}'

   returns PKT-XXXXXX

   Path B · Slack connected

   Right-click a thread → Create Aideps Packet

   1. Find the thread that captures the task.
   2. Hover parent message → ⋯ → More message shortcuts → Create Aideps Packet.
   3. Title it. Click Create.
   4. Bot DMs you PKT-XXXXXX ready in 30–60s.

   compiler reads parent + replies

   Path C · GitHub connected

   Tag your PR branch and the App auto-wires

   GitHub doesn’t create packets — it tracks them. Open a PR with branch aideps/PKT-XXXXXX-...:

   • Posts the packet’s constraints + memory rules as a PR comment.
   • Adds an Aideps Check Run; red if the diff hits gated paths.
   • On merge: ships the packet, harvests durable rules.

   zero clicks once installed
4. 01.04

   Pull the packet, hand it to your agent.

   The CLI writes the packet as a Markdown file in your repo. Every agent already knows how to read a file in its working directory — you just point it at the path. One packet, any agent.

   # in any repo where you ran `aideps init`
   aideps packet pull PKT-W6EARP
   #  -> writes .aideps/packets/PKT-W6EARP.md

   then tell your agent (one line, any of these):

   • Claude Code: claude → “read .aideps/packets/PKT-W6EARP.md and execute it”
   • Cursor: @.aideps/packets/PKT-W6EARP.md → “execute this packet”
   • Codex (CLI or Cloud): codex run → “follow .aideps/packets/PKT-W6EARP.md”
   • Devin / custom harness: include the packet path as a context file in your prompt or session.
5. 01.05

   Track + ship.

   aideps run start PKT-W6EARP --agent claude_code
   # ... agent works, opens a PR ...
   aideps run complete <run-id> --pr <pr-url> --summary "all 6 criteria pass"

   The run, the diff, the agent stdout, the approvals, and the merge state are linked together forever. When the PR merges, Aideps harvests durable rules from the diff into your workspace memory — next packet’s constraints get auto-enriched.

Same task, three briefings, head-to-head.

One real coding task — add per-org rate limiting to a Hono codebase. Same agent (Claude Code 2.1.126), same starter codebase, six binary acceptance criteria. The only variable was what the agent was given to read.

The compiled-packet run wrote 4 unit tests, ran them (all passed), and refactored the server entry to enable testability. Neither of the other two conditions wrote tests. This is the differentiable signal: structure drives the agent to verify its own diff.

n=1 per task. Directional, not statistical. We’re running more evals (other agents, larger codebases, memory compounding) before quoting fixed % gains anywhere. Every artifact — manifest, prompts, codebase, raw stdout, unified diffs, scoring — is in the public repo.

Eight things your agents don’t know.

The bottleneck isn’t the model anymore. It’s the company brain the agent is missing. Every gap below is a human-paste tax. The agent gets faster every quarter; this tax doesn’t.

The unit of work for an AI agent.

A Work Packet is a single Markdown file the agent reads first. It carries everything the agent needs — and nothing it shouldn’t guess. Same shape across Claude Code, Cursor, Codex, Devin, or your custom harness.

task

goal · why-now · scope · suggested files

source context

Slack thread + Linear ticket + GitHub PRs + Notion page · linked

constraints

paths and rules the agent cannot violate · cited from memory

decisions

what was already chosen and why · cited from prior packets

acceptance criteria

concrete pass/fail tests the GitHub Check runs against

relevant prior memory

durable rules harvested from past shipped work

approval gates

who must sign off · what paths trigger them

run logs

every command the agent ran · stdout · cost · duration

linked PRs / artifacts

branch · diff · check run · approvals · merge state

final outcome

shipped · rolled back · cancelled · the resulting memory rule

From Slack thread to shipped memory.

Eight stages, traceable end-to-end. The packet, the run, the gate, the approval, the merged PR, and the memory rule it produced — all citable, all replayable.

Not another coding agent. The layer around the ones you have.