ATOM Thesis
A model for making enterprise AI useful.
The model is rented. The middle is owned.
AI access is everywhere. Adoption is still hard. ATOM is the method I use to make the work explicit: what the tools can see, what they may do, who reviews the result, and how the business knows whether the spend paid off.
The point is not to chase whichever model is loudest this week or build software for its own sake. The point is to make the work clear enough that a company can run it, review it, remember it, and improve it.
The economics
Spend is visible. Value is not.
Enterprises have bought access to powerful AI tools. The gap is not another model. It is the work around the tools: context, action, review, evidence, memory, and the next investment decision.
ATOM makes that work visible, measures it through six pillars, and uses the evidence to decide what should stay inside existing tools, what should stop, and where owned software or custom agents are worth building.
Spend to proof
The gap is not a missing model. It is missing work evidence.
Spend is counted before the business can prove whether work improved.
Visible spend
Seats, tools, model calls, pilots, and review effort.
Measured work
Context, control, memory, performance, portability, and cost.
Investment proof
Renew, expand, stop, configure, or build with evidence.
Configure the tools already in the stack where they cover the work.
Cut pilots, agents, or habits that create activity without proof.
Commission owned software only where the evidence shows a real gap.
01 / The missing middle
The four-layer model keeps the conversation simple.
Most enterprise AI work has the same four parts whether anyone names them or not: rented tools, daily work, the review and memory layer, and the systems and sources underneath. The middle matters because it is where behavior actually changes.
02 / What stays separate
Not every part of the method is the product.
ATOM has to keep the framework, the delivery method, the internal tools, and customer software separate. Otherwise the conversation gets muddy: the model sounds like a product, the delivery scaffolding sounds like customer software, and a custom build gets implied before the gap is proven.
Framework
How to look at the work: context, control, evidence, ownership, and measurement.
Delivery method
The sequence for choosing the scope, setting a baseline, configuring tools, measuring use, and deciding what comes next.
Internal tools
Tools that keep the engagement consistent. They do not automatically become customer software.
Customer software
Only where the evidence justifies it: approved source lists, context rules, review steps, readouts, and custom agents.
03 / Native first
Use what the stack already gives you before building more software.
Microsoft, Google, OpenAI, Anthropic, and the surrounding enterprise platforms already provide valuable controls. The first job is to configure those tools against the real work. Custom software enters the frame only after the existing tools and the method leave a real gap.
Identity, admin controls, connectors, analytics, audit logs, retention, built-in skills, and runtime controls.
Policies, data classification, source approval, role priorities, KPIs, risk tolerance, and the definition of success.
Discovery, configuration design, approved sources, context rules, baseline data, receipts, readouts, and decisions about what to keep, stop, or build.
04 / The engagement
Crawl, walk, run - paced by evidence.
The engagement starts with a clear boundary and then moves in gears. Crawl establishes the foundation, Walk puts real users into approved work, and Run decides what expands, stops, changes, or becomes software.
Gate
Alignment and scope
Pick the first part of the business, the owners, the tools involved, the proof point, and what is explicitly out of scope.
Crawl
Foundation
Inventory tools, sources, roles, context, policy, skills, and agents. Configure what the existing stack already does.
Walk
Active use
Real users do real work through approved context, playbooks, contracts, receipts, and readouts.
Run
Decide what comes next
Decide what expands, what stops, what changes, and what becomes customer-owned software or custom-agent work.
05 / Measurement
The readout shows what leaders can manage.
A pilot is not a proof point until leaders can see what happened. The readout makes cost, context, control, memory, performance, and portability visible enough to manage.
06 / Software
Build software only where it earns its place.
There is real software behind the method, but it has two different jobs. First it maps the current work and shows the gaps. If the gap is real, the company keeps software for approved sources, review steps, receipts, retrieval, and ongoing checks on its own data.
07 / Expansion
Custom agents come after the work is understood.
The first engagement gives the business a working part of the workflow and a clear map of what comes next: expand the use case, configure existing tools more deeply, build customer-owned software, or commission custom workflows and agents. The evidence decides.
Where it shows up
The projects make more sense when the model is clear.
Founder OS runs the method inside my own business. Joan is the company direction. Sidekick is the meeting and revenue product family. VibeOS carries the same discipline into AI-assisted engineering.
Founder OS
The method running my own business: briefs, workers, review queues, research, meeting prep, and follow-up.
Joan
The product direction for shared context, evidence, memory, controls, and agent management across work.
Sidekick
The first product family: meeting and revenue workflows where context, commitments, closeout, and team memory carry forward.
VibeOS
The engineering side of the same thesis: build discipline, evidence, tests, and handoff quality around AI-assisted work.
Customer-facing sites
See the public product sites.
This page explains the operating model. These are the customer-facing sites that show how the Sidekick products are packaged outside this portfolio.
Recent writing
Recent writing on the same thesis.
The position
The model will keep changing. The business still needs to know what happened, why it happened, who reviewed it, and what should be remembered.
ATOM is the implementation model for that middle: use existing tools first, measure the work, build only where the gap is real, and keep ownership with the customer.