The lore behind Loom
As stated in the previous article, I had been using Scrivener for the longest time while working on this book.
My process would roughly be:
Write a few paragraphs.
Stop.
Copy and paste them into ChatGPT.
Get a signal of coherence and continuity.
Get back to writing.
Rinse and repeat...
Of course, more problems came about whenever I switched back to a previous chapter to continue or refine an event I had mentioned earlier.
I would typically start by copying and pasting the entire page, then ask specific questions about the paragraph I was working on.
Then, while rot-scrolling through Instagram, I saw an advertisement for another writing app that included AI.
That sent me down the rabbit hole of comparing writing software and figuring out which features I actually wanted and which ones I didn't.
There were plenty of applications offering revision tools, grammar assistance, and AI-generated suggestions.
But none of them quite offered the thing I actually wanted:
A sounding-board companion.
Enter Loom
This is where I decided to build my own.
With the original problem in mind, the initial plan was fairly simple:
Test the functionality using Ollama and a local model for revision requests, then figure out how to get ChatGPT to communicate with Loom itself.
But once you have a blank canvas, the ideas start flowing.
First came a backend structured around contextual chapter files that could give a model a concise representation of the manuscript, alongside the actual WYSIWYG version I worked in.
Then a file-manager-style structure for nested chapters and reference pages.
Then a fluid reference system that lets a name in the manuscript point back to a singular entity — a character, event, place, or anything else — while accounting for the different ways the manuscript might refer to the same thing.
Then came the idea for a revision system inspired by Git, with archivable, iterable change history for the manuscript.
Then a Timeline, where a page or even a specific passage can be associated with a point in time. That timeline can reflect the real world, or it can be completely arbitrary for a fictional universe.
The ideas kept coming.
They still are.
The manuscript
Loom isn’t meant to replace the author, and AI isn’t supposed to sneak its way into becoming one. The role of AI here is much closer to a sounding board or creative partner — something that helps you question, refine, organize, and understand what you’ve already written.
Everything else in Loom — timelines, references, entities, revision history, context, and metadata — exists to support the manuscript rather than compete with it.
The AI Problem
After getting the local Ollama implementation working, I ran into another limitation: the models I could realistically run on my MacBook were inconsistent at best.
The problem wasn't Ollama itself. The problem was what I could realistically run on the hardware I had.
This is where AP eventually came into play.
Once AP existed, Loom could expose a single application-level AI interface while supporting multiple capabilities underneath it.
That might mean requesting a revision directly from a configured model, or asking for feedback through the communication channel exposed to an external AI client.
The important part is that Loom owns the context and decides what gets shared.
And all of this is optional.
Loom still works perfectly well as a local-first writing environment without AI, without an internet connection, and without any external service.
Anything you write locally remains yours and remains available.
Today Loom is at version 0.1.0-rc.1, which means there will still be plenty of changes, experiments, and probably a few ideas I haven't thought of yet.
A paid tier may eventually differentiate some functionality, but that is a problem for future Juan.
For now, Loom solved a problem I actually had.
And, like AP, it became a moderately fun distraction along the way.
Previous Article: https://www.juancastro.me/writing/ap-ai-proxy