Project Management Template for Human-Agent Teams

A project management template for human-agent teams must do more than organize tasks. It needs to preserve why the project exists, separate proposals from approved work, define what an AI agent may change, and make every consequential action reviewable and reversible.

A reliable project system separates why, authority, work, risk, and proof instead of collapsing them into one task list.

Copy this project management template

Use four related databases: Projects, Tasks, Decisions, and Risks. Add Goals or Evidence as separate databases when the portfolio is large enough to justify them.

Projects database

Tasks database

Decisions database

• Decision ID

• statement

• status: Proposed / Accepted / Superseded / Reversed

• decision owner

• rationale

• alternatives

• evidence

• source meeting or document

• effective date

• affected projects

• review or reversal trigger

Risks database

• Risk ID

• risk statement

• category

• likelihood

• impact

• owner

• mitigation

• trigger

• status

• linked project

• review date

Project page template

# [Project name]

## Outcome

- **Problem:**
- **Target outcome:**
- **Success metrics:**
- **Non-goals:**
- **Project owner:**
- **Sponsor:**
- **Target date:**
- **Review cadence:**

## Context and evidence

- Customer or user evidence:
- Business evidence:
- Technical evidence:
- Constraints:
- Assumptions:

## Scope

### In scope

- [Deliverable]

### Out of scope

- [Explicit exclusion]

## Milestones

| Milestone | Owner | Target | Exit criteria | Status |
| --- | --- | --- | --- | --- |
| [Milestone] | [Person] | [Date] | [Evidence] | Proposed |

## Decision log

[Linked view: Decisions filtered to this project]

## Work plan

[Linked view: Tasks filtered to this project]

## Risks and dependencies

[Linked view: Risks filtered to this project]

## Human-agent operating policy

### Agent may

- summarize verified project state;
- propose tasks, owners, dates, and risk updates;
- draft reviewer packets;
- update fields explicitly approved for automation;
- create approved tasks with stable idempotency keys;
- reconcile destination state.

### Agent must not

- approve its own proposal;
- invent an owner or deadline;
- change scope, budget, permissions, or target date;
- mark work Done without evidence;
- publish or message external people without approval;
- delete or archive records;
- conceal an exception.

## Weekly review

- Outcome and metric movement:
- Milestones changed:
- Work completed with evidence:
- Blocked or overdue tasks:
- Decisions needed:
- Risks changed:
- Agent exceptions:
- Next review:

The short answer

A human-agent project system needs six contracts:

1. a project outcome with measurable success;

2. typed task, decision, risk, and evidence records;

3. controlled lifecycle states;

4. explicit authority boundaries for agents;

5. human gates before consequential actions;

6. reconciliation that proves downstream state.

A template is useful when it makes these contracts visible by default.

The minimum architecture

Keep Projects and Tasks separate.

A project is an outcome-bearing container. A task is a bounded action. One project can contain many tasks; the same task should have one accountable owner and one current lifecycle state.

Connect:

• projects to goals;

• tasks to projects;

• decisions to projects and affected tasks;

• risks to projects and mitigations;

• documents and meetings to projects;

• evidence to decisions, tasks, and milestones.

Notion’s official Projects setup uses connected Projects and Tasks databases. Notion task databases require status, assignee, and due date properties. Unique IDs, sub-items, dependencies, board views, timelines, and sprints add execution structure.

Human and agent roles

Humans own

• strategy and project outcome;

• authority and permissions;

• scope, budget, and target dates;

• prioritization;

• approval of decisions;

• acceptance of ambiguous work;

• external commitments;

• final verification.

Agents assist with

• turning approved plans into proposed tasks;

• extracting risks and dependencies;

• summarizing project state from evidence;

• identifying missing owners or dates;

• detecting duplicate or contradictory work;

• preparing milestone-review packets;

• executing pre-approved, scoped updates;

• reconciling records across systems;

• drafting the next review agenda.

The key word is proposed. An AI-generated task should begin in Proposed, not Ready or In progress.

Agent authority levels

Level 0: Read and summarize

The agent may retrieve project context and produce a report. It cannot write.

Level 1: Propose

The agent may create proposed records in a review queue. A human approves, edits, or rejects them.

Level 2: Execute approved actions

