Longer thinking lives here. The papers and posts behind the work: AI memory systems, real operations, and the lessons that only show up after you ship. Open any piece to read it in place, or jump to the original post to weigh in.
Jun 11, 2026AI systems
Every directory needs a janitor
Everyone wants to feed their AI more context. Almost nobody talks about cleaning up after it.
Everyone wants to feed their AI more context. Almost nobody talks about cleaning up after it. Faster ingestion. More docs. Bigger directories. The advice is always about what to add. After running this pattern for six months, the part nobody mentions showed up.
A knowledge base needs a janitor.
Jason Griffing wrote about the context flywheel a few weeks back. The framing landed for me because it named what I had been building without naming. Append context, capture decisions, link past work to current work, and the directory becomes a substrate the AI can think against rather than just retrieve from.
What I kept hitting underneath that is the thing the flywheel framing alone did not solve: Append-only context grows. It does not pressure-test. Old decisions go stale. New context contradicts old context. The flywheel keeps turning. The directory rots.
The fix I have been working through is a reconciliation pass. Every new piece of context, whether a call transcript, a session recap, or a drift signal, does not just get appended. It re-reads the existing directory and surfaces what should change, not just what to add.
Concrete example from last week. A version reference for the AI substrate moved from v0.10 to v0.11. Two different surfaces in the directory still said v0.10. Neither was the canonical source. The canonical source had already been updated.
Without the reconciliation pass, those surfaces would have stayed wrong. With it, the catch happened on the next ingestion. Five minutes of correction. No confusion downstream.
What makes this work is not the AI doing the reconciliation. It is the architectural primitives underneath: Append-only forensic logs that never lose history. Forward-only linkage where every deferred decision pairs with a named trigger. Schema versioning so the system knows when an old-shape note needs special handling. An edit-source loop, so when a recurring brief needs adjustment, the fix lands at the source, not the brief. Stable IDs so retrieval results survive title renames.
The flywheel is the engine. The reconciliation pass is the discipline that keeps the engine from grinding itself apart.
Most knowledge-base setups in the integrator channel will not need this for a while. But the ones building substrate, not features, will hit it the same way I did. Six months in. Wondering why the directory feels heavier than it should.
Worth knowing the fix exists before the rot starts. Credit to Jason Griffing for the framing that surfaced this for me. The context flywheel was the right mental model. The reconciliation pass is the discipline I would add to it.
Nobody is building systems
Most people I see are using AI as a chat window. Ask it a question, get an answer, close the tab. The more advanced ones are using AI for email drafts, proposal language, or quick research. Some have built something like a single function app or one tool that does one job.
Nobody is building systems.
What I keep seeing when people do go further is AI features bolted onto existing workflows. A transformer here. A chatbot there. Each one a separate service. Each one re-asks the same context questions every time. None of them remembers anything across a week.
That's not an AI strategy. That's a list of vendors.
The shift I've been working through is harness engineering. Three separable layers that each fail differently and can each be replaced without rebuilding the others.
The Brain thinks: models, memory, embeddings. The Muscle executes: scheduled tasks, workflows, delivery surfaces. The Playbook governs: standing instructions, decision logs, audit trail.
In our deployment, the Brain is a local LLM running on our own hardware. No cloud, no data leaving the building. The Muscle processes field tech daily notes and pushes structured site documentation back to the team. The Playbook keeps the whole thing running the same way six months from now as it does today. Nothing about a client's home ever leaves the building.
What the harness buys isn't speed. It's coherence over time.
A year from now the model will be different. The delivery surface will be different. There will be things in the system we haven't built yet. Three layer separation means none of that requires a rebuild. Just component swaps.
This is the part of the curve where the channel splits. Some integrators are building systems. Most are still opening tabs. Those are not the same business in three years.
A better harness, not a better prompt
I spent two weeks tweaking prompts trying to fix an output problem. Turns out I was solving the wrong problem.
The field report transformer I've been building started as a single pass. Raw tech notes go in, structured documentation comes out. One prompt doing all the work: shape the data, analyze it, format the output, deliver it.
It worked... sort of. Outputs were inconsistent. Critical details got buried or dropped entirely. Some reports came out clean, others came out as well-structured noise. Each round of prompt revisions fixed one thing and broke another.
I kept tweaking. Different phrasing. Better examples. More specific instructions. Marginal gains, no real fix.
Then I stepped back and looked at what I was actually asking the model to do. I wasn't giving it one job. I was giving it four jobs in a single instruction and hoping it would prioritize them in the right order.
That's not a prompting problem. That's an architecture problem.
So I re-designed it. Instead of one pass doing everything, the new design splits the work across multiple specialized passes. One pass to shape and normalize the raw input. One pass to analyze and extract the critical information. One pass to structure and deliver the final output. A validation step before anything ships.
Each pass has a focused job. The output of one becomes the input to the next. The model isn't smarter. The system around it is.
This is what I've been seeing referred to as prompt orchestration or harness design in some of the more current AI systems writing. Engineering the workflow around the model instead of trying to force the model to handle everything in one shot.
The early results from the multi-pass beta are exactly what we were missing in version one. Consistent structure. Critical details preserved. Outputs that hold up under management review.
Still iterating. Still learning. But the lesson sticks. When prompt engineering hits a wall, the answer usually isn't a better prompt. It's a better harness.
When the grind stops scaling
At some point "just put your heads down and grind" stops working.
For us it was the plateau. We had built the company the way most small businesses do, on sheer will and long hours. But at some point that stops scaling. We weren't stuck, but we weren't moving the way we needed to. And we both knew the way we'd always operated wasn't going to get us where we wanted to go.
So we brought in a certified EOS Worldwide implementer, shoutout to Dave Riley, and committed to running the Entrepreneurial Operating System.
I'll be honest. I was in but skeptical. Not about EOS, about us. Whether we'd actually follow through. Whether we'd stay disciplined when things got uncomfortable.
And things did get uncomfortable.
Those first meetings were raw. Frustrations that had been building for years finally had a structured place to land. It wasn't always clean. But it was real, it was on the table, and we worked through it together.
That's the part nobody tells you about EOS. The framework doesn't just organize your business. It surfaces what's actually been sitting underneath it.
On the other side of that: a team that's aligned. Everyone top to bottom knows the direction, knows the goal, and knows their role in getting there. We're not just moving, we're moving together.
That shift doesn't happen from a whiteboard session. It happens when you commit to the process even when it's hard.
The EOS Model is a trademark of EOS Worldwide, shared here as it appeared in the original post.
The repeater in the attic
There's a repeater in someone's attic right now that nobody can find.
It's been there for years. The tech who installed it has moved on. The project notes say "repeater in attic works great." The client is calling because it doesn't anymore.
This is the knowledge problem in field services, and it's not about bad documentation. It's about documentation that was never designed to be a knowledge system.
We've had field reports sitting in project notes for years. Every job, every day, every tech. The data exists, but finding one specific detail across hundreds of entries still meant digging and the quality of what you found depended entirely on who was at the keyboard that day.
I've been building toward a solution in a few parallel tracks.
The first is structured training, giving techs the foundational knowledge so fewer things live only in one person's head. That's the training courses I posted about last week.
The second is a field report transformer, an AI layer that takes raw tech notes and restructures them into consistent, searchable documentation. It's in active beta right now. Each week management reviews both the inputs and outputs to tweak the transformer prompting to get the crucial, usable data we need.
The third is the architecture that connects all of it, a knowledge base that ingests the transformed daily reports, SOPs, and other project docs so the next tech walking into a house has real context at their fingertips.
None of this is finished. But it's moving, and the direction is clear.
The goal isn't to replace experience. It's to make sure experience and crucial information doesn't just walk out the door.
Teaching techs how networks actually work
Something I've been working on that I'm genuinely excited about: a structured networking fundamentals course built specifically for residential integration technicians.
Here's the problem. Our industry trains people on installation. Terminations, rack builds, device config. But we send techs into homes with enterprise-grade network infrastructure and expect them to troubleshoot without ever teaching them how networks actually work.
So I built a curriculum that starts from the ground up. What a VLAN is and why it matters, how PoE budgets affect device planning, what's actually happening on the network when a client says "my internet is slow."
But it's not just about networking knowledge. It's about giving people a path.
The new tech who starts on prewire shouldn't feel like that's where they stay. And the senior tech who's great with their hands but never had formal training on the infrastructure side deserves a chance to level up. For their own career, not just for the company.
Cross-training makes the whole team stronger. But more importantly, it shows people you're actually invested in where they're going, not just what they can do for you today.
Version 1 is live right now with our field team beta testing it. I'm currently refreshing my inbox every 30 minutes waiting on quiz scores like a nervous professor on finals week.
Early days, but the goal is real structure around professional development. Not just "shadow the senior guy for a week." Future versions will tie into actual performance metrics so we can measure what's working and keep building from there.
If you're in the integration space and your training program is still "figure it out," I get it. That's where we were too. But the tools and frameworks to do this right are more accessible than ever. Happy to share what I'm learning along the way.
