This past Friday morning I appeared on Isaac Sacolick's "Coffee with Digital Trailblazers." The topic was "Vibe, Buy, or Automate? Deciding How to Build AI Agents." There were several of the finest minds in the business on the panel, another 25 or 30 sharp people in the audience, and everybody was making excellent, valid points.
Listening to all of it, it hit me that the conversation itself was the message. Oh, my word, this is a complex problem. Nobody on that call was wrong. And that's exactly the trouble.
When everybody's right and the problem is still confusing, you don't have a tooling problem. You have a knowing problem.
So, I told the group that we, the people who lead technology, have to become the Department of Know (K-N-O-W)—not the Department of No (N-O).
Our job as technology leaders is to be the guiding light that looks at each proposed use and says one of three things:
Vibe It: Yes, AI makes sense here, but it can be done with a short, well-defined program. Vibe-create it in a small blast zone and move on.
Automate It: The process is stable and boring. Use deterministic automation. Boring wins.
Engineer It: Whoa, this is going to need a whole array of agents collaborating to create new value. Let's engineer the living daylights out of it, get the data right, put the guardrails in, and keep a human in the loop.
You can't do that with a policy memo. And you definitely can't do it by handing people the tools and saying, "Here, create value, save time." Give them a sandbox, sure. Let them play, let them get familiar. But a sandbox doesn't generate purpose. Purpose comes from somebody who knows which tool fits which job, carefully evaluating case by case.
Here is the curriculum—the three questions I brought to the show that you should teach your people to ask before they build anything:
Can you state the job concisely? Vibe coding is cheap when the ask is crisp and brutally expensive when you're exploring as you go. If you can't name the exceptions the business actually runs, you don't have an agent project—you have a guessing project with a credit card attached.
Is the process stable, or still being invented? If it's stable (rules known, inputs clean, exceptions rare), automate it. Agents earn their keep where judgment lives: places where you deal with messy inputs, exceptions, and decisions that need context and data lineage.
Who owns the swarm when it grows? Every agent needs three things on day one: an owner, a cost line, and a kill switch. An agent without an owner is just shadow IT with a better vocabulary.
Our host, Isaac Sacolick, published a sharp 2x2 matrix: buy vs. build, rules vs. judgment. My footnote: the "buy judgment" quadrant is where the swarm breeds fastest, because buying feels like someone else's problem. It isn't.
Here are two quick examples from my own work last week:
Task 1: I keep a spreadsheet with attendees of the weekly Thursday morning SIM MIT session. Updating it by hand is tedious, and writing macros isn't my strength. But I didn't need an agent; I needed Gemini to write a simple macro. I pasted the code into the sheet, and now it automatically sorts and highlights rows on every entry. Deterministic problem, simple tool.
Task 2: In contrast, I gave Muse access to LinkedIn and instructed it to post my weekly meeting invitation every Friday around 8:15 AM, advance the date to the following week, and skip holidays like Thanksgiving. It posted a test on Thursday. Then, on Friday morning, it recognized it had already run, skipped the duplicate post, and confirmed it was set for next week. That requires context and judgment.
That's the whole sermon. The technology leaders who win the agent era won't be the ones with the most tools. They'll be the ones who built the Department of Know—the people everyone comes to with an idea, a need, or a concept for guidance. And they will teach their organizations to ask these three questions for themselves.
Start with a sandbox. Follow with office hours. End with people who know.
Captain Joe
Follow me on X @JPuglisiLLC