DOCUMENT WORKFLOWS
Kim: lessons from document automation
Start with a concrete document task.
The work around the model
My work on Kim grew around document tasks: incoming material, summaries, comparisons, file conversion and knowledge retrieval. The model was one component. Useful behaviour also depended on how documents arrived, how the task was bounded and how the output was reviewed.
Choose the deployment deliberately
The choice of local models, external APIs or research services starts with the task and the documents involved. These questions help make the data paths, permissions and review steps explicit:
| Area | Questions to settle |
|---|---|
| Data flows | Which documents, queries and logs stay on the machine, and which go to email, API or search services? |
| Tool access | Which files may the workflow read or change, and which tools may it use? Which actions require approval? |
| Review | Who checks sources and results, handles failures, and authorises sending or overwriting files? |
A handover matters more than a name
The useful result is a workflow someone can operate: a defined input, a clear output, example tests and understandable limits. Kim is the name I use for this development work.
An early public reference to Agent Kim appears in my note of 17 May 2025, describing tasks received through local email and a watched folder.