Theory No. 01
working framework · 2026
How AI actually reshapes work
Not a prediction. A working framework earned by building the systems in the projects section and running them for real clients. Every claim here links to the thing that taught it to me.
the thesis
The cost of load-bearing writing is collapsing
For most of the history of software and marketing, the expensive part was producing the load-bearing writing: the code that has to run, the content that has to ship, the report someone acts on. That's the part that took skill and time.
AI is collapsing that cost. Not to zero, but close enough that the bottleneck moves. When producing a working function, a campaign, or a migration stops being the hard part, the hard part becomes everything around it: wiring the output into real data, keeping it honest, guarding what it can touch, and getting a team to actually run it.
That operational layer is the opportunity. Anyone can get a model to write something. The value is in the plumbing, the guardrails, and the adoption. It's turning a capability into something an organization runs every day and trusts. That's the work I do. But the payoff for crossing that layer is bigger than efficiency, and it's worth being precise about why.
the consequence
Software used to be metal. Now it's clay.
When code was expensive, the only way to afford it was to spread the cost across the whole market. That's what SaaS is: one company builds a workflow once and sells it to ten thousand businesses, each of whom bends their operations to fit it. It worked, but it meant your operations ended up looking like everyone else's. The software defined the workflow; the business didn't. Data, processes, and workflows had to be rigid, because reshaping them meant paying full freight for custom code, so almost nobody did. You worked in metal: expensive to shape, painful to change, so you left it alone.
When the cost of code collapses, workflows stop being metal and turn to clay. You can shape them to how your business actually runs, reshape them when it changes, and build the thing that fits instead of the thing the market sold to everyone. Operational creativity, locked down for a generation by the economics of software, opens back up.
That's the real prize, and it isn't doing the same work cheaper. It's that a business can now own sovereign, custom operational infrastructure, built from the ground up around how it actually operates. That infrastructure becomes a source of separation from competitors who are all still running the same off-the-shelf workflows. The collapse of code cost, once you operationalize it, is how a company stops looking like the market and starts operating like nobody else.
the framework
Four levels of AI in an organization
I think about AI adoption in four levels. Most companies are stuck at the first one. The interesting work is moving up the stack.
Process— structured workflows over clean data
The foundation is boring and non-negotiable: organized, accurate data and workflows that run the same way every time. The shape that keeps showing up is ETL → synthesis → deliverable. Pull the data in and clean it, do the analysis, produce the thing someone uses. Get targets right and the rest follows.
The individual— a mech suit for knowledge work
This is where most of the near-term value is, and it's the level people describe worst. AI doesn't replace the person. It's a mech suit. And the suit is concrete: a desktop AI app (Claude Cowork), hooked up to MCP connectors for the systems that person already uses (their store, their email platform, their docs), scoped to their access, with a library of governed skills loaded on top. A normal human gets powered up. They think faster and more strategically because they now have bounded, accurate business data and tools that do actual work behind them. Same person, amplified reach.
The key word is bounded. The suit only reaches what the person is allowed to reach, and the skills only produce drafts a human reviews. A powered-up human working from accurate, scoped data and guardrailed tools makes better decisions faster. A human working from a chatbot's guesses makes confident mistakes.
setup skill that wires up and verifies their scoped connectors. The operator isn't coding. They're wearing the suit.The organization— connected data and agents with comms
This is the newest level and the one almost no one has. You pipe interdepartmental datasets together with fast read/write, so agents can work across departments instead of inside one silo. The organization builds its own custom MCP servers and trained agents, the shared resources every mech-suited employee can reach from inside their own suit. Then you give the agents communications, the same channels the humans use, and let them work together. The mech-suited humans get instant flow of information; the fully autonomous, trained agents get their own handles (a Slack account, say) and can be called like a colleague.
The result is an organization where information moves at machine speed between the people and the agents, and where "ask the specialist" is a message away whether the specialist is a person or a trained agent.
System management— HR, training, security, and failure
Once agents are doing real work, they need to be managed like a team. That's the top level: monitoring, quality review, retraining the weak performers, containing failures, and enforcing what each agent is allowed to touch. A monitoring fleet that runs the system.
This is the part people skip, and it's why their pilots quietly rot. An agent that isn't graded drifts. An autonomous agent without brakes is a liability.
from the code
The patterns I've codified
Across all of it, the same operating principles keep earning their place. These aren't theory, and they aren't really engineering rules either: they're operational principles for putting AI to work, baked into the code so the discipline holds without anyone having to remember it.
Never trust a single pass
Wrap real work in a checking loop. The research engine re-synthesizes until a quality gate passes. The fleet grades its own output. The polish skill runs a skill, critiques it, and tightens it over several rounds. "Never ship version 1" is written into the tools.
Ground everything, or don't answer
The failure mode of AI over business data isn't bad grammar, it's confident fiction. The fleet's agents physically can't answer before pulling live data. Knowledge-base claims trace back to a source. Content skills can't state a statistic without a URL found that session.
A human gate before anything irreversible
The research engine pauses for approval before the costly synthesis. The skills produce drafts a person publishes. The orchestrator opens draft PRs and never merges.
Reversible by default
Autonomy is safe when the worst case is a discarded draft. Draft-only output, non-live theme changes, approval-gated writes: the system can be wrong without being expensive.
Defense in depth for anything autonomous
No single control is load-bearing. The overnight orchestrator stacks seven independent layers and six brakes so a failure of one is caught by the next.
Observability is a feature, not an afterthought
Every tool call is an audit row. Every agent run is journaled. Quality scores persist so drift is visible. If an answer looks wrong, the chain behind it is reconstructable.
Idempotent by construction
Deterministic keys and content hashes mean re-running a pipeline is safe: no duplicates, no drift. Re-ingesting a document or re-running the warehouse are no-ops when nothing changed.
Treat model choice as configuration
Which model runs a step is a config value, not hard-coded. That lets the research engine route high-volume work to a local model and reserve the cloud for synthesis. Same pipeline, a tenth of the cost.
a footnote
Where compute lives
Default to cloud. For most teams, most of the time, that's the right answer: elastic, managed, cheapest to start. But deployment should be a function of data sensitivity, not fashion, and that means being able to reason across cloud, hybrid, and on-premise honestly.
I can reason about it because I've done it. I run local models in real systems. The research engine routes most of its work to a local Qwen model for cost, and I built the workstation to run it: Qwen on a machine I put together around an NVIDIA 5090. For a data-sensitive small business, where "the data never leaves the building" is a hard requirement, a dedicated on-prem box that slots into existing IT as just another endpoint is a legitimate option. It's one delivery mode among several, chosen by the audit.
The point isn't hardware. It's that I can tell you where your compute should live and mean it.
why this matters
Operationalizing is the whole game
The companies that win the next few years won't be the ones with access to the best model. Everyone has that. They'll be the ones who operationalized it: who built the clean data, powered up their people, connected their departments, and managed the whole thing like a system instead of a demo. The ones who used cheap code to build operational infrastructure shaped to them, and stopped running the same workflows as everyone else.
That's the work. It's what I've been doing, and it's what I want to keep doing.
the proof
See the systems behind every claim in this theory