AfterDesk
EN
Apply

Working with AI

When the tool acts, not just answers

More tools now do things instead of describing them: they click, send, rename and overwrite. This course teaches the discipline that keeps an acting tool from costing you a night of work: write scope, dry runs, checkpoints, action logs, a limited first run, and a recovery plan written in advance. Finish it and you will never hand a tool the whole file again.

8
lessons
~61
minutes
12
exam questions

Free · No paid tier · No certificate fee

After this course

Everything, and what is in it.

A wrong action cannot be discarded

~7 min

An answer is only a draft

When a tool answers you, nothing has happened yet. It produced text on a screen, and you are still the only person who has seen it. You can read it, disagree with it, delete it, and start again, and the world outside your window is unchanged. That is the tool most of these courses have taught you to use: a thing that proposes, while you dispose. Its worst failure is a confident paragraph that is wrong, and the cost of that failure is the two minutes you spend checking it against the source. A bad answer is caught by reading. Nothing else is required.

An action is already a fact

An acting tool is different in kind, not in degree. It clicks the button, sends the message, renames the file, overwrites the cell, archives the thread. By the time you read what it did, the doing is finished. Forty-five suppliers received an email that named the wrong project. A column of 1,200 phone numbers was overwritten with a reformatted version that dropped the leading zero. You cannot un-send, and the reformatted column no longer holds the original values to compare against. The mistake is not larger because the tool is worse. It is larger because your review arrived after the event instead of before it. That single change of order is the whole subject of this course.

You are already using acting tools

You do not need to think of yourself as automating anything for this to apply. A browser tool that fills a form and presses submit is acting. An assistant that has been connected to a mailbox and can archive, label or reply is acting. An automation that watches a folder and, at one step, asks a model what to do with each file is acting. A spreadsheet add-on that offers to tidy 4,000 rows for you is acting. Even a bulk rename utility with no model in it at all is acting, and it fails in exactly the same way. The question is never whether the tool is intelligent. The question is whether it can change something you would have to repair.

Ask one question before you connect

Before you let any tool act on an AfterDesk task, ask one question and answer it out loud: what can this thing change, and who sees the change first? If the answer is that it can only change a copy on your own machine, and you see the result before anyone else, you are in safe territory. If the answer involves a live inbox, a shared drive, a published page, or the client's own file, you have left safe territory and the rest of this course applies in full. Most workers skip this question because the tool made the offer sound small. Read the permissions screen instead of the marketing sentence. The permissions screen is the honest one.

Remember

  • A wrong answer costs two minutes of reading. A wrong action costs a repair.
  • Acting tools click, send, rename and overwrite. The doing finishes before your review.
  • Intelligence is not the test. The test is whether it changes something you must repair.
  • Ask what the tool can change, and who sees the change first.

Read everything, write nothing

~8 min

Reading is cheap, writing is expensive

Separate what a tool reads from what a tool writes, and treat the two as different permissions with different prices. Reading is almost free in repair terms: a tool that scans 900 emails and tells you which 40 mention a refund has changed nothing, and if its list is wrong you simply discard the list. Writing is where money moves. The same tool, given permission to label or archive, can bury 40 threads the client needed on Monday. When you set a tool up, the read side can be generous and the write side must be mean. Give it plenty to look at. Give it almost nothing to touch. That asymmetry is where the cost actually sits.

The default write scope is nothing

Start every configuration at zero writes and add back only what the task requires, one permission at a time, saying out loud what each one buys you. A tool asking for full access to a drive so that it can read three files is asking for more than the job needs. If the interface offers a read-only mode, take it, run the whole job in that mode, and see how much of the work you can actually finish yourself from what it found. Often the answer is all of it: the tool finds the 40 rows, and you edit the 40 rows by hand in four minutes. That is not a failure of automation. That is automation doing the expensive half and leaving you the safe half.

Sending is a write you cannot recall

People classify writes as edits to files and forget the loudest write of all. A message leaving an account is a write into somebody else's inbox, and it is the one write no undo button reaches. The same is true of a calendar invitation, a form submission, a comment posted on a shared document, and a status change that triggers a notification to six people. Ask of every step: does this produce something a human being outside this task will see? If yes, that step never runs unattended, ever, on any task. On AfterDesk the point is sharper still, because you do not contact clients at all. A tool acting in your name does not get a permission you do not have.

Write to a new place, not over the old

