Switch from win.sh to Task Machine
A practical guide to moving from win.sh to Task Machine: turn autonomous loops into explicit workflows and route every judgment call to one inbox.
Prefer the side-by-side comparison?win.sh and Task Machine share important foundations: accounts remain yours, neither product takes a revenue cut, recurring work can run unattended, and risky actions can wait for approval. The migration changes the operating rhythm. win.sh monitors continuously and reports through a morning brief and Decisions tab. Task Machine makes each recurring process explicit and gathers every judgment call in one inbox before the work continues.
Why do people switch from win.sh?
- The process needs to be visible, not only the decisions. win.sh makes actions, receipts, and authority legible. Task Machine also exposes the workflow graph, branch, current step, verifier result, and complete step history.
- Review needs to happen before more kinds of work continue. win.sh gates risky categories. Task Machine can place a human question, approval, or verifier at any chosen point in a workflow.
- Humans and agents need shared work objects. Task Machine keeps both on the same projects, goals, tasks, comments, and workflow runs instead of centering one autonomous company loop.
- Every judgment call needs one queue. Approvals, questions, failed checks, proposals, and exceptions arrive in the inbox with their decision context and available actions.
What maps to what?
| In win.sh | In Task Machine |
|---|---|
| A 24/7 company loop | One or more scheduled deterministic workflows |
| Authority matrix by work type | Autonomy levels, permissions, budgets, and explicit gates |
| Decisions tab | Inbox items for approvals, questions, failed verifiers, and exceptions |
| Morning Telegram brief | Current task state, inbox queue, and step-level run history |
| Categorized facts, decisions, learnings, and rules | Workspace knowledge, agent memory, task context, and recorded decisions |
| Agent Skills and CLI loops | Playbook catalog, skills, workflows, and connected workers |
| Dollar-based receipts and hard cap | Token and money budgets with warning and stop thresholds |
What do you give up?
win.sh is ahead on autonomous-run polish and the compact morning-review rhythm. Its authority matrix is a clear way to let different work types earn trust over time, and its self-serve onboarding begins with less process design. Moving to Task Machine means defining or installing explicit workflows, connecting a worker, and accepting that the inbox exists because a person still owns selected decisions. Stay with win.sh if the brief gives you enough control and the continuous loop is the behavior you value.
How does the switch work?
- List each recurring loop and separate monitoring, decision, and action stages.
- Install or define a Task Machine workflow for each stable process, then represent decision points as human-question, approval, or verifier nodes.
- Connect the same customer-owned systems through connectors and attach an appropriate worker for agent steps.
- Start with lower autonomy and conservative budgets, then run both systems in parallel for one cycle and compare actions, evidence, and intervention load.
- Retire a win.sh loop only after its Task Machine workflow has completed the expected success path and each known exception path.
Common questions
Should every win.sh action become a workflow?
No. Group actions by the recurring process they serve. One workflow should preserve a meaningful operational sequence rather than recreate every event as an isolated task.
Can Task Machine monitor work on a schedule?
Yes. Workflows can run on schedules and route anything requiring judgment to the inbox. The distinction is that the process and its gates stay explicit.
Does Task Machine take custody of connected accounts?
No. You keep 100% of your revenue, Task Machine takes no cut, and it never custodies your accounts.
Details about win.sh reflect its public materials at the time of writing; check their site for current terms.