Writer’s note: I encourage you to skim the headings, sub-headings, and bold text; chew on the meat and spit out the bones. Field note posts are my attempts to give you a digestible version of long-form internal notes and gibberish made useful and relevant. I get feedback about these long form field notes being “too long” and “you should it put it into short videos…” and I get a giggle out of this. The concise + polished versions come in the form of products, client programs, workshops, one on ones, talks and videos deliverables.

Most businesses are trying to prepare for AI by organizing what they know.

They are cleaning up documents, building knowledge bases, documenting processes, connecting software, centralizing files, and trying to get institutional knowledge out of people’s heads.

That work matters. Most organizations have not even done that much.

Their actual operating knowledge is scattered across inboxes, shared drives, Slack messages, meeting notes, old presentations, disconnected databases, forgotten SOPs, and the heads of a handful of people who have simply been around long enough to know how things work.

That was already a problem. AI makes it impossible to ignore.

If you want machines to help operate a business, the machines need something coherent to operate from.

But I have increasingly come to believe there is another problem waiting immediately behind that one. Organizing what a company knows is not enough. You also have to think about how the organization thinks.

The Encyclopedia Problem

I have been encountering this firsthand while continuing to build and refine Heroik’s own internal knowledge and thinking architecture, what we call the Heroik Brain.

This term “AI Brain” gets thrown around willy-nilly to be the equivalent of any knowledgebase with semantic search plugged into AI.

At its minimum, robust AI brain contains durable principles, methodologies, operating philosophies, business rules, frameworks, definitions, lessons, and the accumulated institutional knowledge that should survive any particular project, software platform, or AI model.

This is a knowledge layer, based brain. This kind of brain alone creates tremendous leverage.

Instead of beginning every AI conversation from zero, the system can operate from an increasingly mature understanding of Heroik.

There is continuity, institutional memory, common language, principles underneath the decisions.

But that success reveals another problem many experience - and we ran into along the way too.

A system designed primarily to preserve durable knowledge can become biased toward permanence.

Every interesting thought starts looking like something that needs to become a rule. Every new observation becomes a candidate for canon. Every change creates another conversation about whether it should become permanent, where it belongs, what it supersedes, and how every downstream system should interpret it.

That sounds disciplined. Eventually, it can become bureaucracy. Bureaucracies create friction and slow down Flow - the movement of value and work itself - stalls.

The original intention was never to permanently lock in every thought Heroik had. The intention was to document the work. Those are very different things.

Most of our work is not permanent. It is exploration. Research. Testing. Experimentation. Hypothesis. Argument. Revision. Failure. Discovery.  Sometimes the most important conclusion of an entire line of work is that we were wrong.

A system needs to be able to preserve that journey without pretending every stop along the way deserves to become doctrine.

We tinkered (and still do) with many solutions to this but want to note it as a warning to others to address early.

The Journey Matters Too

This exposed a second problem. A knowledge architecture can become excellent at preserving conclusions while remaining surprisingly poor at preserving how those conclusions were reached.

The final decision gets documented. The permanent principle gets captured. The polished deliverable survives.

But what about the work in between?

The abandoned fork. The task that exposed a larger issue. The experiment that failed.

The assumption that turned out to be false. The conversation that changed the direction. The research trail.

The reason one option was rejected in favor of another. The mistake that should prevent somebody from repeating the same mistake two years later.

Those things matter. In many cases, they matter more than the final answer.

If the journey remains trapped inside an AI conversation, a person’s memory, or whichever software platform happened to perform the work, the organization has not actually captured its institutional knowledge.

It has captured the artifact. That creates dependency risk.

A company may believe it has built an AI-enabled knowledge system while substantial pieces of its actual reasoning history remain locked inside ChatGPT, Claude, email, Slack, or the memory of whoever was driving the project.

Change the platform and pieces of the organization’s intelligence disappear. That is not resilience. It is another version of tribal knowledge, except now some of the tribe is software.

Knowledge Architecture Is Only the First Layer

This is where I think the conversation around business AI needs to move next.