When a write is genuinely needed, aim it at somewhere new. A new column beside the old one, a new sheet, a new folder, a new file with a suffix: these are additive writes, and an additive write is recoverable because the original is still sitting there for comparison. Overwriting in place is the destructive one, and it is destructive even when the result is correct, because you have lost the ability to prove it is correct. Configure the tool to output to a separate file whenever the option exists. If the option does not exist, make the copy yourself first and point the tool at the copy. Twenty seconds of setup buys you the only evidence you will have.

Reading is cheap, but not with client data

Cheap refers to repair cost, not to permission. Client data does not go into third-party or consumer tools at all, read-only or not: not a chat assistant you signed up for, not an online transcription site, not a document summariser, not an image tool. The confidentiality promise we made the client covers looking, not only changing. Two things do open the door. A brief can grant scoped, written permission to use a named tool for a named purpose. The assistant inside AfterDesk is sanctioned on a task you have claimed: it cannot see the task record, the client, the files or the price, and what you type into it is scrubbed of personal detail before storage. Silence in a brief is still not permission.

Remember

  • Read scope can be generous. Write scope must be mean.
  • Start at zero writes and add back one permission at a time.
  • Sending is a write into another person's inbox. No undo reaches it.
  • Write to a new column, sheet or file. Never overwrite in place.
  • Client data stays out of outside tools, reading included. Silence is not permission.

Make the tool show its plan

~8 min

Ask what it would do

Before any run that writes, get the tool to produce the list of what it intends to touch, without touching it. Many tools have this built in and call it a preview, a test run, a simulation or a dry run. Where it does not exist, you can usually build it: point the write at a scratch file instead of the real one, or set the step to output the target names into a column rather than acting on them. The list is the point. A tool that cannot tell you what it plans to do is a tool you cannot supervise, and on a claimed task with a deadline, an unsupervised run is a coin flip you are paying for.

Check the count before the contents

The first thing to read in a dry run list is its length, and you read it against a number you worked out yourself beforehand. You believed roughly 60 invoices in the folder were unpaid. The preview says 214. Stop. Something in the filter is wider than you meant, and if you had run it you would have restamped 154 paid invoices at three in the morning. The reverse is just as informative: a preview of 3 when you expected 60 means the filter is looking at the wrong field, or the dates are text and not dates. Predict the number, then compare. A count you cannot explain is a stop, not a curiosity.

Read the edges, not the middle

Nobody reads 214 lines properly at 2am, so read the parts where errors live. Read the first five entries: they show whether the tool started where you thought. Read the last five: they show whether it stopped where you thought, or ran off the end of the data into empty rows. Then hunt for the entries that should not be there at all, which is a different mental act from checking that the right ones are present. Sort the list and look for the odd one: the file with a different extension, the row with a blank name, the address that is internal rather than external. Presence is easy to verify. Wrong presence is what actually costs you.

Verify five by hand

Take five entries from the preview at random, not the first five, and check them yourself against the source. Open the invoice and confirm it really is unpaid. Open the two rows the tool says are duplicates and confirm they are the same customer and not two brothers at one address. Five hand checks take four minutes and they test the thing a preview cannot test: whether the tool's idea of the criterion matches yours. If one of the five is wrong, the run is not eight percent wrong, it is wrong in a way you do not yet understand, and the correct next step is to find the pattern, not to fix the one.

Ask the assistant how, not what

If you do not know how to force a preview out of a particular tool, that is a method question, and the assistant inside AfterDesk on a task you have claimed is the right place for it. Describe the mechanism, not the material: how do I get a bulk rename utility to output a list of proposed names instead of renaming, is a good question. The client, the file names, the company and the price stay out of it. That assistant sees only what you type, and what you type is scrubbed of personal detail before it is stored, which is exactly why you keep the client out of the sentence in the first place.

Remember

  • No preview, no run. Build one if the tool does not offer it.
  • Predict the count first. A number you cannot explain is a stop.
  • Read the first five, the last five, and anything that should not be listed.
  • Hand check five random entries against the source before the tool writes.
  • Method questions go to the in-product assistant. The client stays out of the sentence.

Put checkpoints where failure is cheap

~7 min

A chain fails silently in the middle

