The smartest thing in your AI is the part that says "I'm not sure." Most people ship AI that always answers. They train it, test it, deploy it, and expect it to handle every case. The reliable ones ship AI that knows when to stop. We built a lead qualification system for a financial institution. The AI's job: decide if an incoming lead is valid or fraudulent. But we didn't force it to make a binary call every time. When it has enough signal → routes the lead to sales. When confidence is low → a second agent fires automatically. Sends the prospect a follow-up form. Asks more questions. Collects more data. Only when there's enough to make a real decision does a salesperson even see it. Result: the sales team is 70% more efficient. Not because they're working harder — because they stopped chasing leads that were never going to convert. The bottleneck in most AI deployments isn't the model. It's that nobody gave it permission to say "I need more information before I decide." Build AI that knows what it doesn't know. That's where the reliability lives.

Two weeks of Phos AI Labs. The companies that will lead their categories two years from now are making the right AI decisions in the next twelve months. My prescription: start with the strategy. Build on what's real. Stay through the window where the P&L moves. That is where this firm is built to show up.

Going live on June 18th at 1 PM Central / 2 PM ET on the four phases of AI adoption; with Jordan Katon and West Cruz from Rising Ground. The AI Blueprint framework included. Registration link in the first comment.

Three convictions I bring to every client: Compounding: build what gets sharper over time. Judgment: tell clients what they need to hear. Even mid-engagement. Restraint: knowing what not to build is the strategy. The roadmap goes first. Every time.

40,000 companies applied to the Claude Partner Network. We're in. Not because we wrote a good application. Because Anthropic checks whether you've actually shipped Claude into production for real businesses, not slides about it. 300 apps built. That history is the only thing that gets you through that door.

Spent the weekend wiring up something inside Phos that I should have built six months ago. Every client engagement now has its own Claude Project. The Project has: the client's context pack, their voice guide, their workflow map, every meeting transcript from the engagement, every deliverable we've produced. The whole team has access. Before this: each of us had our own Claude tabs. Same questions answered slightly differently across the team. Nobody could see what anyone else had asked. After this: a junior on the team can ask Claude "what did we recommend to the manufacturer in week 3 about IT pushback?" and Claude can answer from the actual project history. Took maybe four hours of setup. Took six months to admit I needed to. The lesson keeps repeating itself: AI tools work in a company when the context is shared. Without the shared context, every person is running their own private experiment. Productivity goes up for one person and the firm doesn't change. If your company has 5 people using AI individually and nobody can see each other's work, that's the next thing to fix. DM me if you want to talk through how.

A client came to us with a Claude bill they couldn't explain. Several thousand dollars. No one on their team knew why it was that high. We dug in. Everybody had access to the same model — Opus, the most expensive one. And they were using it for everything. Including translating text. Nobody had set it up that way intentionally. It was just the default. Nobody questioned it. This is more common than people think. Companies roll out AI, give everyone access to the best model because it feels like the right call, and then wonder why the bill doesn't make sense. The fix isn't using less AI. It's routing. We set up tiered access — developers get stronger models for complex tasks, everyone else gets what they actually need. Then for the workflows that vary in complexity, we added an orchestrator: a lightweight agent that reads the task and decides which model handles it. Hard problem? Opus. Simple output? Something cheaper. Their bill dropped. The output quality stayed the same. Most AI rollouts skip this entirely. The question isn't just "are we using AI?" It's "are we using the right intelligence for the right task?" That distinction is worth thousands of dollars a month.

Three months into an engagement last year, I told the client to stop building something they had already started. The proposal review process they wanted to automate was the one place where a senior partner's judgment was the product. Automating it would have replaced the thing clients were actually paying for. My recommendation: build around it instead. That partner's judgment is now encoded in every proposal the team produces. The system makes it scalable without replacing what makes it valuable. The most important call I made in that engagement was the one where I said stop. Knowing what not to build is the strategy. The clarity always comes before the code

Two years ago we were a no-code shop. Bubble, Glide, FlutterFlow. Then we started using and building with Claude, even back then when Claude was an unknown player and the only known one was ChatGPT (OpenAI). So we went all in. Retrained the team. Rebuilt how we scope work. Started a sister practice, Phos AI Labs, just for companies that want AI woven into how they operate, not bolted on the side. This week that bet got validated in a way I didn't expect: Anthropic invited us into the Claude Partner Network. The lesson isn't "pick the winning model." It's that when you commit to a tool fully instead of dabbling, you end up in rooms you couldn't have bought your way into.

A $24M manufacturer told me last quarter that his "AI pilot" was on its fourth restart. Same pattern every time. The pilot was a tool. A workflow stitched together in n8n, a Claude license for the ops team, a Slack channel where someone was supposed to "monitor adoption." Three months in, the ops team had quietly stopped using it. The owner asked what went wrong. Nobody had a good answer. Here is what went wrong. The company had no AI foundations. No operating manuals the AI could read. No context pack about what the business actually does. No voice guide. No documented workflows. The pilot was a tool sitting on top of nothing. The AI sounded generic because the company hadn't told it who it was. The fix isn't a bigger pilot. The fix is the order. Foundations, then training, then a shared workspace, then operations. The pilot wasn't the wrong idea; it was the wrong step one. Every Phos engagement starts with the foundations because we have watched too many pilots die on the same hill. If you have an AI pilot that keeps restarting, that is the actual signal. DM me "30 mins" and I'll send you a link to a no-deck conversation about what's stuck.

We just got invited into the Claude Partner Network. 40,000 firms applied. Anthropic is putting $100M behind the ones they let in. I'm not posting this for a victory lap. I'm posting it because of what it actually means: When a company hands you their AI rollout, the scariest question isn't "can you build it." It's "will this still be standing in 18 months." Being in the network means Anthropic is vouching that we can put Claude into production and keep it there. That's the part clients are paying for. The badge is nice. The accountability behind it is the point.

The engagements that compound all started the same way. Two weeks inside the operation before anything got built. Reading the order flow that breaks every third Wednesday. Sitting with the ops manager who runs the Monday meeting from memory. The systems built on that map last. They get sharper every quarter because the AI was trained on how the business actually runs, not how the documentation says it does. Those two are almost never the same. Map first. Always.

It pisses me off when ppl tell me that "Ai is taking too long"... like, dude, you'd have spent 2 hours doing this and you can't wait 20 seconds?