Your first AI agent workflow: turn a folder of notes into a reviewable brief

Start with a small task whose result you can inspect. A folder of project notes is a useful first example: the inputs are bounded, the output is a document, and you can check whether each conclusion follows from a source. This guide uses a Markdown brief so the result does not depend on a particular office plugin.

Prepare a workspace with a clear boundary

Create a project directory with a sources folder containing a few notes you are allowed to use and an output folder for the result. For the first run, use copies and leave unrelated material outside the workspace. In GetRun Harness, select this directory, start a new conversation, and confirm the model, run mode, and file permissions beneath the input.

The workspace is the project directory the agent can access. A desktop task may read files, run tools, and create outputs; review the permissions that the current mode actually grants. You do not need to enable browser or computer automation to try a task that only uses local text files.

Inputs: a few readable project notes with stable filenames.
Output: one brief in output/brief.md, with a source filename for every factual claim.
Boundary: preserve sources; ask before using an external service or publishing anything.

Describe the deliverable before the procedure

Say who will read the result, what decision it should support, and how it will be checked. “Summarize this folder” leaves the agent to guess the scope. A request for a one-page decision brief with open questions, source references, and a separate list of missing evidence makes review much easier.

Specify how contradictions should be handled. If two notes disagree on a deadline, the brief should show the disagreement and cite both files. It should not silently choose a date or invent a compromise. Keep unknown values explicitly marked as unknown.

Watch the first run and correct the scope

GetRun Harness shows tool calls and results while a task runs, and you can stop the task. Check the first file reads before waiting for the finished document. If the agent opens the wrong directory or starts a different task, stop and restate the input boundary.

When an action asks for confirmation, check its target and effect. A file read, a local edit, and an external upload are different actions. If you later add browser or computer automation, enable the required setting deliberately and follow the displayed permission prompts.

Review the artifact, then reuse the task

Open the generated brief and compare a sample of its claims with the original notes. Check names, quantities, dates, and quoted commitments. A polished paragraph is not evidence that those details are correct. Also confirm that the source files were preserved and the result was written to the requested location.

For a second run, change only one part of the request, such as the audience or the output length. Keep a small checklist of mistakes from the first run and use it for review. Only turn the task into a repeated workflow after the output is useful and the necessary permissions are understood.

Every decision-relevant claim has a source reference.
Missing evidence and conflicting statements remain visible.
The brief is usable by its intended reader without access to the chat.
No output is published or sent solely because it has been generated.

A first task you can adapt

Read the Markdown files in sources/. Create output/brief.md for a project handover. Include the objective, current decisions, open questions, and next actions. Cite source filenames beside factual claims. If sources disagree, show both statements. Do not modify sources, browse the web, upload files, or publish the result. First list the files you intend to use.