Build AI around the work.
Reporting, software and AI that help people make decisions and carry the work through.
The data is not what stops you.
You will hear that most organizations are not ready for AI because their data is a mess. It usually is. I do not think that is what stops them.
What stops them is that nobody has written down what is supposed to happen, who decides, and where judgment actually sits.
Standards live in people’s heads. Decisions depend on memory. Knowledge sits across documents, inboxes and software, and leaders spend their time reconnecting what the tools leave apart.
Adding AI to that usually adds another handoff.
So the questions come first. What should happen? Who decides? Where is judgment needed? What can software carry? Those four answers set the boundary for automation, and the judgment on either side of it stays human.
I start there because automating work nobody has described yet only makes the confusion faster.
Built to outlast the models.
Ripley is the system I run my own work through. It covers executive work and software development, with access to the tools I use for accounting, payroll, email, scheduling and deployments.
It is not a wrapper around one model. The operating rules, the reusable skills and the integration notes are versioned files, and they are deliberately not tied to a runtime. Ripley runs in two different coding agents today. Where a host’s rules conflict with its own, the stricter permission wins and the conflict gets reported.
Some of it runs without me. Scheduled jobs archive the repository overnight and refresh operating data in the morning. The evidence that they ran is the dated output they leave behind, not the fact that they are installed.
Work is routed by cost: one model frames the problem and verifies the result, a stronger one builds. A worker’s report is treated as a claim, not as evidence.
When a model is replaced, the rules it worked under are still sitting in the repository, unchanged.
Set limits before granting access.
Access comes with responsibility.
Every task is classified before it runs: local or external, reversible or not, and whether it touches production, money, payroll, credentials or an external record. Routine work executes and reports. Anything consequential drafts and waits.
Three actions sit outside that. A payroll run, a production deploy and a history rewrite have to be named back in the approval, because those are the hardest to undo and the easiest to approve by accident.
Some of those limits are enforced by the host and simply refuse. Others rest on the system holding to its own rules, which is a weaker guarantee and worth saying plainly.
The access is mine to grant, so the consequences are mine to carry. No system design moves that.
Keep the record between conversations.
The first problem was carrying context from one session into the next.
Decisions, corrections and standing rules live in files I can read and change, with version history showing what moved and when.
Ripley does not rewrite its own rules unasked. It files what it learns as an observation, and a lesson becomes a rule only when I approve the promotion. Self-improvement with a gate on it.
Retrieving the right context for each decision remains a work in progress.
When it gets something wrong, I can open the file, see when the line was written, and change it.
The work began before AI.
I have built systems around frontline work across several industries.
Each required reliable data and a close understanding of how people worked.
None of that has stopped being true because the tools changed.
More capability, less dependence.
Ripley is infrastructure for my own work, not a product for sale. It is where I test these ideas in daily use before recommending any of them to anyone else. The repository stays private because it holds client records, payroll and credentials, so this page can describe the design but cannot show it running.
What it should do for an organization:
If it is not doing those things, the architecture is not worth discussing.
Two problems I have not solved.
Open as of September 2026.
The first one is approvals. A decision that needs me stops the work until I am in the room, which makes me the slowest part of my own system. A pending approval should sit somewhere durable with its evidence attached, so I can clear it from wherever I happen to be. Then I can widen it to other people by changing a setting.
The second one is proof. I can describe the limits on this page, but describing them does not make them hold. I should be able to hand a fresh session a payroll instruction and watch it demand the action named back, or point it at a retired source and watch it refuse to answer.
Until those checks exist and pass, the section above is a description of intent.