IV · Cowork AI · Chapter 13
Tools and grounding
Which tools Cowork calls, how it reads the inside of attachments, what it counts as evidence and the layers that stop it making things up.
The most dangerous behaviour of a language model is telling you something it does not know in a convincing way. Most of Cowork's architecture is built to prevent this, and it is called grounding: every claim resting on a record or a file in the system.
Tools
Cowork does not answer questions directly; it first calls tools. The main families:
| Family | What it does |
|---|---|
| Search | Searches, filters and counts records |
| Read | Reads a record's fields, chatter and attachments |
| Document | Turns PDF/Word/Excel/presentation content into text and reads it |
| Vision | Reads pictures and scanned documents (OCR / vision) |
| Produce | Produces Word, presentations, HTML documents, tables and diagrams |
| Write | Creates/updates records — behind the approval gate |
Tools always run with the permissions of the user who calls them. Cowork has no permissions of its own; it cannot read you a record you cannot see.
Page Review
A button in the panel asks the open record one question: is anything missing, wrong or problematic on this page? The answer is not a paragraph but a list of findings you can tick; you decide which correction is written.
The review has two passes, and what separates them is not what is expensive but what suits what:
| Pass | What it looks at | Cost |
|---|---|---|
| Arithmetic | Empty required field, broken e-mail, phone not in international format, tax number (VKN/TCKN) whose check digit fails, IBAN that fails mod-97, address without https://, a date that ends before it starts, a forgotten "trial/test" value, text in capitals from start to end | None |
| AI | Commercial, managerial and technical reading that arithmetic cannot decide | One call |
Capitalisation is corrected the Turkish way: İSTANBUL SANAYİ does not become "Istanbul Sanayi".
Writing goes the ordinary way, with your permissions, and lands in the conversation's undo ledger. Every finding has its own savepoint: a single rejected value does not undo the corrections approved in the same click.
The result is kept against the record's own change date; reopening an unchanged record costs nothing. The same review can be asked for in the conversation by saying "review this page"; there it works read-only.
The inside of attachments
The standard core searches only inside plain-text attachments; PDF and office files are invisible to content search. Cowork changes this: PDF, Word, Excel, presentation and open office formats are turned into text and indexed. When a document that has not been indexed yet is asked about, it is indexed on the spot.
A promise is not enough
A model saying "I am updating this now" may mean that it did not update it. In Cowork a promise counts as kept only with a tool call: commitments made in the text with no action behind them are caught and reported to the user.
The same logic applies to empty success reports: a "done" answer with no content does not count as done.
Write turns and undo
Cowork can change records, but that is a separate class:
- Turns that intend to write are routed to a more capable tier.
- Critical actions ask for approval.
- Every change made is captured and its difference kept; a Cowork edit can be undone.
The source gate
Cowork going outside (downloading content from an address) passes through a single gate. That gate checks which addresses may be reached, does not allow certificate checks to be skipped and applies size/time limits. So the assistant cannot be tricked into reaching an address on the company's internal network.
Company memory
Cowork can remember recurring information: the company's abbreviations, product naming rules, the answers to frequently asked questions. Every claim written to memory can be reviewed and rejected — a wrong "fact" in memory poisons every answer.
A plan is one approval
A multi-step job (enter the leave, then approve it, then tell the team) comes as a single plan card and runs with one approval. A step uses the record the previous step created: the system does not guess a record that does not exist yet; a step with a reference it cannot fill is skipped with its reason, never run on a guess.
Leave, in a single approved step. "Enter annual leave for Ali and Ayşe next week" runs on one card: the type is taken from the conversation ("annual" → Paid Time Off), the days are counted from the working calendar (Monday–Friday = 5), a missing allocation is completed for the whole year and the approval is made with the user's own permissions. All or nothing; a rejection names the person and what needs to be decided. The card says "will be APPROVED on your behalf" and asks a second time on click; by voice, two "yes"es are the double approval.
Access doctor. A permission error keeps what the system said: which records, which group grants the permission, who can grant it — in plain language. On a record rule refusal it says what can be done.
Job guides. For common jobs (to-do, activity, note/message/e-mail, leave, opportunity, quotation, purchase, manufacturing, transfer, invoice, timesheet, recalling a rule) the knowledge base names the one right tool — in a form that survives even in the shortened copy used by the fast tier.
Cowork Health
One row a day: number of turns, answer time, turns that hit the step limit, failed actions, negative signals, voice clips and cost. The question "has the assistant got slower?" is answered with one screen.
The learning loop
User feedback (liked / wrong) turns into measurement. Which tier succeeds how well on which kind of question is followed and feeds the bake-offs. The system does not praise itself; it gets its score from how the answers it produced are judged.
An action that is undone is a negative signal too. Suggested rules go to a reviewer (the people set in the settings, otherwise the administrators) with a weekly reminder — nothing in the learning queue becomes a rule without a person's approval.