Keel

Stop writing status updates.

Keel reads your team's chat, meetings, and commits, keeps the plan true, and tells you what is slipping and why. Every change to the plan arrives as a proposal you approve.

Signals reaching Keel, sample project

#launch“Backend auth is delayed 4 days”Auth service +4d GitHubPR #212 merged into mainPayments API ready for review Meeting 14:02“Let's drop Apple Pay from the first release”Decision logged GitHubNo commits on auth-refresh for 6 daysDrift on Auth service #design“Pricing screens are signed off”Pricing screens done

One message in chat. Four days gone from the launch.

of slack before launch

Scroll to watch Keel follow the delay through every task that depends on it.

Proposal from Keel

Shift 3 tasks +4 days

Auth service moved 4 days. Payments API, App integration, and Mobile release depend on it. Launch keeps its date but loses all of its slack.

Northwind checkout launch On track, 86% confidence Launch Nov 18
Dev in #launch, 10:31

Backend auth is delayed 4 days.

  1. BackendAuth serviceNov 3Nov 3
  2. BackendPayments APINov 7Nov 7
  3. WebApp integrationNov 12Nov 12
  4. MobileMobile releaseNov 14Nov 14
  5. MilestoneLaunch4d slack4d slack

One loop runs the whole plan

Whatever comes in, a chat message, a commit, a meeting, it travels the same path. Only your approval changes the plan.

  1. Signal

    Someone writes, pushes, or says something that affects the plan.

  2. Risk

    Keel links it to a task and works out every task downstream.

  3. Proposal

    The change is written up with its reasoning and the source attached.

  4. Your approval

    Approve, edit, or reject. Nothing moves before this step.

  5. Record

    The change is logged with who proposed it and who approved it.

Start where the work already is

No new habits. Keel picks up the briefs, meetings, and questions your team already has.

Paste a brief, get a plan you can check

Keel turns a rough brief into tasks, estimates, and dependencies. It flags what it could not work out instead of guessing.

  • Loops in the dependencies are caught before anything is created
  • Tasks with no clear owner are marked for you to assign
  • Nothing is created until you approve the plan
Brief to plan Written by Keel
Your brief

we need stripe checkout live before the nov 18 launch. backend owns auth + payments api, web does the app integration, mobile ships after that. design needs new pricing screens. not sure who does the receipts email??

Plan preview
  • Checkout
  • Auth service5dBackend
  • Payments API4dBackend, after Auth service
  • App integration3dWeb, after Payments API
  • Mobile release2dMobile, after App integration
  • Pricing
  • Pricing screens3dDesign
  • Receipts email2dNo owner yet. Pick one before approving.
✓ No dependency loops

You decide how far the agent goes

Pick one setting for the whole workspace. New workspaces start with every change waiting for a person, and you can loosen it when you trust it.

How approval levels work

Workspace settings, approvals

Even small changes wait for a person. This is where new workspaces start.

  • Add a comment ◆ Waits for approval
  • Add a label ◆ Waits for approval
  • Link a commit to a task ◆ Waits for approval
  • Shift task dates ◆ Waits for approval
  • Reassign a task ◆ Waits for approval

Every warning shows where it came from

A task marked at risk tells you why in one line, then shows the messages and commits behind it. Dates come from dependency math, not from the AI, so the same plan always gives the same answer.

Why the model never sets dates

App integrationAt riskNov 12 to Nov 16

Moved 4 days because Payments API moved, which waits on Auth service.

  • Message in #launch, Oct 22Dev: “Backend auth is delayed 4 days.”
  • Commit on auth-refresh, Oct 20a41c9e2 fix token refresh on expired sessions

Let the plan keep itself.

Connect GitHub, invite your team, and see your first risk the next time someone mentions a delay.