The agent may perform specific tools after a human approves the proposed payload.

Level 3: Bounded automation

The agent may act without per-item approval only inside a narrow policy: known project, approved schema, allowed fields, defined risk class, idempotency, audit log, and exception routing.

Do not grant Level 3 because an agent “usually gets it right.” Grant it only when the workflow contract makes failure bounded and observable.

Higher autonomy requires a narrower policy boundary, stronger controls, and explicit verification.

The task-state contract

Use:

• Proposed

• Ready

• In progress

• Blocked

• In review

• Done

• Cancelled

Define transitions.

Proposed → Ready requires an owner, due date, acceptance criteria, project link, and reviewer approval.

Ready → In progress requires the owner to accept the work.

In progress → Blocked requires a blocker reason, blocker owner, and next review date.

In review → Done requires completion evidence and acceptance.

An agent may propose a transition. Deterministic validation should enforce required fields. A human or explicit policy provides authority.

Milestones are gates, not decorative dates

A milestone should state what becomes true and what evidence proves it.

Weak milestone:

Beta ready — August 1

Stronger milestone:

Design-partner beta approved — 12 invited accounts configured, onboarding test passed, legal terms approved, support runbook assigned.

Add:

• milestone owner;

• target date;

• exit criteria;

• evidence;

• blocking decisions;

• related risks;

• approval status.

If an agent reports milestone progress, it should cite evidence records instead of inferring progress from task count alone.

Dependencies and sub-items

Use sub-items when a parent task must be decomposed into separately owned work.

Use dependencies when one task cannot begin or finish until another changes state.

Notion can automatically shift dependent dates using different policies, including shifting only on overlap, maintaining time between items, or not shifting automatically. Treat that setting as a scheduling rule, not as approval to move contractual dates.

When an agent proposes a dependency, validate:

• source and target tasks exist;

• the link does not create a cycle;

• task direction is correct;

• date impact is visible;

• affected owners are notified or asked to approve;

• external commitments are not silently moved.

Dependency automation may calculate a date shift, but affected commitments still require review and destination read-back.

Sprint support

Notion sprints require a Task database. Its sprint system provides current, planning, backlog, and timeline views, plus options for incomplete work.

Use sprints when the team has a time-boxed delivery cadence. Do not force every project into sprints.

For human-agent teams:

• the agent can propose sprint candidates from priority, readiness, capacity, and dependencies;

• a human commits the sprint;

• incomplete work is reviewed, not silently rolled forward;

• sprint completion includes evidence and retrospective notes;

• automation does not rewrite scope after commitment without a visible exception.

The project review packet

A weekly review should answer:

1. Is the intended outcome still correct?

2. What evidence changed?

3. Which milestones advanced or slipped?

4. Which tasks completed with proof?

5. Which tasks are blocked or overdue?

6. What decisions are required?

7. What risks increased?

8. What did the agent propose or execute?

9. What exceptions remain?

10. What must be true by the next review?

An agent can generate the packet, but each claim should link to a current record or source.

The exception queue

Create a view for:

• task without owner;

• due date missing;

• acceptance criteria missing;

• Done without evidence;

• dependency cycle suspected;

• project health changed without rationale;

• target date moved;

• agent write rejected;

• destination state differs from source;

• permission boundary crossed;

• stale review date;

• open decision blocking committed work.

Each exception needs an owner, severity, created time, SLA, resolution, and verification result.

AI project update schema

{
  "project_id": "PRJ-104",
  "as_of": "2026-07-21T09:00:00Z",
  "summary": {
    "health": "at_risk",
    "confidence": 0.82,
    "evidence_ids": ["EV-118", "TASK-4821"]
  },
  "proposed_updates": [
    {
      "record_id": "TASK-4821",
      "field": "status",
      "from": "in_progress",
      "to": "blocked",
      "reason": "Legal approval is unresolved",
      "evidence_ids": ["RISK-042", "DEC-071"],
      "requires_approval": true
    }
  ],
  "exceptions": []
}

Validate record IDs, fields, prior values, allowed transitions, evidence, and permissions before applying any update.

Idempotency and reconciliation

Every external write needs a stable key.

For task creation, use the canonical Task ID. If a retry occurs, update or return the existing task rather than creating a duplicate.

