AI & Systems Consulting
Most consultants default to agents because it sounds impressive. I do the opposite.
The first question I ask is whether you actually need AI — or whether a reliable process solves the problem without introducing a system that breaks under edge cases. That triage is the work. Three problems below.
01 — Organization and behavior change
Most productivity and AI adoption efforts treat organization as a filing problem. It is not. Research in behavior change science is clear: lasting change requires satisfying fundamental psychological needs, competence, autonomy, and connection. Skip those and you get compliance without capability. People use the new system for two weeks, then revert.
The teaching philosophy I apply here is grounded in the same principles I use in clinical coaching: build genuine skill first, then independence follows naturally. The goal is not to hand someone a workflow. It is to build the mental model that lets them maintain and extend it themselves.
This is where every engagement starts, before any tool is selected or any system is built.
What this looks like
Honest assessment of the current state
Not what the system should look like in theory. What is actually happening, where things are breaking down, and why.
Structure matched to how people actually work
Folder hierarchies, context files, and knowledge bases built around existing habits, not idealized ones that collapse under pressure.
A mental model, not a manual
When people understand why the structure works, they extend it. When they only know how to follow it, they abandon it the first time something does not fit.
The common mistake
An organization buys an AI subscription. Someone demonstrates it in a meeting. People are told to use it. Three months later, usage has dropped off. The tools were capable. The problem was never defined.
A hammer used well can build a house. Used without a blueprint it just makes noise. The blueprint is the work.
02 — Problem definition before tool selection
Most people approach AI by asking "what can this tool do?" The more useful question is "what problem am I actually trying to solve, and what kind of thinking does that require?"
This distinction matters because the same tool can either accelerate your thinking or replace it with something that looks right but is not. The difference is whether the problem was defined before the tool was opened.
I work with individuals and teams to articulate what they are trying to accomplish at the level of thinking, not just output. From there, the right instrument becomes obvious. Sometimes it is a well-structured prompt. Sometimes it is a different tool entirely. Sometimes it is a folder.
03 — Systems implementation
In the coaching work I do with athletes, there is a distinction between preparation and expression. Preparation is the intentional training that builds the buffer: stronger tissue, broader capacity, more resilience. Expression is what you actually want to do with your life and work. The training exists to serve the expression, not the other way around.
The same principle applies to systems work. The system I build is not the goal. It is the preparation that raises the ceiling on what you can express. We move as fast as we can with the governor on, because the real constraint is not ambition but sustainability.
Implementation means the system is running, documented, and maintained without me. Your team owns it. When the next model drops, or the next tool changes, the foundation stays intact.
What changes after
Context re-explained every session. Files scattered. AI used reactively, for isolated tasks, producing output that requires significant review and revision.
Context lives in the structure. The right files travel with the right work. AI is used for the 10% that requires language and judgment. The other 90% runs on rules.
The ceiling rises. What was previously impossible, given time constraints, cognitive load, or team capacity, becomes routine. The work you actually want to do expands.
The work in practice
Organization size changes the complexity of rollout, not the underlying framework: structure matched to how people actually work, a mental model they can extend, documentation that survives the first time I'm not in the room.
Active Life
Two years building curriculum, co-developing client software, and writing the company's first nutrition coaching standards at Active Life — a coaching company operating across North America and internationally. The work was designed to scale: systems that functioned with or without me in the room.
01
A short intake covering your situation, your current process, and what you have already tried. The more specific you are, the more useful the response.
02
What the actual problem looks like, whether I am the right person for it, and what addressing it would take.
03
Scope in writing before anything starts. You own everything we build. Documentation included. Thirty days of availability after delivery.
No. The systems I build are documented in plain language and your team uses them without touching code. If you want to learn the technical side, that is available, but it is not required for the work to function.
For sensitive use cases, I default to local deployment: models that run on your own hardware, data that never leaves your environment. For cloud integrations, API-only access with no training opt-in. Your data does not get used to train any model.
Businesses where at least one process involves repetitive information handling: documents, client communication, internal knowledge, reporting. Also research teams, healthcare-adjacent organizations, and media operations where data reliability and auditability matter. Industry is less important than workflow structure.
That is the point of building this way. Your business logic and context live in files, not in the AI layer. When a model updates or a better one becomes available, the swap is a configuration change. The underlying system stays intact.
Workshops are a single session. Workflow builds typically run two to six weeks depending on scope. You will see a clear timeline before anything starts.
Describe it specifically. You will get an honest read on whether there is a fit, and if there is not, I will say so directly.
Start a conversation