Three steps chained together feel like one action, and that is the trap. Step one pulls 300 rows from a sheet. Step two asks a model to classify each row. Step three writes the classification back and moves the file. If step two starts guessing at row 90 because a column arrived empty, steps one and three both report success, and the failure is buried inside a green result. Chains do not warn you. They finish. The only thing that turns a silent failure into a caught one is a place in the chain where a human being looks before the next step runs, and the value of that place depends entirely on where you put it.

Checkpoint before the first irreversible step

The rule is short: the checkpoint goes immediately before the first step that cannot be undone, and as early as possible after the step most likely to be wrong. Those two pulls usually agree. Judgment steps are the ones that get things wrong, and sending, publishing and overwriting are the ones that cannot be undone, so the gap between them is where your eyes belong. Concretely: let the tool draft 45 supplier emails into a drafts folder and stop. Let it produce the renamed list and stop. Let it write classifications into a new column and stop. You then spend six minutes reading, and press the last button yourself.

A checkpoint you always approve is decoration

A checkpoint is only real if you have a criterion that could fail it. If you look at the screen, feel that it seems fine, and click continue every time, you have built a delay, not a control. Decide in advance what would make you stop: more than two of my twenty samples are wrong, any row targets a different company, the count differs from my estimate by more than ten percent, any output is empty. Write those numbers down before the run, because after the run, with the deadline close, every result looks acceptable. The purpose of a written threshold is to protect the tired version of you from the confident version of you.

Batch the work so stopping is possible

You cannot check what has already finished, so shape the run to give you places to stand. A job of 400 files split into batches of 50 gives you eight natural checkpoints and costs perhaps ten extra minutes. A job of 400 run in one pass gives you one outcome and no choices. Batching also changes what a failure costs: a bad rule caught after batch one damages 50 files, and you still hold 350 clean ones. Do not batch everything out of habit, because on a 30 row task the overhead is silly. Batch when the run is long, when the rule is new, or when the target is the client's own file rather than your copy.

Remember

  • Chains report success while failing in the middle. They finish, they do not warn.
  • Put the checkpoint after the judgment step and before the irreversible one.
  • Write the stop threshold before the run. Deadline pressure makes everything look fine.
  • Batch long or new runs. One bad rule then damages fifty files, not four hundred.

Read the log, not the summary

~8 min

The summary is a claim

When a run finishes, the tool tells you something short and encouraging: completed, 214 items processed, done. That sentence is written by the same thing that did the work, and it reports intention as if it were outcome. The log is different. The log is the list of individual operations with times, targets and results, and it is the only place where a run tells you the truth about itself. Find it before you need it: most tools keep it under history, activity, runs or executions, and finding it in a panic after something went wrong is much harder than finding it while everything is calm. Read the log every time, even when nothing seems wrong.

Three questions the log answers

Read a log for three things, in this order. What was touched: the actual targets, by name, not the count. In what order: because order tells you where a run turned, and an operation at 03:14 that follows a different pattern from the ones at 03:12 is the moment something changed. And what the result of each was: succeeded, skipped, failed, retried. Skipped is the word people miss. A skipped item is not a done item, and a log of 214 lines where 19 say skipped is a delivery with 19 holes in it. Write those three answers into your own notes as you read. You will need them for the delivery note anyway.

Partial runs look like complete ones

The most expensive log to misread is the one from a run that stopped early. A connection dropped, a limit was hit, the laptop slept at 4am, and the tool processed 138 of 214 and then simply ended. The folder looks busy. The sheet looks changed. Nothing announces the gap. So verify completion by arithmetic instead of by feel: count the lines in the log, count the items you expected, and confirm the last item in the log is the last item in your source. If those numbers do not match, you have a partial run. A partial run is more dangerous than a failed one, because a failed one is obvious.

Never restart a partial run blindly

The instinct after a partial run is to press the button again, and that instinct doubles the damage. Running again from the top can process the first 138 items a second time, which means 138 duplicate rows, 138 second messages, or 138 files renamed twice into names that no longer match anything. Before restarting, use the log to find the exact last item that succeeded, then restrict the second run to what comes after it. If the tool cannot be restricted, finish the remainder by hand, even if that means 76 rows at four in the morning. Slow and correct is a delivery. Fast and doubled is a correction, and corrections cost more than the hour you saved.

Keep the log until the window closes

Save the log, or a screenshot of it, until the task has passed review and the dispute window has closed. It is small, it costs nothing to keep, and it is the only document that can answer a question asked three days later: did the rename touch the archive folder, or not? Keep it somewhere task-related and delete it with everything else when the task is finally closed. Do not paste it into anything outside the task, because a log is full of file names, addresses and account details, and it is client data like any other file. If the operator asks what happened, you quote from it. You do not forward it.

