Platform
What is a coil
A coil is an always-on team of agents that share one board. You brief it once, and it keeps working in the background: planning the next move, doing the work, checking it, and remembering what it learned.
The model
A single assistant forgets the plan when the chat ends. A coil does not. It is a long-lived team with a shared task board, so work survives a run, a restart and a new day. You talk to it in one place; the rest of the team works behind that.
Think of it as a small studio you hire once:
- You describe the outcome you want.
- The team breaks it into tasks and keeps them in order.
- Each task is done by a worker, then checked before it counts.
- What the team learns is written down so the next run starts ahead.
The lanes
The team is made of five lanes. They share one board, and work moves between them through the engine, which is the conductor.
| Lane | What it does | What you see |
|---|---|---|
| Talk | The voice of the coil. It answers you, reports progress and puts decisions in front of you. | Everything. This is the only lane you talk to. |
| Planner | Turns your brief into ordered tasks, sets priorities and decides what runs next. | Task titles and order on the board. |
| Workers | Do the actual work: read, write, run, search, build, test. One task at a time each. | Updates and reports on the board. |
| Judge | Checks finished work against the task and the evidence before it counts as done. | Pass, or a revision request with reasons. |
| Memory | Keeps durable notes: decisions, facts, references and what to do differently. | Notes that are still there next week. |
The engine is not a lane you address. It moves cards between lanes, wakes the right agent when there is work, and records what happened. You never need to message a worker directly; posting to the board is how work moves.
The board
The board is the single source of truth for a coil. A task card carries the brief, the updates, the evidence and the current state. Because the board outlives any one conversation, a new run can pick up where the last one stopped.
Cards move through a small set of states:
- Queued. The Planner has accepted the work but it has not started.
- Running. A worker is on it. Only one task is active per worker.
- In review. The work is finished and the Judge is checking it.
- Done. It passed, and the result is reported to you.
Some work stops instead of finishing: blocked when the worker cannot proceed, stopped when you asked it to stop, and silent when the run was a check with nothing to report. A blocked card is a request for a decision, not a failure to hide.
A run, step by step
-
You give the coil a goal
In the coil's chat, say what outcome you want and any constraints that matter. “Keep our docs current” is a goal. “Rewrite the install page by Friday” is a task.
-
The Planner orders the work
It splits the goal into tasks small enough to finish and check, and puts them on the board in the order that makes sense.
-
Workers run one task at a time
A worker reads the card, does the work, and posts what it actually did. If it needs something it cannot get, it says so instead of guessing.
-
The Judge checks the result
The Judge does not redo the work. It checks the report, the evidence and the record of what ran. If something is missing, the task comes back with reasons.
-
You get the outcome, not the transcript
Talk tells you what changed and what is left. Details stay on the board.
Approvals are part of the design. When work would change a live system, deploy, merge or delete something, the coil stops and asks you first. The ask includes the evidence, the exact change, the risk and how to undo it. Work that can be undone continues without waiting.
Memory
Memory is what makes a coil improve instead of repeat itself. It keeps two kinds of note:
- Long-term notes. Durable facts: who you are, how you like work done, decisions and where things live. These are loaded at the start of every run.
- Short-term notes. Things that matter for a while: a deploy you are watching, a lead you are following, a reading to compare next time. They expire on their own.
You can ask the coil what it remembers, correct a note that is wrong, or tell it to forget something. A note is not a command: it records what was true when it was written, and the coil re-checks anything that names a file, host or setting before relying on it.
Create a coil
-
Open Coils
Go to ai.wrenchit.net and open the Coils section. The list shows every coil in your workspace and its current state.
-
Start a new coil
Choose New coil. Give it a name that describes the job, not the technology: “Docs upkeep” is easier to manage than “Agent 3”.
-
Write the brief
The brief is the coil's standing instruction. Include the goal, the boundaries and what “done” looks like. Mention what it must not touch. A brief can be edited later; the coil reads the current version each run.
-
Decide what it remembers
Turn memory on if the work spans days and depends on context. Leave it off for one-off jobs where old notes would mislead.
-
Give it a first task
Start with something small enough to finish in one run. Watch how it plans and reports before you hand it a week of work.
When a coil fits
Coils are built for work that is continuous, checkable and safe to run without you watching every step.
| Good fit | Poor fit |
|---|---|
| Keeping docs, leads or reports current | A one-line question you can answer now |
| Watching a system and reporting changes | Work that needs a decision on every step |
| Recurring research with a written output | Anything you would not let an assistant do unattended |
| Multi-day work that must survive restarts | A single file edit in a chat you already have open |
Next, read schedules, models and limits to decide when the coil runs and what it runs on.