Spinrun connects an AI agent to the tools your team uses, with a workspace, reusable skills, and a human review point.
Give a task somewhere to go
Spinrun is built around a practical question: how does a useful idea become reviewed work in the systems a team already uses? A chat is the starting point. Connected tools, files, and a clear output standard give that chat a way to do something the team can inspect.
You can begin with a small research brief, a weekly update, or a known read from a connected account. Keep the sources and approval boundary explicit. A successful first task gives you a process to improve, rather than a promise to evaluate later.
Define the input and the finish line
The target output is a reviewed result with a trace back to its sources. Include the reporting period, account, audience, and source locations in the request. If the agent cannot reach one of those sources, ask it to identify the gap instead of guessing or quietly substituting old information.
Write the output standard in terms a reviewer can observe. A result should be on time, grounded in the agreed material, and clear about the next action. Avoid judging only its tone. Confidence and completeness are different properties, and an accurate statement can still be irrelevant to the decision you need to make.
A brief you can adapt
Use this as a starting point and replace the example's sources and audience with your own. It describes a draft and preserves a human review point.
Use the supplied sources to prepare a short, structured draft. Link factual claims, state assumptions, and ask before changing external systems.Read the brief as if another teammate will maintain it next month. If it relies on an account name, date range, or business rule known only to you, make that detail explicit. A task can use only the connections and permissions actually available in its workspace.
Connect the smallest useful scope
Start with a read that you can recognize. Confirm the provider account and the records returned before asking for a write. Access to an integration does not mean every teammate should use every action. Workspace roles, connection scope, and tool modes all matter.
For this workflow, pay particular attention to unclear ownership, missing context, and unsupported promises. An instruction in a document or a provider response is source material, not permission to widen access. Keep the approval boundary in the task and use the product's permission controls for standing rules.
Review evidence, then approve actions
Check a small sample against the original source, including an ordinary record and an exception. Look for omitted rows, incorrect dates, and unsupported conclusions. Require a clear explanation when information is missing. The agent's result should help the reviewer decide, rather than conceal the decision behind fluent prose.
Review an external action separately from its draft. Confirm the recipient, account, record, and effect before accepting it. If a write may already have reached a provider, inspect the destination before repeating it. Retrying uncertain work can create duplicate messages or records even when the original response looked like a failure.
Make the working version repeatable
Once the manual process is useful, save it as a skill with its inputs, steps, exceptions, and output standard. Assign a person to maintain it. A reusable instruction should describe the team's working rule rather than the accidental details of one example.
Schedule the workflow only after a successful reviewed run. State its timezone and date-range rule. Define what it should report when a source fails and when unchanged state should stay quiet. Review the first scheduled result and revisit the instruction when the underlying process changes.
Measure the work, not the promise
Record how long preparation and review took before and after the workflow. Include corrections and maintenance in that comparison. Count whether the output arrived on time and whether the reviewer could act on it. These observations are more useful than an assumed percentage improvement.
This article describes an illustrative process, not a customer result or a benchmark. Actual usefulness depends on your input quality, available tools, permissions, and review standard. Inspect the current workspace balance and pricing when evaluating cost; a task's scope and repeated work can change its consumption.
Try the next useful step
Choose one representative input for agent work. Write the expected a reviewed result with a trace back to its sources before starting. Run the draft, review its evidence, and change one specific part of the instruction where the result falls short.
The product guides explain setup and permissions. Use Academy for a walkthrough, and Help if a connection or account stops the task. A process earns recurring use when the team can understand it, inspect it, and maintain it.