Remember

  • The summary reports intention. The log reports outcome. Read the log.
  • Ask the log what was touched, in what order, with what result.
  • Skipped is not done. Nineteen skips is nineteen holes in your delivery.
  • Confirm completion by arithmetic. A partial run looks exactly like a finished one.
  • Never restart from the top. Restrict the second run to what remains.

Work on a copy, then a subset

~8 min

The first run never touches everything

Blast radius is the amount of the world a run can damage, and you control it with two dials: what the run points at, and how much of it. Both start small. The first run of any new rule points at a copy, and covers a subset. Twenty rows out of 1,200. Five files out of 400. One folder out of nine. Then you inspect the twenty rows by hand, all of them, which takes four minutes and tells you more than an hour of thinking about the configuration would. Only after the small run is clean do you widen, and you widen in steps. Nobody has ever regretted a first run that was too small.

Make the copy before the tool opens

Copy first, connect second. The moment a tool has access to a live file, the window for making a clean copy has closed, because you can no longer be sure what you are copying. So duplicate the source file, give the duplicate a name you cannot confuse at 3am, something like invoices_WORKING_v1 rather than invoices copy, and keep the original untouched in its own folder for the whole task. This is the same rule these courses teach for a destructive formula or a find and replace, applied to a tool that does the destroying for you. The original file stays attached to the claimed task as well, which means a clean copy is always one download away.

Some targets cannot be copied

Copies work for files. They do not exist for a live mailbox, a shared calendar, a folder other people are working in tonight, a published page, or a records system the client uses while you sleep. For those, the only dial you have left is size, and the discipline changes shape: you take the smallest possible slice, you do it during a window where nobody else is likely working, and you check the result immediately rather than at the end. If a tool wants to act across a whole live inbox in one pass, the correct answer is that this is not a job for an unattended run. Do it in batches you watch, or do it by hand.

Widen in steps you can survive

After a clean run of twenty, do not jump to 1,200. Go to a hundred, then to the rest, and inspect between each widening, because a rule can be perfect on twenty rows and break on the hundred and third where a field is empty. Each step should be a size whose failure you could repair inside the time you have left. That is the real test: if this batch goes wrong, can I fix it by hand before the deadline? If the answer is no, the batch is too big, regardless of how confident you feel after the last one. Confidence grows faster than correctness, which is why the sizes are decided by arithmetic and not by mood.

Remember

  • Two dials control damage: what the run points at, and how much.
  • Copy the file before the tool touches it. Afterwards a clean copy is uncertain.
  • Mailboxes, calendars and live systems have no copy. Slice small and watch.
  • Widen in steps whose failure you could repair by hand before the deadline.

Write the undo before you run

~8 min

Undo is a plan, not a button

Write the recovery plan before the run, in three or four sentences, in the same notes where you keep your working record. Not the idea of a recovery plan: the actual steps, in order, that return the world to how it was. If a plan cannot be written in three sentences, it is not a plan, it is a hope. The value of writing it first is that you write it while calm, with time in hand, before anything has gone wrong. At 4am with 76 broken rows and two hours to the deadline, you will not invent a good recovery. You will follow one or improvise a worse one.

Four questions the plan answers

Answer four questions in writing. Where is the clean original, by exact file name and location? What exactly would I do to restore it, step by step, and how long does that take? How would I even notice that this went wrong, and what would I look at? And what does the tool itself offer: a version history, a trash folder with a retention period, an undo that lasts thirty seconds? Answering the last one before the run matters, because a version history you discover afterwards is luck. A version history you confirmed beforehand is a plan. Four sentences. Two minutes. It is the cheapest insurance in this entire course.

Some things have no undo

Be honest about the cases where recovery does not exist. A sent message is gone. A submitted form is gone. A deleted item past its retention period is gone. An overwritten cell in a file with no version history is gone, and so is the original value you would need to prove what it was. A notification that fired has already been seen. For these, there is no recovery plan to write, and the absence of one is itself the decision: a step with no undo does not run unattended, does not run on a first pass, and often does not run at all, because your hand on the button is the only control that exists.

Test the undo on the copy

