Working patterns with Cowork

Getting good results from Cowork is not about knowing "the right command" but about framing the request well. This chapter collects patterns that have been seen to work in production.

Four rules for framing a request

1. Say where you are looking. If you are on a record, "this quotation" is enough. If not, name the record or give its number.

2. Say the format of the output. "As a table", "in three points", "as a Word document", "in language fit to send to the customer". When no format is given the model chooses its own and usually writes long.

3. Limit the source. "According to the attached specification" ties the model to that document. Without a limit it works more slowly and can wander off topic.

4. Separate whether you want a decision. "List the options for me" and "which one should it be" are different requests. If you want the second, also give the criterion the decision should rest on.

Common patterns

Extracting information from a document

Case

A technical answer from a specification

Situation

A customer asks whether a drive supports a secondary encoder. The answer is in the 40-page specification attached.

What was done

"Read the specification attached to this record; list secondary encoder and BiSS support per connector as a table" was asked.

Result

Cowork really read the document and produced the correct table per connector. The cost was well under a cent; the alternative was 20 minutes of an engineer's time.

Turning ERP data into a report

Case

Monthly quotation summary into a presentation

Situation

The status of this month's quotations is wanted for the management meeting.

What was done

"Group the quotations opened this month by status, with their totals; make the result into a presentation" was said.

Result

Cowork read the records, produced the summary and generated a presentation file. Because the figures came from the system, the answer to "when was this taken?" is clear.

Text work

Translation, summarising, rewriting, changing the tone. What gains most here is giving the source: "write this quotation in English, ready for the customer" is both faster and more accurate than having it written from scratch.

Drawings and diagrams

Cowork can draw diagrams. The important thing to know: it draws the meaning, not the geometry. "Make this process a flowchart" is a good request; "move the box 3 cm to the right" is a bad one — that is the drawing tool's job (chapter 11).

Suggesting a bulk edit

Jobs such as "replace the old brand name in these products' internal notes with the new one" are possible and can be undone. But always read the number of records on the approval screen.

What not to ask for

Judging the answer

Under every answer you can see which model answered and which tools were called. Three quick checks:

• Was a tool called? An answer to a question about a document given without reading the document is suspect.
• Where did the figures come from? A total with no visible source should be checked by hand.
• Does the answer answer the question? A long, fluent text is not the same as a correct text.

For some kinds of turn, calling a tool is enforced by the system itself, not merely requested in the instructions — a request in text is weighed by the model, a mechanism is not.

Cowork outside the panel

Cowork works in three more places:

• Inside the office editors — without leaving the document (chapter 15).
• The daily briefing — a morning summary that shows the gaps in the system (chapter 15).
• In the background — long jobs; they carry on while you do something else and appear in the panel when they finish.

When speaking Turkish

Cowork works in Turkish, but two points need care:

• Suffixes can blur terms. Expressions such as "To-Do'larımız" make it harder for the model to recognise the term; the system keeps a suffix dictionary for this, but writing the term in its bare form is safer.
• Abbreviations. Writing company-specific abbreviations into memory once is better than explaining them every time.