The AI industry is divided between two camps: the symbolists and the connectionists.
The symbolists argue that large language models are sophisticated statistical systems—stochastic parrots—that generate probable language without true understanding. The connectionists believe scaling neural networks with more data and compute will eventually produce artificial general intelligence (AGI).
The symbolists are right. The connectionists are wrong.
Wrong—but useful, that is
Large language models are not the human brain. The singularity will not be an emergent property of more data centers making more connections at scale. Yet the connectionists are driving today’s AI revolution. Why? Because their stuff works.
Today, I can feed fifty documents into NotebookLM and get up to speed on a complex topic in minutes. I can draft a full enterprise white paper in an afternoon. As a writer, it’s hard to argue with success like that.
But here’s what this argument actually means in practice: if LLMs don’t reason, understand, or think, then we need to stop using them as if they do. The organizations getting the most out of AI are not the ones with the best prompts. They’re the ones who have built systems that account for what these tools actually are: fast and powerful—but genuinely unreliable without governance.
From prompts to process
For twenty years, my work has been translating complex emerging technologies into narratives that move enterprise audiences. SAP, SaaS, digital transformation, automation—I’ve written across all of it.
When generative AI arrived I did what most writers did. I experimented with prompts. Got impressive results. Got burned by hallucinations. Got frustrated by inconsistency.
I was making the same mistakes I now see everywhere:
- Treating AI like a researcher or expert when it’s actually a pattern-matching tool. The output looks authoritative—but looking authoritative and being authoritative are very different things.
- Assuming speed and volume are the wins when the real risk is credibility loss. In high-stakes sectors like aerospace, healthcare, and finance, a single hallucination in a technical white paper isn’t a typo. It’s a failure of brand authority.
- Not recognizing that LLMs require different—not just faster—workflows. Prompt engineering is literacy, not strategy. You can’t prompt your way to reliability when you’re working with a tool that has no mechanism for verifying truth.
Writing better prompts doesn’t solve this problem, but building better systems can.
What follows are three systems I built, what each one taught me, and (with some humility) where each one stands today.
What I learned building a context-encoded writing system
The first system I built was a custom GPT encoded with specific style guides, brand voices, and compliance rules—essentially a purpose-built writing partner that understood the client’s voice before the first word was written.
The insight behind it was simple: AI produces generic output when given generic context, and on-voice output when given specific context. Encoding brand identity, messaging frameworks, and editorial rules into the system’s context window produced dramatically better first drafts—80 to 90 percent on-voice, consistently.
What this taught me was the same lesson enterprise content teams learned long before AI existed: specificity of brief determines quality of output. The system worked because it was essentially a very detailed creative brief, encoded once and applied consistently.
I’ll be honest about where this stands now. It’s still usable but products like Claude have largely productized this approach. You no longer need to build it yourself. What this validates is the principle, not the system. I understood early that context encoding was the key to reliable output. The vendors caught up. This is a good thing.
What I learned building a verification-first workflow
The second system I built came directly out of a specific project—a competitive comparison of SAP Cloud ERP and Oracle NetSuite.
This wasn’t typical marketing content. It was a side-by-side analysis where every claim about the competitor had to trace back to the competitor’s own primary documentation. Thirty-four footnotes. Every one an Oracle source—product datasheets, technical documentation, compliance certifications. The consequence of an unsupported claim wasn’t a revision cycle. It was reputational and legal exposure for the client.
This project clarified something I now consider a governing principle of AI-assisted enterprise writing: in high-stakes content, research and writing cannot happen in the same conversation thread.
The typical AI workflow collapses these two things together. You ask, it researches and writes simultaneously. The result looks authoritative whether or not it actually is. Probability and authority are not the same thing. In competitive content, in technical white papers, in anything where a single unsupported claim carries consequences—that collapse is a liability.
The system I built in response uses dedicated agents operating under what I call a Source Isolation protocol. A researcher agent extracts claims from source documents. An auditor agent flags anything not explicitly supported by those sources. Narrative synthesis only begins after verification is complete. Subject matter experts can review isolated claims early—without having to wade through marketing copy—which significantly reduces revision cycles.
What I learned trying to automate SEO workflows
The third system I built was the most instructive—and the most humbling.
The idea was straightforward. SEO optimization work is largely rule-based: make changes to keywords and heading structure, add new sections and remove old ones. If the requirements are deterministic, a Python automation should be able to apply them with perfect fidelity. Better than a human, in fact—faster, more consistent, no fatigue.
The automation worked. The Python was solid. It could translate well-formed requests into standard commands reliably and consistently.
The problem was upstream of the code entirely.
SEO leads don’t make requests in structured, machine-readable formats. They communicate the way humans communicate—with variation, implicit context, shorthand, and assumptions. The same requirement would arrive phrased a dozen different ways. The formatting assumptions embedded in the templates added another layer of variability the system couldn’t absorb cleanly.
What I learned is the human interface problem. AI workflow automation tends to break down not at the technical layer but at the point where human input enters the system. The Python was fine. The problem was that nobody had specified what a well-formed request actually looked like—which meant the inputs feeding the automation were too variable to produce consistent outputs.
This isn’t a technology failure. It’s a governance failure. And fixing it isn’t a coding problem. It’s an editorial and process problem—exactly the kind of problem enterprise content teams are good at solving.
What I know now
The connectionists are wrong about what AI is. But their tools are genuinely transformative if you’re honest about what they are and build accordingly.
Context encoding handles brand governance. Verification-first workflows protect technical integrity. And the hardest lesson—that automation breaks down at the human interface, not the technical one—points back to something enterprise content teams have always known: the quality of your inputs determines the quality of your outputs.
This was true before AI. It’s more visible now.
Who understand where AI is reliable, where it isn’t, and how to build workflows that account for the difference. This is the work ahead.
← Back to Blog