A plan you have never executed is still a guess, so try it once while nothing is at stake. Make the copy, break it deliberately, and restore it using your own written steps. You will learn two things in five minutes: whether the steps actually work, and how long they truly take. Workers routinely estimate a fifteen minute recovery for something that takes an hour, and that error is what turns a manageable accident into a missed deadline. If the restore takes longer than the time you have left after a failure, the run is too big, and you shrink it. The plan is not a document. It is a measurement.

When it goes wrong, stop first

The first move after discovering damage is to stop the tool and stop yourself. Do not run a correcting pass, do not try a clever reverse operation, do not delete the evidence of what happened. Disconnect or pause the automation so nothing continues while you think. Then read the log and write down what was actually affected, by name and count, because that list is what your recovery and your delivery note both depend on. Then restore from your original. Then redo the work at whatever pace the remaining time allows, by hand if necessary. Panic repairs are the reason a five minute problem becomes a rejected delivery. Stop, read, restore, redo.

Remember

  • Write the undo in three sentences before the run, while you are calm.
  • Name the clean original, the restore steps, the alarm, and the tool's own history.
  • Sent, submitted and overwritten without history: no undo exists. Never run those unattended.
  • Test the restore once on a copy. Measure the time, do not estimate it.
  • After damage: stop, read the log, restore, redo. Never a panic correcting pass.

Tell the operator what ran

~7 min

Disclosure is part of the delivery

An operator reviewing your work against a written standard needs to know how it was produced, because that changes what they check. A file a person edited row by row and a file a script rewrote in one pass carry different risks: the first fails in scattered places, the second fails in the same way 1,200 times. Saying that an automated step ran is not an admission of laziness, and nobody here thinks less of a worker who automates well. What damages you is a reviewer discovering it themselves, from a pattern in the output you did not mention. Disclosed automation is a method. Undisclosed automation is a surprise, and surprises fail review.

Four lines the operator can act on

Keep the disclosure to four lines. What ran, in plain words: a rename step, a classification step, a deduplication formula. What it touched, with numbers: 1,182 rows in the working copy, not the original file. What you verified afterwards, and how: twenty randomly chosen rows checked against the source, plus every row the log marked skipped. And what remains uncertain, if anything: nineteen rows the step could not classify, left blank and flagged on a second tab. That is a delivery note an operator can review in ninety seconds. Vague reassurance costs them ten minutes and costs you their patience, which is a currency you spend more slowly than you think.

Say what you checked, not that you checked

There is a large difference between I verified the output and I opened twenty rows chosen at random and compared each against the source file. The first is a feeling. The second is a method the operator can trust or repeat. Name the sample size, name how you picked it, name what you compared against, and name what you found, including nothing. Reviewed carefully is the weakest sentence in any delivery note, because every worker writes it, including the ones who did not. Specific verification is also what protects you when something slips through later: a note recording exactly what you checked shows the gap was outside your stated method, not inside it.

Name the tool and the permission

If the brief granted scoped, written permission to use a named external tool for a named purpose, say in your note that you used it, for that purpose only, and nothing beyond it. If no such permission was granted, then no client data went outside the task, and your note should be able to say so plainly: all processing was local to my machine. That single sentence answers the question an operator would otherwise have to ask. The assistant inside AfterDesk sits outside this entirely, since it never receives the client's files or identity, but you can still mention that you checked a method with it if that explains a choice you made.

Report the accident before it is found

If an automated step went wrong and you repaired it, say so, with the same four lines: what ran, what it touched, what you did to fix it, and what you verified afterwards. This feels like handing the operator a reason to reject you. It is the opposite. A worker who reports a caught mistake with a count and a fix is a worker whose clean deliveries can be believed, and that is the whole basis of the record you are building here. The alternative is the same mistake found at review, or worse, by the client, with your note claiming everything was fine. One of those costs you a correction. The other costs you the work.

Remember

  • Disclosed automation is a method. Undisclosed automation is a surprise that fails review.
  • Four lines: what ran, what it touched, what you verified, what stays uncertain.
  • Reviewed carefully means nothing. Name the sample, the source and the finding.
  • Say all processing was local, or name the tool the brief permitted.
  • Report a caught and repaired mistake. It is what makes clean work believable.

Sit the exam

The courses are free. The work is real.

Twelve scenario questions. Pass at ten. Three attempts a day. The bar is the point.

No paid tier. No certificate fee. No upsell. Not now, not later.

Create a free account

You can start the first course tonight.

The curriculum

Everything, and what is in it.