Back to Projects
Work Management architecture diagram showing three tiers — Consumers (browser and MCP clients), Applications (Next.js app and MCP server with ADF connector and WM Daemon), and Supabase data layer

Work Management

The execution spine of the Agentic Work System — a Next.js + Supabase system of record for all projects, plans, tasks, and backlog, with a full MCP adapter for agent-driven orchestration.

The Problem

ADF defines how development projects move through stages. But work isn’t only software development — it’s consulting, board work, business operations, personal projects, and every other domain where things need to get done. A system that only tracks ADF projects misses most of the actual work.

Work Management is the execution spine that tracks all of it, with a design that makes it accessible to both humans (via a Next.js UI) and agents (via a full MCP adapter).

Architecture

Two applications, one system:

Main App (/) — Next.js App Router, Supabase backend. The human interface: projects, plans, phases, tasks, backlog, activity. A system of record, not a task manager. It tracks state and flow; it doesn’t drive them.

MCP Server (/mcp-server) — stdio or SSE transport. The agent interface: exposes the same data model to any authorized agent. An ADF agent can read its current task list, update status, create backlog items, and query blockers — without touching the UI.

The WM Daemon

The daemon is what makes Work Management genuinely operational rather than just a data store:

npm run wm:daemon

Always-on runtime with:

  • Execution monitor — watches active tasks for stuck states, overdue items, missing updates
  • Triage loop — routes untriaged backlog items to the right project/phase
  • Health endpoints: /healthz, /readyz, /metrics, /ops/jobs

This is the closest WM gets to autonomy: the daemon makes decisions about work routing and escalation without waiting for human input. It’s deterministic — rule-based, not LLM-driven — but it runs continuously and acts.

Relationship to ADF

ADF and Work Management are peers, not parent-child. Both operate within the AWS architecture at different levels:

  • ADF operates in the Operations layer — it governs how development projects move through stages
  • WM operates in the Management layer — it’s the execution spine for all work, development and otherwise

ADF projects sync into WM via ADF connectors (npm run test:adf-sync). WM doesn’t live within ADF, and ADF doesn’t depend on WM — but they’re designed to complement each other at their respective layers.

Why an Agent-Accessible Work OS

The MCP adapter exists because human-only interfaces create agent blindspots. If an ADF agent can’t see the full backlog, it can’t prioritize. If Krypton can’t query work state, its cross-system recommendations are incomplete. Making work state agent-queryable is a design requirement, not a nice-to-have.

The whats_next, get_status, get_blockers MCP tools are the most-used by agents. They answer the question agents most often ask: “what should I be working on right now?”

Connection to the Agentic Work System

WM is Management layer infrastructure. Every project in the AWS ecosystem — ADF builds, open source tools, client work — has a corresponding entry in WM. The backlog is the source of truth for what needs to happen. The daemon enforces flow.