Andrej Karpathy wrote that you can outsource the thinking but you cannot outsource your understanding. I would refine that further: you can outsource part of the thinking, not all of it. The understanding is always yours.
This distinction matters more than it sounds. The modern AI environment is noisy. Everyone is talking about AI, but only a small number of builders and AI translators are actually focused on the gap between model capability and real business outcomes.
In a single day, each of us has dozens of ideas. Only a few become action. Fewer still become something real that serves us or the people around us. The goal isn’t to stop thinking — it’s to let AI carry the extra load of thinking while we keep ownership of the understanding.
The “carrying the load” part is an extension of our own original thinking, not a replacement for it. AI should not replace your thought process and your judgment. Every output is a function of your prompt, your context, your understanding and your direction. The underlying concept comes from you. The work of comprehending, reiterating, and applying the output is also yours. AI accelerates the path between thought and artifact. It does not substitute for the thought itself.
That’s the philosophy. The name I’ve given it is the Caddy philosophy — borrowing from golf, where a caddy carries the bag, reads the course, advises on club selection, and stays quiet when the player needs to focus, but never takes the swing. The player commits the shot. The accountability and the judgment stay with the person who owns the outcome. AI should operate the same way: supportive intelligence that handles execution overhead while the human owns the decision and the result.
You don’t need to know golf to understand the principle. The point is the relationship — a tool that carries real load, respects user intent, adds substantive value, and stays out of the way when not needed. Most current AI products fail this standard in one direction or another, which is the rest of what this post is about.
Every business needs supportive intelligence
Every business, enterprise, and industry has different organizational culture, policy, tech stack, processes, products, customers, and services. What doesn’t change is the underlying foundational business process. The process itself isn’t complicated. What complicates it is that 8 billion unique individuals run those processes, each with their own context and judgment.
Businesses adopted SaaS over the past two decades because process owners ran into technical roadblocks they couldn’t solve without external tools. Each SaaS platform addressed a specific layer of the process from a specific angle. The result is the SaaS sprawl most enterprises now live with — many tools, many subscriptions, many integration costs, many siloed systems, each addressing a slice of the work but none addressing the whole.
Applied AI offers a different path. Instead of yet another SaaS subscription or another SaaS contract that addresses one more slice, organizations can deploy supportive intelligence that operates across the process itself, tailored to their specific context. Each business needs its own version because each business, service, and product is unique. The intelligence layer underneath can be the same general capability, but how it’s deployed — what context it has, what permissions it operates under, what workflows it touches — has to be specific to the organization.
This is why I started KindCaddy. Not because every business is on a golf course, but because every business needs supportive intelligence that knows the work, respects the boundaries, carries the load, and lets the humans commit the shot.
What gets the AI–human relationship wrong
The philosophy is easier to understand by what it isn’t. There are four common ways AI products get the relationship wrong, and each one is widespread right now.
- It tries to replace the user entirelyFully autonomous agents that wander off without customized context knowledge or enough input context based on the user’s understanding take actions the user didn’t intend, and produce outputs the user didn’t ask for. These products optimize for “look how much it can do without you” rather than “look how much we can do together.” They lose user intent because they were never trying to preserve it.
- It requires constant promptingChat interfaces that put all the cognitive burden back on the human. The user has to know exactly what to ask, how to ask it, and how to evaluate every response without losing track of the end goal. This isn’t supportive intelligence — it’s a vending machine that requires the right coins.
- It’s so autonomous it loses intent partwayThe system starts doing something the user asked for, then drifts based on its own interpretation, and finishes somewhere the user didn’t want to go. The user is left to either accept the drift or restart from scratch.
- It’s so passive it adds no real valueTools that just rephrase what the user already wrote, or surface information the user could have found in two clicks. These products fail in the opposite direction from the autonomous ones — they’re so afraid of overstepping that they never carry enough load to be worth using.
Supportive intelligence threads between these failures. Carry real load, but don’t take the swing. Add substantive value, but stay aligned with user intent. Be useful without being demanding. The balance is hard, which is why most AI products land in one of the failure modes rather than getting it right.
What this means for product design
If you believe in supportive intelligence as the right model, certain design decisions follow.
- Each user gets their own context and workflowApplied AI deployed inside an organization should be tailored to the user — their role, their access rights, their work. A shared, generic assistant serves no one well. In the platform I’ve been building, this shows up as per-user agent isolation: every user has their own agent state, their own context, their own delegation logic.
- It respects organizational boundariesDifferent roles in an organization see different information for good reasons — privacy, security, compliance, accountability. The platform implements role-based access control so each user’s assistant operates within their permissions, not outside them.
- It accesses the right context for each taskWe use MCP servers to inject business-specific context into the agent’s workflow, so each assistant can pull from the systems and data that matter for the specific situation. Without this, the AI is reading a generic course. With it, the AI is reading this organization’s actual situation.
- It is aware of costSending every task to the most expensive model is the equivalent of pulling out the most expensive tool for every job. The platform implements delegation logic that routes prompts to appropriately-sized models based on the complexity of the task. Simple queries go to cheap models, complex reasoning goes to expensive ones, and some tasks don’t need an LLM at all.
These aren’t abstract principles. They’re decisions you can point to in the code. Anyone evaluating an AI product against this standard can ask: does it respect the user? Does it carry meaningful load? Does it stay aligned with intent? Does it know when to be quiet? Does it choose the right tool for the job? Most current AI products fail at least two of these tests. The standard I want to hold my own work to includes all five.
Building the platform as a test of the philosophy
I should be transparent about how this platform was built. I don’t have a computer science background. I can read code, make small adjustments, and design systems architecturally, but I cannot write production code from scratch. What I did is direct AI tools to build the platform while I owned the design decisions, the testing, the verification and in-depth cross-system understanding that the result actually worked.
This is not a confession. It is a demonstration of the philosophy. I used AI to carry the load on code while I owned the understanding. I broke the problem down into concepts and steps, input detailed context, evaluated the responses, and integrated the understanding before moving forward.
A specific example from when I started building this platform last year. My first prompt looked something like this:
Can you provide me a standard web app structure in a flow chart diagram that also includes data flow between systems? My goal is to implement a web app where users access through a standard login page with industry-standard security functions that connect with a backend’s multi-tenant structure. What security functions do I need to be aware of (front end and server side)? Break these functions down in simple explanation and create examples of how each impacts the end user.
Then I read the output thoroughly until I fully understood the user-end impact of each security function. Only after I understood did I move to the next layer of implementation prompts. When I wasn’t sure about something, I would ask follow-up questions: “Can you provide a real-world case of how this function impacts output quality? How crucial is this function’s role in the system I’m creating?” The questions weren’t about delegating the thinking. They were about deepening my understanding so I could direct the next round of work better.
This is how the platform was built — concept by concept, layer by layer, step by step, with AI carrying the load of code generation while I carried the load of judgment. The philosophy is self-applied.
I should be honest about this post too. Writing has never been one of my strengths. I brought the concepts, the experience, the philosophy, the examples and the structure to this post. I used AI to help refine the prose, the same way I use it to refine code. The thinking here is mine. The expression of it got polished with help. If supportive intelligence means anything, it means I shouldn’t be performing solo writing when I’m not a strong writer, any more than I should be performing solo coding when I’m not a strong coder. Use the right tools for the right load. Keep the understanding.
There are real limits to this approach, and I want to name them. Vibe coding — pasting prompts into AI tools without understanding what’s being built — produces fragile systems that break under stress and can’t be debugged. To direct AI tools effectively, I need to understand the systems at the architecture level. I need to know how role-based access control actually works across files, how authentication tokens protect user sessions, how credentials should be stored, why some functions break under load that others don’t. I don’t need to write the code, but I need to understand it well enough to evaluate whether it’s correct and pinpoint specific issues when something needs to change.
Where applied AI needs to go
The gap between model capability and enterprise business outcomes is the defining problem of applied AI right now. Models keep getting more capable. Most enterprises still cannot translate that capability into measurable impact on revenue, costs, or operations. The gap is widening.
Closing it requires builders who think about AI as supportive intelligence embedded in business processes with humans at the center. It requires platforms organizations actually own, not another SaaS dependency layered on top of existing SaaS sprawl. It requires honest evaluation of where AI adds real value versus where it just adds noise. It requires preserving human judgment at the points where judgment matters.
The future I want to build toward is one where businesses run internal, centralized platforms that deploy tailored agents across workflows. Agents trained on specific enterprise knowledge. Token-cost control by designing a traffic-delegation process between locally hosted models and API calls. Governed by clear guardrails. Audited through proper evaluation processes. Designed to elevate the people who work with them rather than replace them. The dollars that move out of SaaS contracts and external consulting spend move into human capability and ownership of the work. The business gets faster, more capable, and more itself.
Every business needs supportive intelligence. Not another autonomous system that takes over. Not another chatbot that just answers questions. Real intelligence that knows the work, respects the boundaries, carries the load, and lets the human commit the shot.
That’s the philosophy. That’s the platform I’m building. And that’s the work I’ll be doing for as long as it takes to make it real.