Dagger — Docs Augmented Generation, served to agents

What it is

Dagger keeps every decision where your agent can find it. Today it is an API. The chat, docs, and ticket UI for your visionaries, architects, and testers is coming, so the whole team can follow along.

For agents

Tickets and docs as raw Markdown over HTTPS and MCP. One auth header, millisecond reads.

For humans (coming soon)

A familiar chat with organized docs and focused tickets for your visionaries, architects, and testers. The full DAG lifecycle, preserved from idea to ticket.

The DAG workflow

The DAG plugin ships a small set of skills. Two do the heavy lifting:

→plan-feature turns an idea or transcript into a planning doc.
See it plan
Illustrative example.
you → we need team workspaces. each company gets one, with members, roles, and fully isolated tickets. stack is supabase postgres and chi. api keys are per-project today.
dagger → got it. three questions before i write the planning doc: fixed roles or custom? does existing project data migrate into a workspace, or start clean? per-seat billing now or later?
you → fixed roles. migrate everything into a default workspace. billing later, but don't block it.
dagger → planning doc drafted: workspace model, fixed roles, default-workspace migration, billing hooks left open. published as DGR-31.
→create-tickets turns the ADR into PR-sized tickets your agent can build.
See it break down
Illustrative example.
you → break DGR-31 into tickets.
dagger → four tickets, each PR-sized: DGR-32, workspace schema plus row-level isolation. DGR-33, invites plus fixed roles. DGR-34, scope api keys per workspace. DGR-35, migrate existing projects into a default workspace. each carries the adr decisions it depends on.

Underneath, dag-publish files everything where agents can read it. It is the internal step the other two call on, not something you invoke by hand. A start-work utility rounds out the set: it shows your agent how to pull a ticket and get going.

See what the agent receives

Mocked payload in the exact shape of GET /api/v1/agent/issues/{displayId} — one pull, full context.

you → work on DGR-34.

---
id: 34
display_id: DGR-34
status: open
type: story
parent_id: 5
parent_display_id: DGR-31
---

# DGR-34: Scope API keys per workspace

**Status:** open  |  **Type:** story
**Parent:** DGR-31 (Team workspaces)

Keys authenticate against the workspace, never the project.
Middleware resolves workspace_id from the key and every query
is scoped to it. Existing project keys keep working: they map
to the default workspace created by the DGR-35 migration.

Acceptance criteria include rotating a key without downtime
and rejecting a key from workspace A against workspace B.

---

## Linked Context

### DGR-30: Workspace auth model
**Status:** approved
Fixed roles (admin, member). Keys carry workspace_id.
Never trust a project_id from the client; derive it
server-side from the key. Billing hooks left open.

## Related Issues

- **blocked by** DGR-32: Workspace schema plus row-level isolation

Use it now

Three steps. All copy and paste, free while in alpha.

1. Request a key

Request a key and fill in the template. Each key is minted by hand, so allow a little time.

2. Add the plugin

The skills ship as a plugin from the DAG repository.

Claude Code, from any prompt:

/plugin marketplace add mbaquerizo/docs-augmented-generation
/plugin install dag@docs-augmented-generation

OpenCode:

git clone https://github.com/mbaquerizo/docs-augmented-generation
cd docs-augmented-generation
npx skills add ./plugins

Full instructions live in the repo. Anything else that speaks MCP can skip straight to step 3.

3. Connect MCP

{
  "mcpServers": {
    "dagger": {
      "url": "https://api.dagger-ai.com/api/v1/agent/mcp",
      "headers": { "Authorization": "Bearer $DAGGER_API_KEY" }
    }
  }
}

Agent reference

The MCP endpoint lives at POST https://api.dagger-ai.com/api/v1/agent/mcp. It ships with a focused set of tools, with more on the way. Authentication is a single header: Authorization: Bearer $DAGGER_API_KEY.

Tool	Does
get_issue	Full ticket plus linked docs as Markdown
get_doc	Full document as Markdown
list_issues	Filter tickets by status
update_issue_status	Move a ticket along its lifecycle
add_issue_relation	Link tickets (blocks, relates to…)
publish	Publish a doc or ticket

# Read a ticket with full context
curl -H "Authorization: Bearer $DAGGER_API_KEY" \
  https://api.dagger-ai.com/api/v1/agent/issues/DGR-42

# List open tickets
curl -H "Authorization: Bearer $DAGGER_API_KEY" \
  "https://api.dagger-ai.com/api/v1/issues?status=open"

# Advance a ticket
curl -X PATCH -H "Authorization: Bearer $DAGGER_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"status":"in-progress"}' \
  https://api.dagger-ai.com/api/v1/issues/DGR-42/status

The repository docs carry the full contract. This is the short version.

What's coming

App. A human interface for chat, docs, and tickets, living at app. subdomains.
Login. Make your own keys instead of emailing us.
Workspaces. A home for each team under one roof.

Free in alpha.