What to Do When Your AI Employee Gets Stuck

Key Takeaways

• Stuck tasks have a short list of causes. A disconnected tool, an ambiguous brief, a task too big for one pass, or a genuine hiccup on the service side. Debug in that order.
• Ask what happened before assuming what happened. "What did you try and where did it stop?" gets you the failure point in one message, because an AI employee can narrate its own work.
• Expired connections are the most common culprit. Tools disconnect quietly when tokens expire or passwords change. Reconnecting takes a minute and fixes a whole category of "it stopped working."
• Big tasks fail in the middle; staged tasks don't. "Do the whole migration" is fragile. "Do the first ten, show me, then continue" is robust and catches format problems early.
• Correct the output, don't just retry it. A retry with the same brief reproduces the same result. Name what is wrong and the fix carries forward.
• Escalate with the thread, not a vibe. "It didn't work" is undebuggable. The task, the step it stopped at, and the error message make support fast.

Every employee gets stuck sometimes

A human colleague hits a locked spreadsheet, a missing permission, or an ambiguous request, and you find out at standup. An AI employee hits the same walls; the difference is that many teams treat the first stall as a verdict on the technology rather than as the normal friction of delegated work. The teams that get consistent value have a debugging habit instead: a fixed order of checks that resolves the majority of stalls in a couple of minutes.

Here is that order, from most common cause to least.

Step 1: ask him what happened

Before touching anything, ask the question you would ask a person:

@Viktor that task looks stalled. Walk me through what you tried,
step by step, and tell me exactly where it stopped and what the
error or blocker was.

This is the single highest-value troubleshooting move, because an AI employee can narrate his own work. The answer usually points directly at the cause: a tool that would not respond, data that did not match what the brief assumed, or a genuine ambiguity where he made a judgment call you would not have made. Everything below is just the follow-up to what this answer tells you.

Step 2: check the tool connection

The most common cause of a working task that suddenly stops working is not the task. It is the connection behind it. Integrations disconnect quietly: a password change, an expired token, a revoked session on the tool's side, a two-factor reset. The task did not get worse; the door got locked.

The signature is a task that ran fine before now failing at the same step, or Viktor reporting that a specific tool will not respond or returns an authorization error. The fix is almost always to reconnect that one integration, the same authorization flow as when you first connected it, taking about a minute. The adjacent case is worth knowing too: sometimes the connection itself is healthy, but the account you connected with simply lacks access to the specific folder, board, or dataset the task needs, and the fix lives in that tool's own sharing settings.

One habit that prevents repeat surprises: when a tool's password or permissions change on your side, reconnect proactively instead of waiting for Monday's report to fail.

Step 3: check the brief for a hidden fork

If the tools are fine and the output is wrong rather than missing, the brief usually contained a fork you did not notice you were leaving open. "Pull last month's numbers" ran on calendar month while you meant the last 30 days. "Update the tracker" found two trackers. An AI employee resolves ambiguity with a judgment call, like a new hire would, and about half of "it did the wrong thing" reports are really "it chose the other branch of my ambiguous sentence."

The fix is a correction, not a retry: name the branch you meant. "Last month means the last 30 days, and the tracker is the one pinned in #ops. Redo it and remember both." A plain retry of the same words reproduces the same judgment call; a correction changes this run and, once remembered, every future one.

Step 4: stage tasks that are too big to fail gracefully

Some stalls are size problems. "Migrate all 800 records", "summarize the entire year of tickets", "update every page" are tasks where a single problem in the middle can stall the whole run, and where you find out about a formatting misunderstanding only after everything is done.

The robust pattern is staging:

@Viktor migrate the first 10 records from the old sheet to the new CRM
format and show me the result before continuing. If those look right
to me, do the rest in batches and report progress after each batch.

Staging converts one fragile giant task into a checkpoint plus a routine. It catches format problems when they cost ten records instead of eight hundred, and batch-by-batch progress reports mean a mid-run problem loses one batch, not the run.

Step 5: if it's none of the above, it might genuinely be us

Sometimes every check above comes back clean and the task still will not run: responses are unusually slow, or a step fails with an error that has nothing to do with your tools or your brief. Services have bad moments, and pretending otherwise would be dishonest. When that is the situation, the productive move is a good escalation rather than another dozen retries.

A useful report contains three things: what the task was, the step where it stopped, and the exact error or behavior observed. That is also why step 1 matters; the narration you asked for at the start is precisely the content support needs. Send it through your usual support channel, and rerun the task once things clear rather than layering retries on top of a known-bad window.

The debugging order at a glance

Working down the table in order matters, because the top rows are both the most common and the fastest to check.

Frequently Asked Questions

How do I know whether the problem is the tool connection or the task?

Ask for the narration first. If a specific integration would not respond or returned an authorization error, it is the connection; reconnect it. If the tools responded and the result just is not what you wanted, it is the brief; correct it.

Why did a task that ran for weeks suddenly break?

Almost always a quietly expired or revoked connection, often after a password change or a security review on the tool's side. Reconnect the integration. If it recurs for the same tool, check whether that tool enforces short session lifetimes for connected apps.

Should I just retry a failed task?

Once, yes, especially if the narration suggests a transient hiccup. More than once, no. Repeated identical retries reproduce the same failure; change something first, whether the connection, the brief, or the task size.

How do I stop one bad record from killing a big batch job?

Say what to do with exceptions in the brief: "if a record is missing a required field, skip it and list skipped records at the end." Exception handling you can predict belongs in the brief; staging catches the ones you could not predict.

What should I include when I report a problem to support?

The task you asked for, the step where it stopped, and the exact error message or behavior. Asking your AI employee to narrate what he tried produces exactly this, ready to paste.

Is an AI employee supposed to ask questions instead of getting stuck?

For genuine ambiguity, yes, and a good brief invites it: "ask me before making assumptions about the data" is a standing rule that trades a little back-and-forth for a lot of rework. For a locked door like an expired connection, he can tell you what is blocked, but reconnecting needs you.

Stuck is a state, not a verdict

The teams that quit on AI employees and the teams that run entire workflows on them see the same stalls. The difference is the response: one group reads a stall as "this doesn't work," the other spends two minutes on the debugging order and moves on. Ask what happened, check the connection, close the fork in the brief, stage the big jobs, and escalate the rest with real detail.

Add Viktor to your workspace and put the debugging order to the test

Related reading:

• How to Write a Brief Your AI Employee Can Run With
• Replace Weekly Reporting With AI
• Replace Meetings With Async Reports