Most agent work starts in a chat window, because that is where the question first occurs to someone. A lot of it should stay there. Some of it quietly turns into something else: work that other people will rely on, that will run longer than anyone watches, or that ends in a file someone has to sign off. Leaving that kind of work in a conversation is how results get lost, and turning every quick question into a ticket is how teams stop using the agent at all. The useful skill is telling the two apart early.
What a conversation is good at
A conversation is the right shape when the person asking is also the person reading, and the answer is needed now. Exploring a topic, drafting a paragraph, testing how a question should be phrased, checking what a document says about one clause: these are short loops where the value lies in the back-and-forth. Nobody needs a record of the third rewording of an email subject line.
A good conversation still has limits. In GoCux Conversation, any tool call that would change something waits for you before it runs, so a chat can investigate freely but cannot quietly send, delete or export. That keeps chat safe for exploration. It does not make chat a good place to keep work that matters later.
Signs the work has outgrown the chat
Watch for any of these. One is often enough to move the work; two almost always are.
- Someone else has to review or rely on the result. A reviewer cannot sensibly scroll a transcript to work out what was asked and what was decided.
- It will outlast your attention. If you would close the tab and come back tomorrow, the work needs a home that survives without you.
- There is a definition of done. The moment you can say what a finished result looks like, write it down where the work can be checked against it.
- It needs sources you will have to show later. Findings that will be questioned need their evidence attached, not buried in message eleven.
- It produces files. Tables, reports and drafts are deliverables, and deliverables need a place where they are versioned and reviewed.
- It may need a consequential action. Sending, exporting or scheduling deserves a clear decision point tied to one specific piece of work.
What a work order adds
A work order turns a request into an object with a shape. In GoCux, each piece of work gets one work order that states the goal, the scope it may touch and the acceptance criteria that define done; GoCux then picks the skills the work needs. The order belongs to a project, carries a data classification and runs within bounds on wall time and tool calls.
From there, the order moves through four states: queued, running, awaiting decision and done. The third state is the gate. Nothing downstream of it starts until a person decides, and a rejection is recorded rather than quietly releasing the work. Each step is written to the order's record as it happens, so the result, its sources and the decisions taken along the way stay together.
Two details are easy to miss. An order being accepted does not mean the work was carried out; the state, progress and attachments tell you that. And if durable execution is not available, the order is refused openly instead of showing progress that is not happening. A refusal is a result explains why that honesty is worth more than a spinner.
Side by side
| Conversation | Work order | |
|---|---|---|
| Best for | Exploring, drafting, quick checks | Work others rely on or review |
| Definition of done | In the asker's head | Written acceptance criteria |
| Record | A transcript | Events on one record, as they happen |
| Results | Messages | Attachments with their sources |
| Decisions | Per tool call, in the moment | A defined gate before anything downstream |
| Limits | Your attention | Bounds on time and tool calls |
Promoting a chat to a work order
The conversation is not wasted when the work moves. It is usually where you discovered what the real question was. The mistake is to paste the whole transcript into the order and call it the brief. Instead, pull out three things:
- The goal, in one or two sentences. “Find the notice period for price changes in the current supplier agreement and its amendments.”
- The scope. Which project, which documents or sources, and what is explicitly out.
- The acceptance criteria. “The answer quotes the clause and names the document and section. If the amendments change the period, both versions are quoted. If no clause is found, the result says so and lists the documents checked.”
Writing those criteria well is its own skill; write acceptance criteria before the agent starts walks through good and bad examples, and the guide to specifying a task shows the fields in practice.
Mistakes in both directions
- Running long jobs in chat. The work happens, but nobody can find the result next week, or say which sources it used.
- Ticketing every question. If a one-line lookup needs a form, people go back to doing it by hand.
- Reading “accepted” as “done”. Check the state and the attachments before you forward anything.
- Treating chat as memory. A helpful line in a conversation does not turn into company knowledge on its own; memory with consent covers how it should get there.
A quick test before you start
Ask yourself three questions. Will anyone other than me rely on this? Can I say what finished looks like? Will I need to show where the answer came from? If the answer to all three is no, stay in the conversation. If any of them is yes, open a work order, and let the chat be the place where you worked out what to put in it. An audit trail is only as useful as the record behind it, and that record starts with this choice.
Bring this workflow into your workspace.
Set the scope. Review the evidence. Approve the steps that need it.