Surviving AI

The Decision

There are two ways to deploy AI in your business. One is fast and constrained. The other is hard and compounding. Most teams choose wrong - by default.

Mark Jones
Mark Jones · Collab365

You are probably overloaded with opinions about what to do with AI right now. Every consultant, vendor, and LinkedIn post has a different answer. Most of them start with an assumption that you already know what you are building towards.

You probably do not. Neither did we.

So let us simplify it. There are two paths any knowledge business can take. Only two. And the choice between them determines almost everything that comes after.

Path A: Connect AI to What You Already Have

This is the path most organisations take first, because it makes immediate commercial sense.

Hand-drawn sketchnote illustrating Path A: Connect AI to What You Already Have

You have existing content. Existing systems. A SharePoint intranet, a WordPress blog, a Confluence wiki, a CRM full of client records. You point an AI at them. You build a chatbot. You deploy Copilot. You add a RAG layer over your document library. You ship something within weeks. You have a demo. You have something to tell the board.

We took this path. For six months. Here is what we found.

What Path A gives you

Speed. Something visible quickly. A proof-of-concept that satisfies the stakeholders who want to see AI happening.

If your content is relatively clean, relatively current, and lives in one place, a well-built Path A solution can work well enough. Not perfectly. But usably.

What Path A takes away

Control. Ceiling. Compounding.

When your AI points at systems you do not own, you inherit every problem those systems have. Outdated content surfaces as current fact. Contradictory information from different eras gets blended into a confident, authoritative-sounding answer. You cannot update the underlying data quickly. You cannot run your own logic against it. And when the third-party platform changes their API - and they will - your integration breaks and you have no recourse.

The deeper problem: the ceiling on Path A is structurally fixed. You can improve your prompts. You can tune your retrieval. But you cannot do things with third-party data that the platform was not designed to allow. You are renting a room. You cannot knock down any walls.

We had hallucinations. We had outdated content surfacing as truth. We had a system that looked impressive in a demo and fell apart under real member questions. We will cover exactly how that happened in the next chapter.

Path B: Own Your Architecture. Build Your Internal Brain.

Path B is harder. Slower to start. More expensive in the short term. And it is the path that compounds.

Hand-drawn sketchnote illustrating Path B: Own Your Architecture and Build Your Internal Brain

Instead of pointing AI at systems you do not control, you migrate your knowledge into an architecture you own. You build an intelligence layer that reads, updates, and reasons over your proprietary corpus. Your data model, your logic, your rules for what the AI can and cannot say.

What Path B gives you

The ceiling on Path B is completely different.

Because you own the data, you can update it the moment the world changes. Because you own the architecture, you can run any logic you want against it. Because the data lives in your codebase, your AI agents can reach across every part of your business simultaneously: member records, content, subscriptions, community signals, validated problems. All of it queryable, all of it grounded in truth.

And critically: it compounds. Every member interaction enriches your understanding. Every solved problem strengthens your knowledge base. Every validated solution makes the next one faster to produce. The system gets more valuable every day it runs. That value belongs to you.

What Path B takes away

The quick win. The easy demo. The six-week delivery timeline.

Migration takes time. Cleaning 14 years of legacy content took us six weeks of focused engineering - and that was after we had built the automation tools to do it. The architecture decisions take longer to get right. The first version will not work the way you expect. There will be an expensive failure or two before the system clicks.

We are not romanticising this. Path B is hard work.

The Honest Comparison

We are not telling you Path A is wrong. We are telling you what it costs.

If you need something working in six weeks for a board presentation, Path A is your answer. Go in knowing what you are choosing: a constrained, fragile integration that will require ongoing maintenance and will hit a ceiling you cannot break through.

If you are building something you want to be genuinely better in twelve months than it is today, Path B is the only option. Go in knowing what it costs: time, migration pain, and a willingness to delay the demo in favour of building the foundation.

Why This Matters More in 2026 Than It Did in 2023

Here is the thing that most people have not fully understood yet: building Path B is more accessible in 2026 than it has ever been.

AI-assisted coding tools have genuinely changed what a small team can build. Vibe coding is real. A founder who can think clearly about a process and describe it in structured steps can build things today that would have required a team of ten engineers in 2022. We built our entire intelligence architecture with two people, AI coding tools, and a lot of architectural thinking.

The barrier is not the engineering. The barrier is the architecture decision. You need to know what you are building before you build it. That decision is worth taking your time on.

Make the decision deliberately, not by default. Because the default choice almost always leads to a quiet, expensive failure. Here is exactly what happened when we took the easy path.

6 months

How long we spent building a chatbot over our legacy data before we killed it completely.