Local Rubicon: AI Conversations Shift

At the very first Coastal Intelligence Council meeting, we introduced ourselves formally (and a bit awkwardly) and didn’t really bond until somebody in the middle of the table said, “Did anybody see yesterday’s announcement about Gemini 2.0?” and the room erupted.

We knew we had found our tribe.

Yesterday, by my reckoning, was the 24th gathering of the Coastal Intelligence Council around the lunch table and the conversation was markedly different from the previous 23.

Instead of the conversation being about:

• The release of OpenAI’s GPT-6
• The release of Anthropic’s Claude 5.5
• The release of Google’s Gemini 4 Argon
• The release of Grok 4.7
• Dots, Duet, Muse Wonder, Grok Bot
• Open Claw, Hermes, Instinct, Jev, Cloudflare Clef
• The Rise of “Decision Models”
• The massive cybersecurity exploit PHP2Shell
• Anthropic Outlawing “Cruelty” to Claude

any one of which would easily have consumed our 90-minute meeting.

We talked about business process engineering.

I can hear your eyes rolling and see you groaning with boredom. But this is where all of us who are deep in the throes of helping people adopt AI find ourselves.

We’re talking about how the business operates, how decisions get made, and why three departments can’t agree on what constitutes a customer.

In the 1970’s and 1980s, when companies were putting in computers in a serious way, we engaged in Business Process Reengineering because we could automate everything.

In the 1990s, I would consult with major corporations about why they should have a website. When they were finally at the point where they were willing to consider it, they would ask, “So what should we put on our website?” My response was always, “That depends. What are you trying to accomplish?”

At the turn of the century, as I was diving into analytics, they would ask me, “What should we measure?” My response would be the same. The result would be a hostile argument between the leaders of these companies about their goals, their key performance indicators, and, in fact, their very business model.

This was Digital Transformation which languished for decades until COVID forced it into the spotlight and we all got on Zoom.

Now, with agentic AI, organizations are facing the same question: How do we automate our processes?

You have to start with the business problem, not the AI solution. Executives often arrive with an idea for an agent before agreeing on what problem they’re solving.

The issue is that people tie themselves in knots trying to articulate how they do their job. They can describe tasks, and they can point to standard operating procedure manuals. But definitions are inconsistent and what people actually do bears little resemblance to the procedure manual.

At the recent MAICON conference in Cleveland, I had the joy of watching Liza Adams present again. She told a wonderful story of her grandmother’s wonderful cookies. Grandma claimed she was just following the Tollhouse Cookie recipe, but while watching, Liza discovered that she swapped butter for lard, added a bit of vanilla, and goosed the temperature of the oven for the first few minutes of baking. The result was a fantastic-tasting cookie that nobody could reproduce because Grandma had never written down what she really did.

Thus it is with business processes.

Ask the person who pays the bills, and you’ll discover that half the steps are skipped, three exceptions are handled through email, and one indispensable employee knows how everything really works.

We do the tasks, but we alter what it says in the instructions because we’ve learned that we have to accommodate other people not following their processes, we have to account for the data we receive being inaccurate, and we have to compensate for the sensitivity of that one employee who can really screw things up if you don’t do it the way they want.

Standard operating procedures got that way because something went wrong, so we put in a rule, a guideline, a guardrail, a restriction, and an approval process. And then there were unintended consequences, so we put in more rules, guidelines, guardrails, restrictions, and approval processes. And then another, and another, and another.

Trying to figure out what to automate requires identifying the intention. What are you trying to accomplish?

I’ve seen organizations spend weeks doing this. Instead, rapid prototyping can quickly expose disagreements, missing requirements, and unexpected scenarios. The trick is to alternate building and thinking.

It’s great when senior executives come up with great ideas, but they are entirely inappropriate for designing the solution. The people at the coalface who do the actual work and know how the actual work actually gets done are the right people to have on hand for vibe coding.

And once they start seeing the results on the screen instead of on the whiteboard, they’ll engage in that productive struggle of thinking things through more thoroughly together.

Then it’s time to get into the weeds with the really boring stuff of governance, security, privacy, data readiness, accountability, and human oversight.

Once that’s all addressed, and the clever demonstration can be turned into a dependable system, it’s time for the real messy effort of change management.

The real value is in human understanding, not software production. Frameworks, judgment, and productive struggle are becoming more valuable precisely because software is becoming easier to create.

The ability to generate an application is becoming a commodity.

Knowing what to create and why is the skill of the future, not banging out code.