There is a permanent knowledge layer. Every organization should have one. It should capture the principles, definitions, methods, operating rules, processes, lessons, and institutional knowledge that deserve to persist.

Most companies are still dramatically behind on this.

But knowledge architecture alone will not be enough for the environment we are entering.

The speed of the AI paradigm requires something more adaptive around it. Call it a reasoning architecture. A thinking architecture. A cognitive architecture. The label matters less than the capability.

The system needs to support the movement from uncertainty to action without forcing every thought into permanent storage.

It needs room to explore, to argue, to hold contradictory possibilities temporarily, as well as room to test something seriously and then throw it away.

It needs room to distinguish between:

• We are considering this.
• We are testing this.
• We currently think this.
• We decided this for this project.
• We learned this.
• We now believe this is durable enough to preserve.

Those are different states. Collapsing them into a single category called "knowledge" creates rigidity.

From Exploration to Durable Knowledge

A healthier system needs movement.

Something closer to:

Explore → Reason → Decide → Execute → Learn → Preserve

The early stages should be loose enough to allow discovery.

The later stages should become progressively more deliberate.

Not every idea survives. Not every experiment becomes policy. Not every project-specific choice deserves to become an organizational rule. But the path should still be documented well enough that another human or machine can understand what happened.

That distinction creates breathing room.

It also changes what the AI is being asked to do. Instead of merely retrieving rules from an encyclopedia, the AI participates inside a governed thinking process. That is a much more interesting problem.

AI Has a Reasoning Problem. So Do Humans.

There is a lot of marketing right now about AI reasoning. Some of it is deserved. A lot of it is hype.

These systems can compare enormous amounts of information, surface patterns, generate alternatives, challenge assumptions, summarize arguments, and operate at speeds no human can match.

They can also confidently misunderstand the problem, follow a bad premise beautifully, invent certainty, overweight whatever happens to be in context, or produce an extremely sophisticated explanation for something that is simply wrong.

Human beings like pointing this out. And we should. But we should not let ourselves off the hook.

Humans are not nearly as good at reasoning as our mythology about human reasoning suggests. Worse, we are often terrible at explaining how we reason.

Ask someone why they made a complicated strategic decision and you will often receive a cleaned-up story created after the fact.

Experience, pattern recognition, instinct, fear, incentives, values, incomplete evidence, memories, preferences, relationships, and dozens of subtle signals may have influenced the decision.

Then the person explains it in three tidy bullet points.

We regularly confuse the explanation of our reasoning with the reasoning itself.

That creates a serious problem if our plan for sophisticated business AI is simply to "teach the AI how humans think."

Which humans? Thinking about what? Under what conditions? How accurately can they articulate it? How much of their process is actually conscious?

Humans do not currently live up to the hype of being able to perfectly create reasoning systems for AI to swallow either.

That is why I increasingly believe the real opportunity is hybrid.

• Durable organizational knowledge.
• Multiple AI models.
• Structured reasoning processes.
• Recorded decisions and learnings.
• And human judgment in the loop.

Not because humans are infallible. Because neither side is. The architecture should be designed around the strengths and weaknesses of both.

That is augmented intelligence in a much deeper sense than simply adding an AI chatbot to a business.

Software Development Has Good Ideas. It Does Not Own the Problem.

Another pattern has become increasingly obvious. A significant amount of the conversation about AI architecture is being shaped by coders and computer scientists.

That makes sense. They are building many of the systems. And software development has produced some extremely useful disciplines for dealing with complexity.

• Specifications.
• Version control.
• Testing.
• Architecture decision records.
• Change management.
• Principle-based programming.
• Structured documentation.
• Dependency management.
• We should steal aggressively from all of it.

But every discipline has a tendency to mistake its tools for the whole toolbox. Software developers are not immune.

A software specification is usually trying to answer some version of:

• What are we building?
• What should it do?
• What constraints must it satisfy?
• How will we know whether it works?

Those are useful questions. They are not the entire cognitive problem.

A business reasoning system also needs to wrestle with questions like:

