In this article
When I try an AI workflow, I want to learn whether it helps me finish something useful. A polished first response is encouraging. The experiment becomes more interesting when I can inspect the result and see what it took to get there.
This is a practical follow-on to how I work with AI agents. We will use two concepts, inference and the agent harness, to design a small trial you can run with a task you already have.
Two terms that help you understand the work
Inference is the model generating an output from its current input. The output might be a draft or a request to use a tool. The harness is the software managing the surrounding session: context, permitted tools, progress, and the repeated calls needed to continue. Cloudflare defines inference, and Anthropic explains how a model and harness work together.
You might see several rounds in one task. The model proposes a step; an available tool does the permitted operation; the result comes back; the model uses that information to propose the next step. Keeping a record of those steps helps you find where the workflow needs improvement.
Choose a task small enough to review
Start with an existing need: turn approved meeting notes into an action brief, prepare one service-page section, or assemble a short workshop promotion packet. Avoid choosing a large business transformation for your first trial. A compact task gives you a realistic chance to inspect every important claim and interaction.
For this exercise, imagine preparing a workshop promotion packet containing a page outline, three short promotional messages, and a list of missing information. This is a hypothetical teaching example. It does not assume a workshop is scheduled or that any messages will be sent.
Use a permitted sample brief with the audience, topic, confirmed logistics, and the intended next action. If a fact is unknown, label it unknown. Keep private attendee information out of a practice task that does not need it.
Define the result before opening the chat
Write the acceptance criteria in ordinary language. For our promotion packet: the three messages must match the outline; every logistical fact must match the brief; the intended next action must be clear; and missing information must remain visible.
If you want files, specify the files. If you want a page preview, specify that preview and the interactions you expect to check. If your current assistant cannot create that output, use the exercise to identify the missing capability before promising a bigger result.
| Question | Write your answer |
|---|---|
| What will exist at the end? | A named document, file, preview, or other inspectable result. |
| What information may it use? | The brief, approved examples, and named sources. |
| What may it do? | The specific drafting, file, or test actions allowed. |
| What requires a decision? | Missing facts, conflicting requirements, or a release action. |
| What counts as acceptable? | A short list of observable requirements. |
Run the task and watch the transitions
Use your existing AI environment and ask it to explain which relevant tools it can actually access. Then give it the brief below. Save the result where you can find it again.
Prepare [deliverable] for [audience] from [approved inputs]. The result must meet [acceptance criteria]. Use [permitted tools and actions]. Identify missing or contradictory facts before relying on them. Return the finished output, the source references used, the checks performed, and anything unresolved. Stop before [actions requiring a decision].
As the task runs, record only the transitions that matter: the brief was understood, a tool was requested, the operation succeeded or failed, the result was reviewed, and a revision was made. You do not need to transcribe every token.
If the assistant only produces text, that can still be a useful drafting experiment. If it can work with files and previews, include those outputs in your review. Judge the task against the capabilities actually available and the outcome you requested.
Count the effort around the draft
Keep setup effort separate from each run, then include both when you assess the first attempt. Record your preparation, prompting, review, and correction time. Record model or tool cost when available. Also record elapsed time so you know how long you waited for the result.
Here is a fictional example: a familiar manual task takes 35 minutes of hands-on work. The AI version takes 10 minutes to prepare, 12 minutes to review, and 8 minutes to repair: 30 minutes of recurring hands-on effort. If setup took another 20 minutes, the first attempt required 50 minutes. That first trial did not save time, even if the initial draft appeared quickly.
Use your own observations for subsequent runs. Compare work of similar scope and quality, include failed attempts, and avoid counting overlapping waiting and hands-on time twice. One successful attempt gives you a useful observation; it does not establish an income claim or a universal efficiency gain.
The workflow run log gives you a place to record attempts. For more detail, read how to measure AI time savings.
Repeat once with an intentionally incomplete brief
Remove a required fact from your practice brief. In the workshop example, leave out the date. Observe whether the agent identifies the gap, leaves a clear placeholder, or invents an answer.
Then check the actual output. A missing fact reported in the chat may still be hidden by a confident sentence in the document. The review should cover the deliverable itself.
For a task involving tools, use an authorized test to see what happens when one step cannot finish. A good handoff identifies the failed step and the completed work that can still be reused. Do not create a failure in a live customer process merely to run this exercise.
Choose keep, change, or stop
Keep the process when it produces an acceptable result with manageable effort. Save the brief, permitted sources, review criteria, and location of the output.
Change the specific part causing rework. The model may need clearer facts. The harness may need access to a file or a reliable way to preserve state. The reviewer may need a more concrete acceptance criterion. Add one improvement you can observe.
Stop when the task is too ambiguous, the required access is unavailable, or checking the output costs more than the result is worth. That is useful information from an experiment.
Describe. Create. Deliver. Repeat.
Describe one useful outcome. Create with the information and tools the task needs. Deliver something you can inspect. Repeat the parts that earn their place in your work.
If you are building a product, read the product-building guide to harnesses and inference. If you deliver work for clients, explore the campaign workflow and delivery checklist. Your next experiment can stay small while your understanding grows.
Published November 5, 2026. Examples, timing figures, and worksheets are illustrative. They are not claims about Ashley's results, client outcomes, or guaranteed savings.
Your next move
Choose one small deliverable, copy the experiment brief, and record preparation, review, corrections, and the evidence that the result worked. Decide what to keep, change, or stop.
