The Processing Layer Is Not a Moat
A few months ago, a friend booked a meeting room at a coworking space in Nashville and invited anyone interested in AI to come talk shop on a Friday morning. No agenda, no slides - just builders comparing notes on what’s actually working.
One of those Fridays, a conversation about MCP - Model Context Protocol, the mechanism that lets AI agents interact directly with tools like Jira, Sentry, and GCloud - sent me home to rebuild my entire engineering workflow. I wrote about that in Eliminating Waste in the SDLC . The short version: I gave Claude Code access to the same tools I use, and 12 hours of manual work per week disappeared.
But the deeper I got into that work, the more an uncomfortable question started forming. It wasn’t about productivity. It was about defensibility.
What I Built
I’m the sole engineer at an ed-tech startup. I also run a personal portfolio of more than twenty projects - a Rails web app, an iOS app, a macOS app, Hugo sites, a knowledge management system, a transcription tool, family utilities. One person. No team.
To make that work, I built a system of Claude Code skills that automate the parts of the SDLC that used to eat my days:
/devops - a production health check that runs 17 parallel checks across GCP infrastructure, Sentry monitoring, GitHub Dependabot alerts, and Jira tickets, then cross-references everything and produces a triaged action dashboard. What used to take 100 minutes of manual console-hopping happens in under 5 minutes. I run it every morning.
/review-pr - a review-comment triage system. When I built it, three AI reviewers (Copilot, CodeRabbit, Gemini Code Assist) ran on every PR, generating 8-15 comments each. Most were noise - style nits, scope creep, bikeshedding. The skill fetched every thread, classified them into four severity tiers, auto-fixed the real issues, dismissed the noise, committed, pushed, and kept a per-PR log with a diminishing-returns detector that flagged when the bots were just arguing with each other. All three of those bots have since sunset, run dry, or gone quiet - which proved the point better than the skill did. The reviewers were interchangeable. The triage system wasn’t. Today a second agent, never the author, plays the adversary on every PR, and the pipeline runs the same.
/dispatch - a multi-agent orchestration system. I describe what needs to happen across the portfolio. Agents spin up in parallel, each working in an isolated git worktree, each reading the target project’s documentation for context. They create pull requests. They never merge. Human review is non-negotiable.
Persistent memory - a file-based system where the AI remembers who I am, how I like to work, what decisions we’ve made, and what feedback I’ve given. Every conversation starts with full context. No re-explaining.
Gherkin specifications - acceptance criteria written before implementation begins, derived from an audit of 250 PR review comments that revealed 50% were preventable mechanical issues. The specs are encoded into the environment. Agents can’t violate rules that are in their context.
The measured savings: 733 minutes per week. 12.2 hours. A day and a half of engineering time, recovered.
That number felt like the story. For a while, it was.
The Uncomfortable Pattern
Over the past year, I’ve watched a pattern repeat across the startup landscape. Funded companies - good teams, real problems, experienced founders - building AI-powered products that process domain-specific documents and surface structured insights through a chat interface. The pitch is always some version of: “We use AI to make sense of messy, unstructured data.”
And increasingly, I have the same quiet thought: I could build a meaningful version of this in a weekend.
Not a production system. Not something with enterprise compliance and a sales team. But the core value proposition - take documents, extract structured data, let people ask questions about it - that’s a weekend project now. For anyone with API access and domain knowledge.
The smart founders know this. The underlying capability is commoditizing faster than anyone expected. They’re convicted about the market opportunity. The harder question - the one that keeps surfacing - is what makes any particular team the one that wins, when everyone has access to the same models.
Processing Is Not a Moat
Here’s the pattern I keep seeing:
- Startup identifies a domain with messy, unstructured data
- Startup builds an AI pipeline to process those documents - OCR, extraction, embedding, retrieval, chat
- Startup raises money on the promise of that processing capability
- Six months later, the processing capability is table stakes. Every competitor has API access to the same models. The pipeline is a commodity.
The processing layer is not a moat. It never was. It just looked like one when the models were new and the API access was scarce. Now everyone has the refinery. The question is who owns the crude.
This isn’t hypothetical. I watched it happen in my own workflow. When I first built the /devops skill, it felt like magic - 17 parallel checks, cross-referenced, triaged automatically. Three months later, anyone with Claude Code and MCP servers could replicate it in an afternoon. The skill isn’t the moat. The compound context around it is - a year of saved reports, institutional knowledge about which Sentry issues recur, which endpoints degrade under load, which Jira tickets are really the same bug filed three different ways. That context makes each run more valuable than the last. A fresh copy of the skill, without the context, is dramatically less useful.
Where the Moat Actually Lives
If processing isn’t defensible, what is?
Proprietary data. Structured knowledge that doesn’t exist anywhere else. Not raw documents - anyone can get those. The structured output of processing those documents over time: the validated relationships, the resolved ambiguities, the institutional decisions that turned messy inputs into clean, trustworthy outputs. That’s the crude. The raw documents are just dirt you haven’t refined yet.
Workflow entrenchment. When your tool is part of someone’s daily process, when their operations are built around your output format, when switching means retraining and rebuilding - that’s a moat. It’s boring. It’s real. Microsoft didn’t win because their spreadsheet was better. They won because everyone’s workflows assumed Excel.
Compound context. Every interaction makes the system smarter in ways competitors can’t replicate by cloning the code. My /devops skill gets more valuable every week because the historical reports create a baseline. A new issue isn’t just “new” - it’s “new relative to the pattern we’ve seen for six months.” That’s not in the prompt. It’s in the accumulated data.
Domain expertise encoded as system behavior. Not prompts - prompts are not IP. Rules, validations, cross-references, edge case handling baked into the architecture. The pre-flight checklist I built from auditing 250 PR comments isn’t a prompt. It’s institutional knowledge encoded as environmental constraint. It took months of production experience to derive. A competitor can’t copy it because they haven’t made the mistakes that produced it.
Data Is Still the New Oil
Clive Humby said “data is the new oil” in 2006. Twenty years later, it’s more true than ever - and the metaphor has gotten sharper.
LLMs are the refinery. Two years ago, access to the refinery was the competitive advantage. You had to build your own extraction pipeline, your own embedding system, your own retrieval architecture. That was hard, and being good at it mattered.
Now everyone has access to the same refineries. Claude, GPT, Gemini - the processing capability is a commodity. The API costs are dropping. The quality is converging. Building an extraction pipeline is a weekend project for a competent engineer with Claude Code.
So the moat moves upstream. It always does. When refining was scarce, the refinery was the moat. When refining became commodity, the crude became the moat.
The question every AI startup should be asking isn’t “how do we process data better?” It’s “what data do we own that nobody else has, and how does every customer interaction make that data more valuable?”
If the answer is “we process documents better than anyone” - that’s a feature, not a company. The model will do it natively in 18 months.
If the answer is “every document we’ve processed makes the next one more accurate, and our customers’ daily workflows are built on our output” - that’s a moat. A real one.
What I’m Building Differently
This thinking changed how I approach my own work.
I’ve been building a life-tracking application called Silo since 2016 - a decade of continuous development. It captures experiences, places, activities, photos, and contexts. The moat isn’t the app. Apps can be replicated. The moat is the data: a decade of someone’s life, structured and searchable, owned entirely by them.
In an AI world, that data becomes dramatically more valuable. The more of your life you capture, the smarter the system gets - and that intelligence is built on your data, not a generic model. Nobody can replicate it by building a better app, because the value isn’t in the app. It’s in the irreplaceable, deeply personal dataset that only exists because you’ve been using it for years.
The same principle applies to my engineering workflow. The skills I’ve built are open - anyone could write a /devops check. But the year of compound context - the memory, the historical reports, the accumulated decisions, the feedback loops - that’s mine. You can copy my tools. You can’t copy my context.
The Compounding Loop
There’s a Toyota Production System concept that ties this together. Ohno didn’t eliminate waste once. He eliminated it continuously - standing on the factory floor, watching the same processes, finding the next margin to remove. Each pass revealed the next layer that was previously invisible.
AI accelerates that loop. When you can hand your tools to an AI agent and let it operate them directly - not through you as a bottleneck, but alongside you as a parallel operator - the iteration cycle compresses from weeks to hours.
But here’s what I’ve learned this year: the tools aren’t the most important compounding loop. The conversations are.
This blog post exists because Pete Swan
booked a room at Switchyards. The /devops skill exists because John Rembold
showed up one Friday and we talked about MCP. I run Claude in Ghostty
because Nathan Gonzalez
suggested I try it. Each conversation compounded into something I use every single day.
The tools will keep getting better. The models will keep getting smarter. But two things actually compound:
Systematically identifying and eliminating waste - standing on the factory floor, watching the work, refusing to accept motion without value.
And talking to other builders about what you’re learning.
The processing layer is not a moat. The data is. The context is. The community is. Everything else is refinery access - and everyone has that now.