# How to Correct an AI Employee's Mistakes (2026) > By Kris Newlin, Paweł Siuciak · Published 2026-10-16 > Written with [Viktor](https://viktor.com), the AI employee. > Source: https://viktor.com/blog/how-to-correct-your-ai-employee-when-it-gets-something-wrong How to correct AI output that arrived wrong: reply in the same thread, name the exact wrong value, supply the constraint that was missing, and restate the rule for next time, all in one message. Then verify the redo before accepting it. This page covers only output that already came back wrong. The loop below makes the fix stick so the error does not return next run. ## How to correct AI mistakes: the loop that actually changes behavior In the thread where the wrong output landed: 1. Diagnose which root cause produced the error. 2. Name the exact error and the expected output in one message. 3. Verify the explanation and sources before accepting the fix. 4. Write the rule down so it survives the next run. [Start free, up to $100 in credits, no card →](https://app.viktor.com/signup) ### Step 1: diagnose which root cause produced the error - **Ambiguous instruction.** You asked for “pipeline” and he counted every open deal, stale ones included. This is the operator’s bug; the fix is a sharper definition, covered in the guide to [writing Tasks your AI employee can run](https://viktor.com/blog/how-to-write-tasks-for-your-ai-employee). - **Missing context.** He did not know deals marked “on hold” are excluded, because nobody told him. - **Stale tool connection.** The CRM data was hours old or the connection had expired. The reasoning was fine; the input was not. - **Genuine model error.** Right data, clear instruction, still a miscount. The only one a redo alone can fix. ### Step 2: name the exact error and the expected output “This looks off” forces a guess at what displeased you, and a guess can add a new error. State three things in one message: the wrong value, the missing constraint, and a request for the source. > The pipeline total in this report is wrong. It shows 14 deals, but two of those were marked closed-lost on Tuesday and should not be counted. Pipeline total means deals in stages qualified, proposal and contract sent only. Which source and filter did you use? ### Step 3: verify the explanation and sources before accepting the fix Read the explanation before the corrected number; it tells you which cause you had: - “I counted every deal with an open date this month”: the instruction was ambiguous about stages. - “The CRM query returned these 14 records”, with two closed-lost rows in the list: the filter or the data was the problem. - “I do not have access to the deal-stage field”: a connection or permission issue, not a reasoning issue. Then check the redo against the source he names, not against your gut; a confident second wrong answer is what this step exists to catch. If the explanation cannot reconstruct where a number came from, treat the whole report as unverified. The guide to [verifying your AI employee’s work](https://viktor.com/blog/how-to-verify-your-ai-employees-work) covers that check before output ships. ### Step 4: write the rule down so it survives the next run A correction that lives only in one thread will be made again. With Viktor the write-down is part of the exchange: his docs state that when you share a lasting preference, goal, correction or fact about yourself, he records it in your personal skill in the same run, even when your actual request was something else, and next time the preference is already applied ([Personalize Viktor](https://viktor.com/docs/personalize-viktor)). Lasting facts about the team go into a shared team skill the whole workspace benefits from. For recurring work, the rule belongs in the Task itself, so the next scheduled run carries it. The post on [giving your AI employee memory](https://viktor.com/blog/how-to-give-your-ai-employee-memory) explains what he keeps for you versus for the team. Close the loop with one more line: “Confirm you saved it and repeat the rule back to me.” A misread rule is cheap to catch now. [Browse 9,800+ one-click integrations →](https://viktor.com/integrations) ## A real exchange: a wrong report, the correction, the saved rule The example is generic. > **Viktor, Friday 9:00, #sales:** Weekly sales summary is ready. Pipeline total: 14 deals. Full table attached. > > **Ops manager, 9:04, same thread:** @Viktor the pipeline total is wrong. Two of the 14 were marked closed-lost on Tuesday. Pipeline total means deals in stages qualified, proposal and contract sent only, and that applies every week. Which filter did you use? Then redo the summary. > > **Viktor, 9:05:** I pulled every deal with an open date this month and did not filter by stage, so the two closed-lost deals were included. Redone with the three stages: 12 deals. Saved for the weekly sales summary: count only qualified, proposal and contract sent; exclude closed-lost and on-hold. Repeating it back: pipeline total = qualified + proposal + contract sent. Three things happened in five minutes: the error was named with the records behind it, “every week” marked it as a standing rule, and the redo came with the filter stated, so the manager could check it against the CRM. ## Which corrections should become permanent instructions? The test: will the expectation exist next time the same work runs? ```json:object { "_key": "k96", "_type": "table", "rows": [ { "_key": "k90", "_type": "tableRow", "cells": [ "The correction", "One-off or standing", "Where it lives" ] }, { "_key": "k91", "_type": "tableRow", "cells": [ "“Use the April figure here, not March”", "One-off", "The thread. Nothing to save." ] }, { "_key": "k92", "_type": "tableRow", "cells": [ "“Pipeline excludes closed-lost, always”", "Standing rule for one report", "The Task for the weekly summary" ] }, { "_key": "k93", "_type": "tableRow", "cells": [ "“Keep every summary to short bullets”", "Standing preference for one person", "Your personal skill" ] }, { "_key": "k94", "_type": "tableRow", "cells": [ "“We renamed EMEA to International”", "Standing fact for the workspace", "The shared team skill" ] }, { "_key": "k95", "_type": "tableRow", "cells": [ "“Always write in English in public channels”", "Workspace-wide instruction", "Workspace instructions in Settings" ] } ] } ``` Viktor’s docs separate these on purpose: a personal preference goes into a skill only you can see, a team fact into a shared skill everyone uses, and workspace instructions, set under Settings and Behavior, apply to Viktor for everyone and run up to 4,000 characters. The docs’ own example of a team fact is “We renamed EMEA to International.” In a chat window, the fifth explanation that pipeline excludes closed-lost is the same as the first. With a correction recorded in the same run, the fifth never happens. ## Severity tiers: correct, pause, or escalate ```json:object { "_key": "k108", "_type": "table", "rows": [ { "_key": "k103", "_type": "tableRow", "cells": [ "Error type", "Example", "Response" ] }, { "_key": "k104", "_type": "tableRow", "cells": [ "Cosmetic", "Wrong date format, a column out of order", "Correct in place. No rule unless it repeats." ] }, { "_key": "k105", "_type": "tableRow", "cells": [ "Factual", "A wrong figure in an internal report", "Run the four steps, then add a check to the Task: “state the source and record count for every figure before posting”." ] }, { "_key": "k106", "_type": "tableRow", "cells": [ "Tool or data", "A stale export, an expired connection, a field he cannot read", "Fix the connection first, then rerun the same day." ] }, { "_key": "k107", "_type": "tableRow", "cells": [ "Critical", "A wrong figure that reached a client, a record changed in the wrong account", "Pause the Task, tell the people affected, audit prior runs, then correct." ] } ] } ``` Viktor’s security page states that money moves, code pushes, and customer emails wait for your explicit approval in Slack, and that admins put high-risk tools behind human approval. The same page says admins can disconnect any integration, pause any user, or kill a running task in one click. [See how Viktor handles data and access →](https://viktor.com/security) ## When the same mistake keeps coming back The same wrong report after a correction is a pattern, with one of three causes. Check them in order. 1. **The rule was never saved where the work runs.** Ask him to show the current rules for that work. In Viktor, the docs point you to About you under Yours on the Skills page to see what he has recorded about you ([Skills](https://viktor.com/docs/skills)). 2. **Two people gave conflicting rules.** The section on multiple managers below covers the fix. 3. **The work is too large to run cleanly in one piece.** Some Tasks need splitting into smaller steps with a check between them. A stop rule, as a rule of thumb: after the third return of the same error with the rule saved, stop correcting and rescope. Split the Task, or hand that step back to a human and let him do the rest. If the run did not come back at all, or stopped halfway, that is a different problem, covered in [what to do when your AI employee gets stuck](https://viktor.com/blog/what-to-do-when-your-ai-employee-gets-stuck). ## Does the correction stick? Chat vs custom instructions vs an AI employee with memory ```json:object { "_key": "k143", "_type": "table", "rows": [ { "_key": "k139", "_type": "tableRow", "cells": [ "Setup", "Where the correction lives", "Survives the next session?" ] }, { "_key": "k140", "_type": "tableRow", "cells": [ "Plain chat with no memory feature", "The open conversation only", "No. A new thread starts from zero." ] }, { "_key": "k141", "_type": "tableRow", "cells": [ "Custom instructions in a settings box", "A text field you maintain by hand", "Yes, if you went and typed it. The same text loads for every conversation." ] }, { "_key": "k142", "_type": "tableRow", "cells": [ "An AI employee with persistent memory", "Recorded from the exchange, in the same run, scoped to you, the team, or the Task", "Yes. Applied next time without anyone re-entering it." ] } ] } ``` The third row is what an [AI employee](https://viktor.com/ai-employee) adds: the write-down is part of the work. Viktor’s security page adds that this memory is scoped to the workspace, encrypted at rest, never used to train models, and exportable or deletable on request. ## Multiple managers, one AI employee: avoiding conflicting corrections When three people manage one Viktor, two can disagree. His docs state that personality and workspace instructions apply to Viktor for everyone in the workspace, any workspace member can change them, and the advice when a teammate changes something is to agree on it as a team. Editing a shared skill on the Skills page is limited to workspace admins. Three rules keep order. 1. **One owner per Task.** The person who owns the output owns its standing rules; anyone can correct a one-off result in the thread. The post on [who should manage your AI employee](https://viktor.com/blog/who-should-manage-your-ai-employee) covers how to pick that person. 2. **Personal preferences stay personal.** “Short bullets for me” belongs in your own skill, not in a workspace instruction that changes his replies for everyone. 3. **Log changes to standing instructions in one place.** A pinned message in the channel where the Task posts, with the date, the person and the rule in one line, shows whether two rules now contradict each other. [See Viktor by use case →](https://viktor.com/use-case) Pricing is usage-based credits per workspace with no per-seat fee, and a new workspace starts with up to $100 in free credits and no credit card. Pricing checked October 2026. [Start with up to $100 in free credits and no card required →](https://viktor.com/pricing) ## FAQ ### How do you correct AI when it is wrong? Reply in the same thread: name the wrong value and the records behind it, state the missing constraint, and ask which source and filter were used. Check the redo against that source, then have the rule saved so it applies to the next run. ### Can an AI employee remember a correction, or do I repeat it every time? A chat with no memory needs the correction every session. Viktor’s docs state that a lasting correction shared mid-task is recorded in your personal skill in the same run and applied next time. Say “every week” or “from now on” so it is clearly a rule, not a one-time preference. ### Who is accountable when an AI employee’s error causes damage? The person who owns the Task and its output, which is why one owner per Task matters. Sensitive actions also wait for a human: per Viktor’s security page, money moves, code pushes, and customer emails wait for explicit approval in Slack. ### When should I just redo the work myself? For a genuine one-off that will never run again, redo it. For anything recurring, correct him: the four steps take a few minutes once, while hand-fixing costs the same minutes every run. If an error already reached a client, fix the artifact first, then run the loop. ### Does a correction for one Task apply to other Tasks? Only if you ask for that scope. A rule saved for the weekly summary applies to the weekly summary. State a broader preference, such as “exclude on-hold deals in every report”, as broad, so it is recorded as a preference about you rather than a rule for one Task.