I faced two seemingly different problems at different times. Only later did I realise they were connected.
One was a narrative pipeline for an educational game that forced me into a manual, interrupt‑driven role. The other was an expensive, supposedly all‑purpose AI model that burned resources on tasks a fraction of its size could handle. Both were symptoms of the same flawed instinct: centralising intelligence in a single, fragile point. The solution, in both cases, was the same.
The Collaboration Plane and the Glue Person
Our narrative content lived in a Collaboration Plane: a Google Sheet that served as the single source of truth for production. Each row represented a narrative unit, a line of dialogue, a branching choice node, a tutorial step. Columns captured dialogue IDs to decouple narrative from code, UI types, speaker information, branching logic, localised text across multiple languages, and encoding columns for engines that needed specific fonts or glyph mappings. The sheet was a contract between writers, translators, designers, and developers. Writers saw a script with structure. Designers saw a tuneable graph. Translators worked in context. Developers consumed structured data instead of chasing hard‑coded IDs across code files [1].
But every time a translator finished a column, or a writer fixed a typo, the message came: “The sheet is updated, can you run the build?” I would export CSVs, run encoding and validation scripts, trigger builds, and sanity‑check outputs. I had become the glue person for my own system. The Collaboration Plane captured what should happen, but the how still ran through me.
Tanya Reilly, a former Staff Systems Engineer at Google, coined the term “glue work” for the essential but often non‑promotable tasks that hold teams and projects together [2]. When glue work is unconscious and unmanaged, it becomes a trap. The engineer who is always available, always responding to pings, never gets their real work done.
The False Promise of the Monolithic Model
Around the same period, I fell into the second trap. I had internalised a widespread industry assumption: that general capability scales with model size. For one project, I needed to classify sentiment in short‑form video comments which is a straightforward natural language task. Instead of reaching for a specialised lightweight model, I defaulted to a heavyweight generalist. The results were acceptable, but the cost and latency were absurd for the task.
That assumption proved costly and unnecessary. I later ran a separate experiment: a self‑hosted AI stock analyst built in 48 hours. A local LLM parsed SEC filings and news sentiment, writing results directly into spreadsheet cells. Native formulas calculated moving averages, RSI, and Bollinger Bands. Months of front‑end work were bypassed. The model was small, focused, and running entirely on my local hardware. Yet it delivered exactly what the business logic required.
The monolithic model was not just overkill, it introduced fragility. When you rely on a single, giant model for everything, you accept its latency, its cost, and its hallucinations for tasks that don’t require its full capacity. You couple every operational objective to a single design‑time choice. The shift from model‑centric to system‑centric design is not optional; it is where the industry is heading [5][6].
The Real Cost: What the Data Shows
The cost of centralised thinking, whether in human workflows or AI architecture is staggering.
Research analysing data from over 200 engineering teams found that context switching isn’t a minor productivity loss. It’s the root cause behind slow reviews, stalled tasks, and unpredictable delivery. It takes an average of 23 minutes and 15 seconds to fully return to a task after an interruption. Frequent interruptions can reduce problem‑solving ability significantly. Developers experiencing ten context switches in a day can lose 1–2 hours of productive time just to reorient [7].
Cognitive performance can drop by up to 40% when people rapidly switch tasks [8]. Knowledge workers spend as much as 20–30% of their day recovering context [9]. And when people switch tasks without closure, a portion of their attention remains stuck on the previous task, a phenomenon researchers call “attention residue” [10].
The parallel to AI is direct: a monolithic model forces you to accept its limitations. A modular approach lets you match the right specialist to each task. That gives you better control, lower costs, and less frustration.
Automating the Collaboration Plane
We picked one annoying task and automated it. Nothing grand. Just the spreadsheet‑to‑deployment loop. Writers marked a cell as “yes” when content was ready for staging. A developer then had to validate and deploy.
We built a small automation using three tools: n8n for workflow orchestration, Ollama to run a small local LLM, and Docker to keep everything contained. When that spreadsheet cell changed to “yes,” the automation triggered.
The importer, which already existed as part of our CI/CD pipeline validated the structural integrity of the narrative data by checking for missing dialogue IDs, broken branches, missing localisations, and audio file references. Then an AI agent, running locally via Ollama, reviewed the actual narrative text by scanning for inconsistent speaker names, missing variables, or tone issues across languages.
Once both validation steps passed, the workflow committed the updated content files to Git, and our existing GitHub Actions pipeline handled the build and deployment. The developer who used to be the glue person got back hours each week.
This success led to a second experiment: a self‑hosted AI stock analyst built in 48 hours. We connected a local LLM to a Google Sheet. It parsed SEC filings and news sentiment, then wrote the results into cells. Native spreadsheet formulas did the rest: calculating moving averages, RSI, and Bollinger Bands. Months of front‑end work were bypassed. The humble spreadsheet became the interface.
From Glue Automation to Model Modularity
If a spreadsheet toggle can trigger the right agent, why not apply the same idea to AI models themselves?
Instead of relying on one giant model, we built a small team of specialists. A focused Llama model handles structured analysis by pulling numbers from financial filings, parsing log files, anything tabular. Another lightweight extractor mines text for sentiment and key phrases. A lean classifier sits in front and routes each incoming task to the right specialist.
I was sceptical at first. More moving parts, more things to break, right? But the opposite happened. Each piece became simple, cheap, and replaceable. If the sentiment model starts misbehaving, we swap in a different small model. No downtime. No vendor lock‑in. The classifier does not care which model it calls, as long as the interface stays the same.
Compound AI systems where multiple models and tools work together in clear, repeatable processing steps are increasingly outperforming monolithic approaches [5]. The performance gap between smaller, specialised models and large general‑purpose models is decreasing much faster than anticipated. Modular architectures offer superior scalability, enhanced specialisation capabilities, and alignment‑safe distributed governance [6].
Latency, Routing, and Human Oversight
Modularity introduces operational concerns like latency management, task routing, and keeping the ensemble from becoming a distributed nightmare. We learned these lessons the hard way.
Some tasks that need a response in milliseconds go to the lean classifier or a tiny rules‑based system. Others can wait a few seconds, so they use the heavier Llama model. Task routing matters: do not send a simple job to a slow model just because you can.
Keeping the ensemble stable requires discipline. Docker helps. So does keeping orchestration boring, predictable, well‑tested, and not clever for cleverness’ sake.
Human‑in‑the‑loop is a feature and a design principle, not a weakness or a patch [11]. Before emails go out, the workflow pauses on a review node. I can inspect the analyst JSON and the composed HTML. The goal is to blend the speed of AI with the accuracy and quality of human judgment.
The Core Shift
Stop fixating on model size and general capabilities. Instead ask, what workflow gets this job done most efficiently?
Where a single large model forces you to accept its limitations, a modular approach lets you match the right specialist to each task. That gives you better control, lower costs, and less frustration. It also means you are not paying a giant model to do tiny jobs, a pattern I see all the time in teams that buy first and design later.
The same logic applies to human work. Glue work is something you design, not something you endure. When you automate predictable handoffs, you free people to focus on problems that actually need human judgment.
A Practical Blueprint
Pick one repetitive task on your team that follows a clear pattern. Something that happens every day, takes a few minutes, and interrupts someone who should be doing deeper work. Ask yourself: could an agent read a simple human signal, like a checkbox in a spreadsheet and then orchestrate the next steps?
Try it with n8n and Ollama on your laptop. No cloud account needed. No approval from IT. Just a local experiment.
Once that works, look at your AI usage. Where are you using a giant, expensive model for a small, routine job? Swap in a specialist. You will save capital and get faster answers.
You do not need to boil the ocean. You just need one toggle, one agent, one small win. That win will teach you more than any whiteboard architecture.
Glue work is a design problem, not a career path. A team of specialists, human or machine beats a single generalist every time. The right architecture, chosen early, prevents months of unnecessary struggle.
The industry is shifting from assistance to orchestration [12]. The engineers who embrace modular, local, composable systems will be the ones who stop fire‑fighting and start building.
Stop being the glue. Start being the architect that runs the glue.
References
[1] DeLeon, C. (2013). Excel in Games: Using Spreadsheets for Game Design. Game Developers Conference. https://www.gdcvault.com/play/1017772/Excel-in-Games-Using-Spreadsheets
[2] Reilly, T. (2019). Being Glue. https://noidea.dog/glue
[3] Particle41. (2026, April 7). Should CTOs Be Worried About AI Vendor Lock-In? https://www.particle41.com/insights/ctos-worried-about-ai-vendor-lock-in/
[4] Chen, L., Zaharia, M., & Zou, J. (2023). How is ChatGPT’s behavior changing over time? arXiv:2307.09009. https://arxiv.org/abs/2307.09009
[5] Snyk. (2025, October 6). From Models to Compound AI Systems: Building the Future of AI. https://snyk.io/articles/from-models-to-compound-ai-systems-building-the-future-of-ai/
[6] InfoWorld. (2025, October 6). Pros and cons of microservices in genAI systems. https://www.infoworld.com/article/4068388/pros-and-cons-of-microservices-in-genai-systems.html
[7] Cubic.dev. (2025). Context switching is killing your team’s velocity. https://www.cubic.dev/blog/context-switching-is-killing-your-team-s-velocity
[8] American Psychological Association. Multitasking and switching costs. https://www.apa.org/topics/research/multitasking
[9] McKinsey. The social economy. https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/the-social-economy
[10] Leroy, S. (2009). Why is it so hard to do my work? The challenge of attention residue when switching between work tasks. Organizational Behavior and Human Decision Processes, 109(2), 168–181. https://www.sciencedirect.com/science/article/abs/pii/S0749597809000399
[11] LangChain Team. (2024, December 14). Making it easier to build human-in-the-loop agents with interrupt. https://www.langchain.com/blog/making-it-easier-to-build-human-in-the-loop-agents-with-interrupt
[12] Futurum Group. (2026, January 15). Will Vendors Enable More Complex Agentic Workflows in 2026? https://futurumgroup.com/press-release/will-vendors-enable-more-complex-agentic-workflows-in-2026/
