I Made an AI Project Manager PMI-Aligned

We’ve started working with AI like a colleague, not just using it as a tool.

We ask it to plan work, coordinate people, surface risks, and tell us what should happen next. But an AI colleague with that much responsibility needs more than intelligence. It needs professional discipline.

That is why I made Project Manager PMBOK 7 principles-aligned through documented tailoring: so an AI PM can operate with autonomy without confusing confidence for evidence—or rigor for bureaucracy.

This is not a claim of PMI certification. It is a concrete design decision about how the system decides which management disciplines apply, which do not, and how those decisions stay honest.

The employee model changes the product boundary

A chatbot attached to a task board still leaves the user operating the project-management software.

You move cards. You update fields. You repair dependencies. You rebuild the report. The chat box may make each operation easier, but you still translate project reality into tool operations.

An AI PM employee should reverse that relationship.

You should be able to say:

The vendor API is delayed until September 15. The launch date cannot move. Show me the credible options.

That statement may affect dependencies, schedules, risks, scope, ownership, evidence, and the next decision. The AI PM should trace those consequences together and maintain the working plan.

That requires autonomy.

It also creates risk.

Autonomy without discipline creates confident chaos

A language model can produce a plausible plan even when ownership is missing, dates are unsupported, and completion has no evidence.

The output may look polished while the project underneath it is incoherent.

The answer is not to bury every project under a heavyweight process. That would destroy the reason to use an AI PM in the first place.

The answer is to make process a deliberate, inspectable decision.

That is where PMI tailoring becomes useful.

“PMI aligned” needs a precise meaning

Project Manager is aligned with PMBOK 7 principles through documented tailoring.

PMBOK 7 makes tailoring central: the management approach should fit the project rather than forcing every project through the same machinery.

For a concrete declaration, Project Manager uses the ten familiar PMBOK 6 knowledge areas. Each area must be recorded as one of two things:

• Applied
• Tailored out, with a rationale

A discipline cannot disappear silently.

That distinction matters. A small internal project may genuinely have no procurement activity or dedicated cost budget. Omitting those areas can be correct. Omitting them because nobody considered them is not the same thing.

A tailoring declaration might look conceptually like this:

Area	Decision	Rationale
Integration	Applied	Changes must propagate across the plan
Scope	Applied	Success criteria and boundaries must remain explicit
Risk	Applied	Launch depends on an external vendor
Cost	Tailored out	Work is absorbed by the standing team
Procurement	Tailored out	No external purchasing is involved

The useful part is not the table. It is the fact that every omission becomes a recorded decision.

Tailoring is not checkbox theatre

A declaration is worthless if the system lets the project contradict it.

Project Manager therefore fails validation when the project says an area is tailored out but configures the corresponding management structure.

For example:

• Tailor out risk management, then add a risk register: validation fails.
• Tailor out stakeholder management, then add a stakeholder register: validation fails.
• Claim an area is applied, then report missing information as zero or “on track”: not allowed.

The declaration cannot become fiction.

This also changes reporting. A tailored-out area is reported as tailored out with its rationale. It is never silently omitted, represented as zero, or painted green.

“Cost: not tracked—no project budget; work is absorbed by the standing team” is honest.

“Cost: $0” may be completely false.

The system expands only when the project needs it

The smallest Project Manager project still has three files:

PROJECT.md
TASKS.md
STATUS.md

That is enough to define the outcome, organize the work, and derive current status.

Additional management modules appear only when they answer a real operating need:

• assumptions
• issues
• risks
• stakeholders
• decisions
• milestones
• lessons learned
• closure records
• traceability
• source and change history

This is the practical value of tailoring: rigor without mandatory ceremony.

A project can stay small without looking negligent. A controlled project can add the structures it needs without changing the underlying operating model.

Evidence is the counterweight to agent confidence

PMI alignment addresses management discipline. Evidence addresses execution truth.

An AI agent saying “done” is not proof that a task met its acceptance criteria.

Project Manager separates ordinary presentation from a stricter internal lifecycle:

planned  ready  in_progress  implemented  verification  verified  done

Completion must be supported by evidence mapped to the task’s acceptance criteria.

A closed issue is not automatically proof.

A commit is not automatically proof.

A file existing is not automatically proof.

Confident prose is definitely not proof.

The AI PM can coordinate people, agents, external systems, and software workflows, but they meet at the same boundary: a task contract defines the expected result, and an evidence manifest proves what happened.

That is how autonomy stays accountable.

Unknown must remain unknown

Project-management software is good at displaying false precision:

• confident dates without a real schedule
• green status without acceptance evidence
• percentage complete without a defensible calculation
• zero cost when cost was never tracked

An AI PM makes this problem worse if it treats every missing fact as an invitation to generate one.

Project Manager instead keeps unknown information explicit. It should challenge:

• a target date with no schedule evidence
• completion with no acceptance evidence
• work marked ready while a dependency is unfinished
• a plan that does not cover its success criteria
• a combination of scope, capacity, and date that cannot all hold

A useful project manager exposes the conflict. It does not decorate it.

What is deliberately not implemented

“PMI aligned” should not become a license to imply capabilities that do not exist.

Project Manager does not currently implement:

• cost accounting
• Earned Value Management
• critical-path scheduling

If a project needs those disciplines, they must be tailored out with a rationale or managed in another system with that boundary recorded.

That limitation is part of the design, not an embarrassing footnote.

A trustworthy AI PM should state where its authority ends.

The larger idea

The interesting shift is not from manual task management to AI-assisted task management.

It is from software you operate to an AI employee that maintains a coherent project with you.

You provide the outcome, constraints, evidence, and decisions that require human authority.

The AI PM keeps the plan aligned with reality.

PMI-aligned tailoring gives that employee discipline without forcing every project into the same process. Evidence-backed completion keeps its confidence from becoming project truth.

That combination—autonomy, tailoring, and evidence—is what makes an AI project manager credible.

Try it

Project Manager is open source:

github.com/yysun/project-manager

In your AI agent app, ask:

Install the project-manager skill from yysun/project-manager.

Then brief it like a colleague:

We need to launch the new website by October 15 without interrupting the current site. Rollback must be proven before launch. Establish the project, challenge anything vague, and surface the decisions I need to make.

Do not start with the board configuration.

Start with reality.