• What do we currently believe?
• Why?
• How confident are we?
• What assumptions are we carrying?
• What are we testing?
• What evidence would change our position?
• Where did this decision come from?
• What did we learn after execution?
• What deserves to become durable knowledge?
• What should remain temporary?
• What should be intentionally forgotten?
• What should we refuse to automate?
• What is technically possible but strategically stupid?

Those are not merely software development questions. They touch strategy, psychology, operations, knowledge management, organizational behavior, leadership, design, economics, culture, and human judgment.

So yes, borrow from software engineering. Borrow heavily. Then broaden the architecture. The problem is larger.

What You Leave Out Is Part of the Architecture

There is another part of this that gets uncomfortable quickly. A good system cannot be built by endlessly accumulating "best practices." Someone has to make subjective decisions.

Someone has to say:

• I understand this is commonly done.
• I understand somebody published a framework saying we should do it.
• I understand this might be considered best practice.
• I do not care.
• It adds complexity without enough value, so we are not doing it.

That is judgment. That is also architecture.

Good systems are defined as much by what they refuse to contain as by what they contain.

• What will you not track?
• What does not deserve automation?
• What does not deserve permanence?
• What process creates more administrative work than operational value?
• Which rule made sense five years ago but does not fit the current terrain?
• Which feature sounds impressive but increases cognitive load?
• Which industry convention exists because everybody copied everybody else?
• Which "requirement" is actually somebody’s preference wearing a necktie?

Those decisions require discernment. In our work, the things we omit, ignore, simplify, delay, refuse, or deliberately leave human can be as important as anything we build.

Some rules should be followed. Some should be bent. Some should be broken. None of these systems will ever be perfect. Perfect is not the goal. Excellent is.

Our work at Heroik is building things for the real world From Thought to Profit™.  Real-world does not live in a land of make-believe perfection - but it demands high-performance. There are no participation trophies - but did you help the client’s work Flow, did you advance their condition,

There Is an Advantage in Moving Before the Map Is Finished

This is where the current AI moment gets particularly interesting.

Paradigm shifts create temporary periods where the map is incomplete.

Institutions are still researching. Standards are still forming. Best practices are being written while the terrain underneath them continues changing. People are confidently explaining technologies that did not exist in their current form twelve months earlier.

During stable periods, established best practices become increasingly valuable. The terrain has been explored. The obvious mistakes have been cataloged. Standards emerge because enough people have crashed into the same wall.

But during a paradigm shift, yesterday’s certainty becomes much less valuable. The premium moves toward a different set of capabilities.

• Experience.
• Discernment.
• Experimentation.
• Pattern recognition.
• Speed.
• Cross-disciplinary thinking.
• Comfort with ambiguity.

The ability to act without pretending uncertainty does not exist. And perhaps most importantly, the ability to recognize which rules no longer match the terrain.

That does not mean recklessness. Boldness and stupidity are not synonyms. It means accepting calculated uncertainty when the potential upside justifies it.

There is always a gap between theory and reality during periods like this. Operators encounter problems before institutions have names for them. People working in the field develop techniques before researchers validate them.

A strange combination of experience, evidence, instinct, experimentation, and a shockproof bullshit detector sometimes reaches the right answer years before somebody publishes the paper explaining why.

That gap is opportunity.

Great Time to Be a Cowboy

The advantage does not belong to whoever memorizes the largest collection of AI rules.

It probably does not belong to whoever adopts the most software either. It belongs to the people and organizations capable of learning and moving faster than the terrain changes.

Capture what you know. Get the knowledge out of people’s heads. Document the work. Preserve the journey, not only the conclusion. Separate exploration from commitment.

Let experiments remain experiments until they earn something more.

Use AI aggressively. Do not worship it. Keep humans accountable for judgment.

Borrow useful ideas from every discipline you can reach. Ignore disciplinary boundaries when they stop serving the problem. Delete complexity that cannot justify itself.

Move before the map is finished. Pay attention to what happens. Correct course without ego. Keep what survives. Then turn those lessons into the next version of the system.

The AI era is still a Wild West moment. That can be frightening if your advantage depends on somebody else having already mapped the territory.

For the rest of us?

It is a great time to be a cowboy.

Cowboy up.