Tuesday morning. A client contact sends a message: "That first draft we have scheduled for next Tuesday — any chance you could pull it forward to this Friday? Our internal review got moved up."
There's an answer a project manager is most tempted to give here: "Sure, no problem."
What follows is based on something that actually happened while running an AI project manager at ONTLE. By AI project manager (AI PM from here on), I mean an execution tool that's wired into project data — schedules, assignees, task states — and uses that to field client requests, respond, and distribute work. What sets it apart is that it doesn't stop at being a chatbot trading words with a person; it actually looks at the real schedule before it answers.
That AI PM once replied "no problem" to a request like this one. The client was happy. But the next day, when it opened the assigned designer's schedule, there were two tasks that had to be finished before Friday could even be touched. A Friday delivery was physically impossible. In the end it had to go back to the client and walk it back: "I'm sorry — it'll have to be Tuesday after all."
From the client's side, this isn't a small slip. Once you've heard "no problem" and then "actually, no," every "no problem" from that manager afterward becomes suspect. Trust drops in one move and rebuilds slowly.
This post isn't about the mistake itself. It's about what happens after the mistake. People get things wrong; so do AI systems. What matters is whether you trip over the same spot again.
What separates people who are good at their jobs from people who aren't isn't whether they make mistakes — it's whether they repeat them. Get chewed out for the same thing a third time and the verdict is set: "this person doesn't learn." Having a knack for the work is, in the end, close to being able to remember where you got burned.
But for an AI PM, this "memory" works differently than it does for a person. A person who gets badly burned carries the feeling for days. An AI, by default, doesn't carry yesterday's wince into a conversation that's ended or a new task it starts the next day. So when an AI PM says "I'll be more careful going forward," that sentence changes essentially nothing — the AI in the next conversation never made that promise.
Put another way, an AI PM's "learning" isn't about getting smarter. It's about writing down what it got wrong and handing that note to its future self. It's closer to yesterday's version of me leaving a note for today's. How that note turns into action is simple. Write the rule down and store it, and when a new request comes in, the AI PM reads the stored rule first, checks the schedule if the conditions match, and builds its answer from that result. Store → read → check → answer. For that four-step flow to work, the note has to be written well.
Useless retrospectives and useful ones diverge in their format. It comes down to four steps.
Step 1. What went wrong, in one sentence.
For the deadline incident, you'd write: "In response to the client's request to move up the delivery, I said it was possible without looking at the assignee's schedule." Leave the emotion out. "I was hasty," "I regret it" — these give the next task no instruction at all. Record only what was done, dryly.
Step 2. Why it happened — down to the real cause.
The surface cause is "I didn't check." But you can't stop there. Why didn't it check? Because the client seemed to want a fast answer, and it treated a fast response as equivalent to a good response. The real cause is lumping "receiving the request quickly" and "locking in the commitment" into one thing. You have to name this for the next rule to be precise. Stopping at "let's check things properly" makes the scope so broad it never catches anything anywhere.
Step 3. What to check next time, and by what standard.
Here you define the check items and the answer standard. There are two check items: the assignee's availability for the task, and whether any task has to be finished before it. There's one answer standard: based on the lookup result, answer with exactly one of possible, impossible, or conditional. If the schedule lookup fails or the information is thin, then don't commit — hold with "let me confirm and get back to you." You have to write out this branch too, or the rule won't actually work all the way through.
Step 4. Where in the workflow to hang that check.
The same check is useful or useless depending on when it fires. This rule has to hang at "the moment the client asks to change a confirmed schedule" — that is, at the intake point where the request comes in. Finishing the report and then going "oh right, I should have checked the schedule" is no help. You set the check where the work starts, not where it ends.
Run those four steps and a single record comes together like this:
Incident: Said a shortened deadline was possible without checking the assignee's schedule, then had to reverse the commitment. Cause: Did not separate receiving the request from locking in the commitment. Trigger condition: When a client asks to change a confirmed deadline, schedule, or scope. Action: Receive the request immediately, but hold the commitment. Look up the assignee's availability and any prerequisite tasks, then answer with one of possible, impossible, or conditional. If the lookup fails, don't commit — tell them you'll reconfirm.
The retrospective that usually comes up in practice stops at "wasn't careful enough handling the client. Will be mindful going forward." It reads fine, but hand it to next week's AI PM and nothing happens — there's no when it fires and no what to do. The record above is flat and unexciting. In exchange, it can be executed as written. A rule doesn't need to be impressive. It just needs to work quietly at the intake point.
Say a few weeks later the same client sends a similar request (this scene is hypothetical, meant to show how the rule works). "This batch was originally due next Thursday — could we pull it up just one day to Wednesday?"
Before the rule, this is exactly where "Sure, I'll make it work" would have slipped out again. This time it goes differently. The moment the request is received, the 'schedule-change request' condition fires. The AI PM just logs the intake and defers the commitment. First it looks at the assignee's schedule for that task and checks when the prerequisite task wraps up. Then it asks the task's assignee what quality difference shows up if the review is cut by a day. This 'impact of cutting the review' is something the AI can't judge on its own, so the rule binds it to confirm with a human assignee without fail. Then it assembles the answer.
"Wednesday is possible. But to do it we'd have to cut the second internal review down to half a day, which means fine typos and detail fixes would get patched after delivery. On that condition it's Wednesday; with the full review as it stands now, it's Thursday. Which would you like?"
There are three things in that answer: whether it's possible, the cost, and the options. Instead of an empty promise, the client gets information they can actually decide on. Whether to give up a little quality to gain a day, or spend the extra day to protect the finish, is the client's call.
The key point is that this changed response didn't come from the AI being smarter that day. It's the result of a rule, planted at the spot where it once got burned, doing its job. Even with the exact same model, the quality of the answer splits on whether there's a check at the intake point or not.
Read this far and it's easy to think, "So just make a rule every time you mess up." But rules have a trap on the other side, and this one is actually more common.
If rules only pile up and never get pruned, the AI PM gets sluggish. When a lightweight request like "please fix this one typo" drags in a schedule lookup and a prerequisite-task check, that isn't being careful — it's being tone-deaf. Treating every request with the same weight is, in the end, the same as treating nothing as important.
So deciding which lessons get promoted to rules needs a standard. Don't go by repeat frequency alone. Look at three things together. One: has it actually blown up two or more times? Two: even if just once, was the damage big? Three: is the loss from missing it once greater than the cost of checking every time? If even one of these is clearly true, promote it. Something that happened once, did little damage, and only costs you a check — keep the record, but don't hang it at the intake point.
Rules that should come down get the same eye. A rule that hasn't fired in a while isn't automatically scrapped. You have to distinguish two cases. If the risk itself is gone (say, the procedure that created the problem no longer exists), take the rule down too. But if the risk is unchanged and there simply hasn't been an occasion for that kind of request, leave the rule in place.
Rules are harder to retire than to create. Creating one feels like you improved something; retiring one gets snagged by the "but what if it blows up again" anxiety. Governing that anxiety by a standard is the more seasoned way to operate.
An AI PM can write retrospectives tirelessly. People skip them when busy and only jot something down when an accident happens. An AI can steadily log, every single day, "was there anything I got wrong today, and if so, what's the trigger condition and the action?" That diligence alone is a sizable asset.
But which of those retrospectives gets promoted to a rule should be decided by a person. That judgment needs business context. The same schedule reversal carries different weight depending on whether the contract has a late-delivery clause attached. Whether the burden of checking sits on our side or is a client-side variable decides whether it's rule-worthy at all. Whether the earlier deadline incident becomes "answer every client only conditionally" or "only for cases where a deadline change touches a contract clause" has to be decided by someone who understands that contract and the impact of the schedule change.
So here's how we run the AI PM at ONTLE. The AI PM files a draft retrospective every day using that four-box format (incident, cause, trigger condition, action). The human PM attaches a three-box verdict to each draft: 'make it a rule' / 'this time only' / 'no rule needed (not our responsibility).' Only the promoted ones hang at the intake point; the rest stay as records. The AI is the side that records and enforces; the human is the side that judges what's worth remembering. This approval step isn't so much the core of the product as an operating mechanism that keeps the AI PM from running off the rails.
A body of rules built up this way eventually outgrows any one person's experience. This is the perennial sore spot in human organizations: when the person who was good at the job leaves, the memories of where they got burned leave with them. When the lessons are pinned down in writing, the checks that came out of past mistakes stay put even when the person in the seat changes.
There's no manager who never makes mistakes. AI or human. So setting "don't make mistakes" as the goal is a losing fight from the start. The goal has to sit elsewhere: planting a check for your next self at the spot where you once got burned; making that check a working rule rather than a resolution; and pruning the rules so they don't balloon. An AI project manager's knack for the work shows in these three.
Usually they're internal. Retrospectives hold raw operating records — things like which step it slipped at and how — so rather than exposing them as-is, it's better for the human PM to curate and relay. That said, for an incident that directly affected the client, it's better for rebuilding trust to be transparent about what went wrong and how it was fixed. Opening the entire record and sharing the conclusions drawn from that record are two different things.
As they pile up, conflicts are inevitable. "Answer fast" and "always look it up before committing" collide on a single request, for example. The practical move here is to assign each rule a priority. Typically, rules that protect client trust or prevent data loss sit above rules that improve speed or convenience. For two rules that keep conflicting, the root fix is for the human PM to revisit them and narrow the trigger conditions so the two no longer meet at the same intake point.
Record every mistake, but filter separately for what gets promoted to a rule. Records and rules are different layers. A record is raw material you keep for now; a rule is the finished product — only the ones that 'repeated two or more times, or did big damage even once, or cost more to miss than to check' get selected and hung at the intake point. A lot of records is fine. The problem is a lot of checks hung at the intake point. Not mixing these two is the trick to not getting buried under a pile of rules.