I’ve already visually confirmed no em/en dashes in the draft and both flagged “X, not Y” constructions are rewritten as separate plain sentences. Here is the corrected markdown.
When a pull request breaks something, an engineering team already knows how to investigate. Open the PR, read the diff, see who approved it, check the CI run, read the commit message. None of that is remarkable. It’s just how a team finds out why a change happened, and nobody has to ask permission to look.
When an AI assistant sends a message in Slack, updates a task, or edits a wiki page, something in your work has changed too. But the point where it decided to make that change usually isn’t the point where you see the result. By the time the message lands, the prompt behind it, the passages it pulled up before answering, and the model version that produced the output can already be gone. There’s rarely an equivalent of a diff to open. A week later, when someone asks why a task got reassigned or a page got edited, the answer is often just “the AI Coworker did it,” and the trail stops there. Nobody is lying when they say that. There’s just nothing further back to check.
Three things go into every response, and only one of them is visible
Dutify’s AI Coworker, the assistant surface that runs in Slack, Teams, and over API, answers a question or takes an action by combining three separate inputs: what someone asked or an automation instructed it to do, whatever passages it pulled from your tasks, docs, or meeting notes to answer with, and a particular version of a particular model doing the reasoning. What you read afterward is one output built from all three, and it looks the same regardless of which one caused a problem. A confidently wrong task update reads the same whether the assistant misread the instruction, pulled the wrong page, or was simply reasoning worse than it did the week before because the provider shipped a new model behind the same name.
That distinction has a direct consequence for anyone debugging a wrong answer. A wrong instruction means someone phrased the request ambiguously, and the fix is asking it differently next time. Stale retrieved context means the assistant answered from a page that no longer reflects reality, and the fix is updating or re-scoping what it’s allowed to read. A model-version issue means the provider changed how the underlying model behaves, and no amount of better prompting will help until you account for it. Each of those has a different fix, and mistaking one for another costs the same afternoon a wrong hypothesis costs in any debugging session: you patch the layer that wasn’t broken, watch the same wrong answer come back a few days later, and start over with less patience than you had the first time. Without visibility into which of the three happened, a team is left re-prompting and hoping, which is not actually debugging, just retrying with better manners.
Getting a yes before the write happens
As of last month, Dutify’s AI Coworker no longer applies a write action the moment it decides on one. When someone chats with it in Slack or Teams and it proposes creating a task, changing an owner, or updating a field, that proposal sits in front of the person until they review and approve it. Nothing gets written to Dutify Cloud, Codexum, or Roadmarq without someone seeing the specific action first.
That review step solves the most urgent version of the reproducibility problem: it stops a bad decision from becoming a bad write. It doesn’t, on its own, explain why the assistant proposed that action in the first place. A person approving a task reassignment sees the proposed change. They don’t see the paragraph of retrieved context that convinced the model the new owner was correct. If that context was wrong and the reassignment still looked plausible on its face, the approval goes through anyway. Only later, when the actual owner never sees the task, does anyone realize something upstream was off, and by then the approval itself is the only record left of what happened. Catching the write is progress over catching nothing. Explaining the write is a separate problem, and it’s the one that decides whether a team trusts the assistant with the next action or just this one.
What the assistant read has probably already changed
Most of what the AI Coworker retrieves before answering comes from documents that keep changing. A runbook in Codexum gets a paragraph corrected once someone notices it’s out of date. A task’s custom fields get edited as a project moves forward. A meeting summary in Dutify Hub gets a follow-up note added days later. None of that is unusual. It’s what a live wiki or a live project board is supposed to do, and nobody would want it working any other way.
It creates a specific problem for investigating a decision from a week ago. If the AI Coworker read a Codexum page on Tuesday and answered based on what it said then, opening that same page today shows this week’s version, not last Tuesday’s. A link to the source page tells you where the assistant looked. It doesn’t tell you what was actually there when it looked, unless the system captured the passage itself at the moment of retrieval rather than just a pointer to it. That gap matters most exactly when you need it closed: after someone has already edited the page to fix the thing that made the answer wrong, which is usually the first thing a team does once they notice something was off.
It also complicates the approval step from the previous section in a way that isn’t obvious until it bites you. The person reviewing a proposed task reassignment is reading the current state of everything around them: the current owner field, the current page, the current thread. The assistant’s proposal was built from whatever those things said at the moment it ran, which might already be a version behind. An approver can look at a proposal, check the page it’s supposedly grounded in, see nothing wrong with either, and approve a change that was actually reasoned from a state of the world that no longer exists. Approval checks the decision against the present. It doesn’t check the decision against the past it was actually made from, and those are not always the same review.
The same bar you already use for changes to your systems
None of this requires treating every AI Coworker action like a security incident. Most write actions are small, low-stakes, and correct. The point of being able to reconstruct one is the same as the point of keeping PR history and CI logs around for changes nobody expects to ever need to investigate: you don’t build it for the ordinary case, you build it because you can’t tell in advance which case will turn out to be the one that matters. The team that never opens a six-month-old PR still wants the option there the one time a customer asks why a field changed and nobody remembers doing it. The same applies here. A task nobody questions for months is exactly the kind of change that gets questioned eventually, usually by someone who wasn’t in the room when it happened.
That question is worth asking about any AI-native tool your team adopts. Dutify is only the example at hand here. Can you see the instruction that produced a given action, the specific passages it was grounded in, and the model version that reasoned over them, for something the assistant did last week rather than what it’s doing right now? A tool that only shows you the present moment is asking you to trust every past decision on faith. A tool that keeps the trail is asking you to check its work, which is a much easier thing to say yes to.