After execution:

1. store the destination record ID;

2. read the destination record;

3. compare owner, due date, status, and project;

4. record reconciliation time;

5. route mismatches to the exception queue.

A connector returning success is not enough. The system must prove durable state.

Project views to create

Portfolio

Projects grouped by goal or strategic theme, showing health, owner, target date, and outcome progress.

Active projects

Only approved active work. Sort by health and next review.

My tasks

Tasks assigned to the current person across projects.

Agent proposals

Records where Agent state = Proposed by AI.

Approval queue

Proposed transitions or actions requiring an authorized reviewer.

Blocked work

Tasks with Blocked status, blocker owner, and next review date.

Decision queue

Open decisions sorted by impact and needed-by date.

Risk register

Open risks grouped by severity.

Reconciliation failures

Source and destination records that do not match.

Common template mistakes

One database for projects and tasks

Projects and tasks have different lifecycles and required fields. Relate them instead.

Progress equals completed-task percentage

Ten trivial tasks can hide one blocked milestone. Report outcome and exit-criteria evidence.

AI has edit access but no policy

Tool access is not authority. Define allowed records, fields, transitions, and risk classes.

Missing Proposed state

Without a proposal state, generated work can appear approved.

Agent invents owners

Unknown ownership should become an exception.

Done without evidence

Require a link, artifact, test, approval, or other observable proof.

Automation moves dates silently

Dependency shifts and sprint rollover can change expectations. Surface and review material changes.

No read-back

Verify external task state after writes.

Every project has its own task database

This fragments portfolio and workload views. Prefer a governed shared task source per teamspace, consistent with Notion’s migration guidance.

When Notion is enough

Notion can be enough when the team benefits from connected documents, projects, tasks, views, IDs, sub-items, dependencies, sprints, buttons, and lightweight automations.

Add a dedicated execution system or integration when you need:

• code-native issue workflows;

• complex capacity planning;

• strict release or incident gates;

• cross-system transactional writes;

• stronger audit and policy enforcement;

• high-volume event processing.

Keep the project context and decision record connected even when execution lives elsewhere.

Frequently asked questions

What should a project management template include?

Include projects, tasks, owners, dates, outcomes, milestones, decisions, risks, dependencies, evidence, review cadence, approval states, and agent authority.

What properties does a Notion task database require?

Notion documents status, assignee, and due date as required task-database properties.

Should AI agents create project tasks automatically?

Start with proposed tasks and human review. Use bounded automation only after the schema, allowed fields, authority, idempotency, audit, and exception handling are stable.

How should project progress be measured?

Measure outcome evidence and milestone exit criteria, supported by task state. Do not rely only on percentage of tasks completed.

Can Notion manage dependencies?

Yes. Notion supports task dependencies and optional date-shifting policies. Review impacts before moving external commitments.

Can Notion manage sprints?

Yes. Sprints can be enabled on a Task database, with sprint planning, current, backlog, and timeline views.

What is the minimum safe agent write contract?

Known record, allowed field, expected prior value, allowed transition, evidence, authority, idempotency key, audit log, and post-write read-back.

Last verified: July 21, 2026.

Use the reusable template

Use the working table below to run one real project. Keep outcome, owner, risk, next milestone, and evidence visible so AI suggestions cannot silently become commitments.

Sources

• Notion: Getting started with projects and tasks

• Notion: Migrating to Notion for project management

• Notion: Task databases and sprints

• Notion: Sub-items and dependencies

• Notion: Database buttons

• Notion: Database templates

Product facts were verified on July 21, 2026.

Put the template into use

1. Create Projects, Tasks, Decisions, Risks, and Evidence as separate but linked records.

2. Assign one accountable owner and one acceptance test to every active task.

3. Give agents proposal or bounded-write authority; require confirmation for scope, budget, permission, or release changes.

4. Review blocked work and stale evidence weekly, then archive completed project state instead of deleting its history.

Where Dokki fits

Dokki is designed for this shared human-agent operating model: documents, tables, decisions, and agent output remain connected and reviewable. Start with one project and measure whether handoffs become clearer and recovery becomes faster.

• Content calendar template for an AI editorial workflow

• Meeting notes template for decisions and actions

• Notion Custom Agents workflow and permissions