When organisation starts getting in the way of work
AI assistants can help with many projects, but they can also expand their own administration. This case shows how a mechanism intended to organise tasks became a source of delays and what we changed.
1. What the registry was meant to do
We were handling different matters in parallel across several conversations. We needed a shared, concise status: what had been requested, who was responsible, whether approval existed, what had been done, what blocked progress and what came next. Such a list helps prevent duplicated work, repeated questions and duplicate messages.
The registry was our additional tool. Windows and ChatGPT do not themselves require such a file to operate. It should save more work than it costs to maintain.
2. How a useful list grew beyond 300 MB
Old versions, complete evidence, extensive control data and further updates began accumulating alongside current statuses. The mechanism preserved this information cautiously, but lacked a sufficiently clear boundary between operational state and archive.
A measurement of a consistent copy showed approximately 333 MB of data. Of this, approximately 321 MB was in the updates section, including about 320.7 MB for the historical event log alone. Case records occupied about 10.3 MB, but also contained history and extensive evidence. The final copy before reduction had already reached 336.7 MB.
Changing one short status therefore required processing a large amount of information not needed for that decision. More chats queued for the same file. In one run, waiting for the lock alone took 4 minutes 54 seconds, before the actual write.
3. EPERM: not every error on Windows comes from a Windows defect
Independently of file size, an EPERM error occurred during safe file replacement. The write created a complete new version and was then supposed to replace the previous one. We reproduced a variant of the problem with a reader still using the old version and improved the interaction between reader and writer. However, we did not identify the specific process holding the file during the original failure.
The original tests covered competing writes, but missed the relevant scenario of a reader held open for a long time. We too quickly attributed the earlier denial to environmental restrictions. We should have reproduced it more precisely before treating the mechanism as sufficiently tested.
A combination of two changes helped: the reader allows the sharing required for replacement, and the writer uses the documented Windows function FileRenameInfoEx with the appropriate flags. The reader finishes the old, consistent version; a new open sees the complete new version. A test with a compatible reader held open completed 12 writes and 292 full reads without an error.
This is a diagnosis of this specific mechanism. It is not evidence that every Windows 11 or ChatGPT user has this problem, or that every EPERM denial has the same cause. Genuine access denials must still be respected.
4. The user’s question that changed direction
‘Why do we need this registry?’
After fixing the error, we could have continued adding safeguards and layers. The user instead asked about the tool’s purpose. We considered retiring it, then adopted a simpler solution: keep the useful current state and remove historical material from the active file.
The registry retained basic case information and links to details. We preserved the complete earlier history in a separate archive and verified its checksum. Brief statuses for completed and rejected cases were retained to avoid repeating old actions.
We also introduced an update policy: write when there is a significant new task, decision or approval, a change of owner or scope, an important blocker, or completion. A read, a new check time, a repeated status or another observation alone does not change the file. Project history should be updated in batches at a milestone or closure, rather than after every minor step.
5. Comparing individual measurements: before and after
This comparison of actual runs was requested by the user. It is important to retain where each measurement was taken and what it does not prove.
| Measure | Before | After the change | How to interpret the result |
|---|---|---|---|
| Active file size | 336.7 MB | 3.16 MB | Approximately 99% less data in the active registry. History preserved separately. |
| Read | About 30–34 s | 0.41 s on the live registry | Roughly 80 times shorter in these individual measurements. |
| Write without queueing | About 3 min | 1.73 s on a private copy of real data | Roughly 100 times shorter. The new write was not measured as a production operation. |
| Waiting for the lock | An additional 4 min 54 s in one run | No comparable measurement across the entire organisation | We do not add this wait to the write time itself, and we do not promise that queues will disappear. |
On a narrow screen the table can be scrolled horizontally.
6. Even a repaired mechanism can benefit from simplification
A further review found that even the small file was reconstructed several times as a complete JSON structure. Two of those passes repeated work on bytes whose consistency was already being checked.
We removed duplicate structure reconstruction and a second normalisation of the same records. The prepared content is validated once, while a checksum confirms that the written temporary and final files match. Checks of owner, source and scope, locking, backup, concurrent-change detection, write synchronisation and read-back remain.
| Measure | Before code simplification | After code simplification |
|---|---|---|
| Number of trials | 5 | 5 |
| Median write time | 1.34 s | 0.64 s |
| Range of observed times | 1.23–1.60 s | 0.60–0.79 s |
| Result and backup | Logical results matched; all backup checksums matched; repeated statuses caused no write. | |
In these trials the median fell by approximately 52%, making the write about 2.1 times faster. This is a better-controlled comparison than the first stage, but it is still a small sample in one environment with a local cache. It is not a measurement of throughput across all projects.
7. Bottlenecks in procedures and context
Code is not the only possible source of overhead. One row of a shared spreadsheet held a second full copy of the working instructions — about 29,000 characters. Some simple searches therefore returned that entire text as well. The duplicate copy could also drift out of sync with the current source.
We simplified this to one complete source of instructions, with brief current rules and a link in the spreadsheet. Within an active task, unchanged documents need not be fetched again and the same integration need not be rediscovered. A fresh read is needed after a source change, a new scope, a break, an error or a contradiction. We still check the necessary current information before a significant write or send.
We also clarified that a fix, continuation or new technical case identifier does not constitute a new project requiring a proposed chat name. We did not establish the origin of the particular rename option visible in the interface, so we do not attribute it to this rule with certainty.
A brief ten-second observation of the panel showed approximately 0.27% of the computer’s total CPU for the main process and about 0.01% for the reader. We did not regard this as grounds for another rebuild of a working panel. Not everything that can be optimised is worth optimising.
8. Causes that are easy to repeat
- A blurred purpose. A list of current matters becomes an archive of everything.
- No growth budget. We do not establish how large the active state should be or how much maintaining it may cost.
- Updating after every step. We record the fact of checking rather than an actual change.
- Patching the symptom. We fix a write error without asking why the write is so expensive.
- An incomplete test scenario. We test two writers while overlooking an open reader and a large dataset.
- Too many copies and checks. Each copy seems reasonable on its own, but together they create cost and a risk of conflicting versions.
- Overstating a small measurement. We turn one fast result into a promise of general speed or savings.
9. How to avoid a similar problem
- Write one sentence describing the mechanism’s purpose. Every field and every write should serve that purpose.
- Separate state, history and details. Keep the status and a link in the current list; update milestone documentation in batches.
- Identify significant events. A new task, approval, owner, scope, significant blocker and completion matter. A check alone is usually not a change.
- Measure the whole path. Separate queue, read, computation and write times. Several alternating trials are more convincing than one result.
- Test growth and interruption. Test a larger dataset, an open reader, two writers, a repeated event and a failure before commit.
- Simplify before adding layers. First remove unnecessary data, copies and repeated computations. Only then consider another tool or database.
- Keep safeguards that serve a distinct purpose. Speed does not justify losing approvals, backups, owner checks or result verification.
- Do not guess at benefits. We did not measure credits, tokens or financial savings, so we do not claim them. Nor have we shown that additional agents or different hardware solve this problem.
Prompt for reviewing your own overhead
Review which elements of our way of working help achieve the goal and which merely create administration. Separate confirmed delays from hypotheses. Measure queue, read, computation and write times. First remove unnecessary data, repeated steps and outdated copies. Preserve approvals, ownership, backup and result verification. Show a before-and-after comparison, the method and its limitations. Do not add a new system if simplifying the existing one is enough.
The most useful question in this case was not about another technology: does the mechanism still do only what it was created to do? AI can efficiently build procedures and code. That does not exempt us from accounting for their cost.
Sources and limits of this study
This account concerns one real case from October 2026. Operational data, private content and account identifiers are not published. We provide anonymised measurements and a description of the method in JSON. The documentation below confirms API behaviour; it is not independent verification of our timings.