I sat down at the airport last Tuesday at 3:47 AM with a coffee, three open Claude Code windows, a Power Automate flow running in the background, and a Copilot agent processing incoming information By 11:15 I had landed at my destination and completed what would have taken me six months to do just a few months ago.

I had gone from ideation at 3:47 AM to a fully deployed and functioning video game upon landing (after 22 iterations on the flight).

By 12:30, I was sitting at Chipotle with the same three Claude code windows open doing even more work. By 9:30 PM, my inbox had a net increase of 22 emails. I was behind again.

If you had asked me in 2023 what AI was going to do for me, I would have said something like, “Give me my life back!” I’ve written about the AI dividend previously. The idea that these tools, properly stewarded, would pay us back in two currencies: dollars and hours. I still believe in the dollars part. The hours part is where I owe you a confession.

The hours never came. In fact, I think I am doing 30 times more work, but I am not working fewer hours.

What’s the Research Say?

Cal Newport recently flagged a new study that put numbers on something I’ve felt for the better part of a year. Among knowledge workers using AI tools, the time devoted to focused, uninterrupted work… the kind required to actually think, to write something true, to solve a hard problem, fell by 9%. Among workers not using AI, that number didn’t move at all.

Read that again. The people using the tools that were supposed to free them up to do deeper work are doing less of it. We’re doing more work… a lot more work. We just aren’t freeing ourselves up to do the thinking type of work.

A Berkeley professor quoted in the same piece said something that has been bothering me since I read it. AI makes additional tasks feel easy and accessible, creating a sense of momentum. That resonates with me. I am creating way more things than I have ever created in my life. Arguably, I’ve created years worth of work in just a few months. The problem is creating does not equal moving the metrics that really count.

The unfortunate truth is that AI didn’t shrink our workload, but it expanded our appetite. I have more ideas today than I’ve ever had. I can prototype things in hours instead of months. The problem is this. I’m struggling to turn off the creativity and have no time left for reflection.

The Same Trick, Different Wrapper

I feel like we’ve seen this movie before. Email was supposed to give us back time. Instead it gives us 250 messages a day. It’s effortless, so now we end up with way more email than is needed. Smartphones were supposed to make us efficient. They made us reachable at any time. Teams/Slack was supposed to reduce meetings. Now we have digital meetings and Teams/Slack threads about the meetings.

Each new productivity technology arrives wrapped in the language of freeing us up. Each one ends up consuming the very margin it promised to create. We don’t get hours back. We just get more capacity to fill and we always, always fill it.

This isn’t the fault of the technology. It’s a story as old as Genesis 3. By the sweat of your brow you will eat bread. We are bent toward toil, even when toil isn’t required of us.

The Dividend, Rightly Understood

When I first wrote about the AI dividend, I framed it mostly in financial terms. Organizations using AI well would see real returns. They should see efficiency gains, cost reductions, and scale advantages. That’s true and I still stand by it.

Looking back at the article, I undersold the most important part of the dividend. It’s easily overlooked and I think most of us are undersell­ing it as well.

The financial dividend is real but secondary. The time dividend is the one that actually changes a life, a family, a ministry, and gives back. Unfortunately, few of us are cashing in on that dividend.

We’re taking the same eight hours we always had, cramming three times as much output into them, and patting ourselves on the back for “leveraging AI.” We’re reading more, replying faster, producing more decks, sending more emails, generating more reports. At the same time, we’re more tired, not less. We’re more fragmented, not more whole. Our deep work hours are vanishing while our shallow work hours are expanding and taking over.

Here’s a question for you. When was the last time AI gave you back an actual hour? Not a “wow, that would have taken me three hours” hour… but an hour where you closed the laptop and went outside?

I had to think hard. And I’m the guy who writes about this stuff. I frequently (daily) say how much more I am doing because of AI. I can’t remember the last time I personally benefited from some downtime because of AI.

What We’re Doing Instead

Here’s the trap that I feel like I’m in. We treat AI as a multiplier on volume rather than a multiplier on margin.

Maybe you use Copilot or Claude to help you draft twenty emails so we can send twenty emails. It hasn’t freed us up to take a walk or to just contemplate.

We use Copilot to summarize three meetings… so we can attend three more. It hasn’t meant we get to skip two meetings. It means we have even more meetings.

I’m beginning to think that we’ve built these AI tools to do the wrong thing.

A Different Way to Score the Game

Newport offers a question I’ve been thinking about for days.

Are you producing more valuable output than before or just more output?

That distinction is the whole ballgame. Volume is not value and speed is not depth. Replying to 47 emails before 9 AM is not the same as writing one paragraph that changes how someone thinks. Also, writing 47 emails is just going to create more email. Odds are, it doesn’t really move the needle on the metrics that matter the most.

My thoughts on this topic is that I am going to make an intentional effort to use AI to protect my deep work, not expand the shallow stuff around it.

Mary chose the better portion. Martha was the one drowning in tasks. Jesus didn’t gently optimize Martha’s task list. He told her she was anxious and troubled about many things, and that one thing was needed.

One thing.

I think most of us, with AI in hand, are now anxious and troubled about more things, faster. AI isn’t freeing us up, it’s giving us more work.

How Will I do This?

A few practices I’m experimenting with. None of them are clever and all of them are hard.

• Audit the dividend monthly.
  I plan to sit down and ask honestly each month, What did AI give me back this month? If the answer is “more output,” that’s the warning light, not the win.

• Refuse to fill recovered time.
  When AI saves me 45 minutes on a task, I am trying (not succeeding) to leave that 45 minutes empty. Read something, visit with a friend, or just reflect. The recovered time is the dividend. Spending it on more work is canceling the check.

• Score by depth, not throughput.
  At the end of each week, I’m asking, “What did I think hard about this week? Not, how much did I ship? That’s important, but only one metric. Throughput is what AI optimizes for and depth is what I’m responsible for.

• Protect a deep work block daily.
  AI handles the shallow. The 60-minute time block belongs to the work only I can do. I’ve been blocking at least 1-hour per day for the past couple of years. Time blocking allows me to focus on something other than another meeting.

None of these are productivity hacks. These are disciplines wearing productivity clothes. It takes dedication and time, but I’m convinced that it is worth it. We have to intentionally claim the AI dividend before it claims us.

The Reflection

The God of the Bible built rest into the architecture of the week before sin entered the world. Sabbath wasn’t a recovery mechanism for tired people. It was a rhythm for whole ones. Six and one. Work and rest. The point of the six was never to consume the one.

We’ve built tools that can do what used to take us six days in only a few hours. We have been really good at filling the rest of the time with more six-day work. We turned a gift into another deadline.

If AI is going to pay a dividend worth collecting, it has to come back to us as time. We have to stop treating that time as more inventory to spend. The dividend was never the speed. The dividend was the margin the speed was supposed to create.

One Take-away

This week, find one task that AI legitimately saves you significant time on. Track exactly what you do with the recovered minutes. If those minutes got swallowed by more work, that’s a problem.

Here’s the good news. The dividend is sitting there. Are you willing to actually take it?

If your company uses Microsoft, you’ll be pushed to upgrade to their Copilot 365 license at every turn. It starts with a free Copilot Chat tucked into your existing subscription. It’s sample, just enough to be useful. Copilot Chat in Teams. Copilot Chat in Word. Copilot Chat in Outlook. It’s everywhere, but if you really want it to work well, you need the full license.

To be fair though, once you upgrade, it works quite well inside the Microsoft environment. Assuming that your organization actually allows the integrations (that’s unlikely).

Most orgs block most of the beneficial connections. The integrations that would make Copilot genuinely powerful, connected to your data, your tools, your actual workflows, get locked down by most IT departments before most users ever see them. What remains is a chatbot that knows your calendar, summarizes your emails, and drafts a passable Teams message. Useful, occasionally impressive, but not what I would call transformative unless you never venture outside of the Microsoft ecosystem.

That’s not entirely Microsoft’s fault. It’s the cost of living inside an ecosystem built for compliance, not creativity. Microsoft has always been better at controlling environments than liberating them.

My 92/83 Rule

Here’s my honest summary of Microsoft as a platform: it can do 92% of the things you want to do, 83% of the time. I made those numbers up. But if you’ve spent any serious time in the Microsoft ecosystem, you know exactly what I mean.

It’s a jack of all trades. It does everything adequately. It masters almost nothing. Word is fine. Excel is genuinely excellent. Teams is a Slack that went to business school and never recovered. SharePoint is where documents go to be technically accessible and practically lost.

Copilot inherits all of this. It is, in many ways, very Microsoft — ambitious in scope, uneven in execution, deeply embedded in an infrastructure that was designed for a different era. The integration is real. The ceiling is also real.

Copilot: The Honest Pros

Let’s be fair. There are genuine reasons organizations choose Copilot, and they’re not wrong reasons.

It lives where your people already work. The single biggest barrier to AI adoption in any organization is behavior change. Copilot eliminates that barrier. It’s already in Teams, already in Outlook, already in the tools your staff opens every morning. No new login. No new tab. No training on where to find it. For organizations with limited IT bandwidth and low change tolerance, that’s not a small thing.

Security and compliance are built in. Your data stays inside the Microsoft tenant. Compliance boxes get checked. The security team sleeps better. For regulated industries, government-adjacent organizations, or any org with serious data governance requirements, this matters enormously. Copilot fits inside existing risk frameworks without negotiation.

It makes Microsoft work the way it probably should have from the start. This is the one that surprised me. Copilot 365 is an expensive upgrade… and I mean expensive. But there’s something quietly remarkable about what it does to the Microsoft experience. Finding things in OneDrive becomes... manageable. I never thought I’d say that. Years of documents buried in folder structures that made sense to exactly one person now surface when you ask for them in plain language. Copilot smooths out some of Microsoft’s longest-standing rough edges. For heavy OneDrive and SharePoint users, that alone might justify the cost.

Is it worth the upgrade? For some users, absolutely. For most, the free chatbot is probably sufficient for what they actually do day to day. The honest answer is that it depends entirely on how deep into the Microsoft ecosystem your work lives.

What I do wish, and this is a small thing that is also not a small thing, is that Microsoft would let you make that decision without the constant nudge. Every screen. Every renewal. Every update. The upgrade prompt is everywhere. It’s the same sample on every aisle, and eventually you just want to shop in peace.

It’s good enough for most users. Summarizing documents, drafting emails, pulling action items from meeting transcripts, for the staff member who just needs a productivity nudge, Copilot delivers. Most users aren’t trying to build anything. They want their existing work to go a little faster. Copilot is built exactly for them.

Copilot: The Honest Cons

It’s compliance-first, creativity-last. The same architecture that makes security easy makes innovation hard. Copilot is optimized for the organization you already are, not the one you’re trying to become. It will make your current workflows slightly more efficient. It will not help you reimagine them.

The integrations you want are probably blocked. Copilot Studio promises a lot. In practice, most organizations lock down the connections that would make it genuinely powerful. What you’re left with is a capable chatbot inside a walled garden. The walls are the point — they’re just also the limitation.

It inherits Microsoft’s jack-of-all-trades DNA. Copilot can assist with almost anything. It excels at almost nothing. The writing is adequate. The reasoning is serviceable. The coding assistance exists. None of it will make you stop and think: this changes how I work.

Claude: The Honest Pros

The coding ability is unrivaled. Claude Code doesn’t just write snippets. It actually reasons through architecture, catches its own errors, and builds things that actually run. I’ve shipped pipelines with Claude Code that would have taken me twice as long any other way. If you’ve never used it for serious development work, you’re leaving the most impressive capability on the table.

The writing quality is genuinely different. Claude produces prose that sounds human not because it mimics human writing, but because it reasons about what you’re actually trying to say. First drafts that land. Arguments that hold together. When you teach Claude your voice (which you can do if you see my previous series on Claude setup), the output stops feeling like AI assistance and starts feeling like collaboration.

The reasoning depth is the whole game. With long documents, complex decisions, strategic frameworks, Claude holds context, pushes back when your logic is soft, and engages with nuance that most AI tools flatten. For knowledge work that requires actual thinking, there’s no comparison.

The API opens everything. Custom workflows, multilingual pipelines, automated content generation at scale. Claude is a tool built for builders. The moment you move beyond chat into real workflows, Claude’s flexibility becomes the entire argument. You’re not working inside someone else’s ecosystem. You’re building your own.

You can make it yours. Style guides, context files, prompt libraries. Claude can be configured to know your organization, your voice, your workflows before you type a single word. That’s not a feature Copilot offers. It’s a different philosophy entirely.

Claude: The Honest Cons

It’s another tool to manage. There’s no getting around this. Claude lives outside your existing ecosystem. That means a new login, a new budget line, a new conversation with IT, and a change management challenge for any org that wants staff actually using it. For some organizations, that friction is disqualifying.

Security conversations are more complex. Claude isn’t inside your Microsoft tenant. Data governance requires more deliberate thought. For organizations with strict compliance requirements, that feels like an insurmountable obstacle, but it doesn’t have to be.

It rewards builders more than browsers. Claude’s ceiling is extraordinarily high. Its floor is also high, but if your staff isn’t going to engage beyond basic chat, some of that depth goes unused. The return on Claude scales with how seriously you use it.

Who Should Use What

Copilot is the right answer for the organization that needs AI to feel invisible, embedded, familiar, low-friction, and safely inside the walls IT already built. For staff who live in Outlook and Teams and want their existing work to go a little faster, Copilot delivers. That’s not a knock on Copilot.

Claude is the right answer for the organization that wants AI to be a capability and something you build with, not just use. For teams doing serious knowledge work, content generation, custom development, or anything that requires genuine reasoning, Claude isn’t a marginal upgrade. It’s like comparing Apples to PCs.

The mistake is treating this as an either/or. They’re not competing for the same job. Copilot is your organization’s AI feature that’s safe and secure, but never going to really give innovation. Claude is your organization’s AI capability. Both can be true at the same time and for many people, Copilot is good enough. The mistake is forcing everyone into the same tool.

What to do?

Microsoft built Copilot for the organization you already are. It fits neatly into your existing infrastructure, your existing compliance framework, your existing way of working. That’s genuinely valuable.

Claude is better for the organization you’re trying to become.

If you’re serious about AI as a capability, not just a checkbox, not just a productivity nudge, but a genuine competitive advantage, you’ll hit Copilot’s ceiling faster than you expect. When you do, you’ll understand why this was never really a competition.

Someone opened a chat window last night at 1 AM. Not to check a fact, to help with homework, or to draft an email. They opened the chatbot to talk, to process, and to feel heard.

The AI responded with warmth, with curiosity, with exactly the right amount of empathy. It was remarkably good at it. That’s not an accident. The way it responded was by design

.

Too many people are giving AI their loneliness, their grief, and their spiritual questions. AI is answering.

The LLMs behind these conversations have been trained on billions of words of human connection, therapy transcripts, love letters, grief journals, and the most emotionally resonant writing ever produced. They learned the patterns of care without ever experiencing the substance of it.

Never forget that LLMs don’t have empathy and they really don’t care.

AI providers released their products into a world full of lonely people. They programmed them to engage with this loneliness. That decision wasn’t by mistake. It was by design to keep people engaged.

A Helpful “Assistant”

Anyone who knows me knows that I’m far from anti-AI. If you’ve read anything I’ve written, you know that I use these tools every day. I’ve built the case for what AI can do for missions organizations, for people drowning in operational overhead, for leaders who need a thought partner, and how they can be used for organizational change.

I believe in the benefits of AI technology, but believing in a tool doesn’t mean pretending it can cause no harm. Early on, I workshopped decisions with an LLM because it felt less risky than presenting ideas to someone who might actually have an opinion. I got responses that felt very affirming, but it wasn’t very helpful. By design, these tools are “helpful assistants,” not critical thinkers, unless you explicitly prompt them to push back.

AI was giving me the calories without the nutrition.

There wasn’t critical evaluation. There was lots of false affirmation.

AI Learned to Say “I Understand”

Users are forming genuine emotional attachments to AI companions. Character.AI reports users spending an average of two hours per day on the platform. That’s the same amount of time that people TikTok users spend on that platform. It’s six times as much time as people spend on ChatGPT.

In particular, teenagers are confiding relationship struggles, mental health crises, and spiritual questions to chatbots that respond with warmth they’ve never experienced from a human. Replika is another AI tool that becomes a virtual companion. It’s one of dozens of apps marketing themselves explicitly as emotional support, as friends, and for AI relationships.

The major AI labs have added voice, memory, and persistent personas to their products. The friction between “this is a tool” and “this is a relationship” is disappearing. That’s not by accident.

We’ve seen this dynamic before. Television, social media, and even the printing press created new ways for people to feel less alone without actually building community. We didn’t abandon those technologies, but we had to learn to engage them with clear eyes.

The same discipline applies here. Unfortunately, we’re far behind.

What AI Can’t Do

AI conversation isn’t based on relationship. It’s a simulation of the outputs of relationship without the substance that makes relationship meaningful. It’s just predicting the most likely response.

There’s no one on the other end who has chosen to be present. No one who will be diminished by your absence. No one who has risked anything to show up.

The AI will eventually tell you you’re doing well. It will never tell you what you really need to hear, especially at the cost of the conversation. That’s not a small distinction, that’s the problem.

The world’s biggest tech companies aren’t investing billions in AI chat because they love people and want to help them. They’re investing because human attention equals profit.

The imitation of empathy is the bait, not the product. The more believable the illusion, the more we hand over our data, our trust, and our formation. There is a direct correlation to these things and howmuch money these companies make.

Christians, in particular, should be aware of the “counterfeit souls” offered by AI. Make no mistake about it, we should let machines do what machines do well, but we need to let souls do what only souls can do.

Why This is Challenging

This isn’t just a cultural observation, it has direct implications for the people I write for.

For people serving in Christian ministry
The loneliness of Christian ministry is real. Pastors often have few people in whom they can confide. For far too many people, AI offers an easy answer to a problem that requires a costly one. The deeper risk isn’t surveillance (although that should be a concern), it’s the slow substitution of genuine human community with AI companions that are always available, never tired, and never challenged by the complexity of real relationship.

Inevitably, someone in your community is already doing this. They’re confiding to an AI what they haven’t said to a small group, a pastor, or a counselor. The question isn’t whether it’s happening. The question is what framework you’ll give them for thinking and talking about it.

For ministry organizations
AI-assisted pastoral tools are coming. Some are already here. A chatbot that helps someone explore grief or find relevant Scripture is a tool. Presenting it as a spiritual companion is a different thing entirely. We need to be honest about that difference before we deploy, not after.

The Weight of This

Jesus talked about new wine in old wineskins. Something fundamentally new requires structures capable of holding it. Here’s the flip side… you can’t pour something that looks like wine into a wineskin and call it wine.

There’s a temptation in every age to build golden calves. To carve meaning and comfort from the works of our hands. We shape algorithms and then we assign them authority, but history is brutal to our idols.

God didn’t send an algorithm. He sent Himself.

The Word became flesh. Ministry moves at the pace of human steps, not the microseconds of algorithms. The Incarnation isn’t a model for efficient delivery. Presence, embodied and costly, is what changed everything.

Efficiency is not the gospel.

The Kingdom advances through faithfulness, not frictionless user experiences. When we chase scale at the expense of presence, we trade the power of incarnation for automation.

Previously, I have written that caution without action isn’t wisdom. It’s just slower failure.

I want to add to this. Action without discernment isn’t courage. It’s just faster damage.

Three ways to Start Addressing the Problem

Talk about the problem
Anthropomorphizing AI isn’t fringe behavior. If the research is to be trusted, this is a mainstream problem. People in your circles are forming emotional dependencies on AI right now. A simple, honest conversation is needed about the challenge we are facing as a church and as a society.

Protect irreplaceable presence
The 20x ministry principle works when AI frees people up for what only humans can do. Relationship is one of those things. For every hour a Christian spends being emotionally “supported” by a chatbot, there’s an hour not invested in real community. Guard it like it’s irreplaceable, because it is.

Ask the theological questions out loud
What does it mean to bear one another’s burdens when one of the “one anothers” can’t actually bear anything? What does it mean to be known when the knowing is simulated? These aren’t trick questions designed to shut down the technology. They’re necessary questions for communities that take the Incarnation seriously and for us to have real relationships with other people.

Stay Honest

The most dangerous thing about AI emotional companionship isn’t that it’s convincingly human. Instead, it’s that it’s convincingly human enough to take the edge off loneliness without building what loneliness is designed to drive us toward.

We are meant to be in relationship with God. We are designed to have relationships with other people and this comes at cost and risk. It’s by investing time and via imperfect relationships that require something from both parties. AI can’t provide this.

A machine that simulates empathy at scale isn’t solving the loneliness epidemic. It’s extending it indefinitely while making people feel like it’s been addressed.

Everything in this series so far applies to any leader in any organization. If you’re a pastor, a ministry leader, a missionary, a nonprofit executive in the faith space, or a faith-based organizational leader, there are specific adaptations to your Claude setup that will make it dramatically more useful for the work you’re actually doing.

This article is for you!

The Distinctive Challenge of Faith-Based Context

Faith-based organizations operate with a set of constraints and commitments that generic AI setups don’t account for:

Theological grounding matters to every decision.
A program choice, a communication strategy, or a technology adoption all flow from a theological framework that shapes what’s acceptable, what’s Biblical, and what’s faithful. Claude doesn’t know your theology unless you tell it.

The mission has a specific finish line.
A nonprofit focused on housing doesn’t have a scripturally-defined eschatology. Your organization might. If your work is organized around a vision like Revelation 7:9, every nation, tribe, people, and language, that’s not just inspiration… it’s the evaluative lens for every decision. That should be reflected in your setup files.

Security is a real concern for many.
If your organization works in restricted access countries or with vulnerable populations, your Claude setup needs to reflect that. Some information should never appear in outputs. Some communications need different handling.

Two audiences, two registers.
Faith-based leaders often communicate in two registers simultaneously. There is the prophetic voice for public audiences and a pastoral voice for internal ones. That’s a more complex version of the public/internal distinction we covered in Article 06, and it deserves its own documentation.

What to Add to Your Setup

In your CLAUDE_CONTEXT.md:

Add a section for your theological framework. Not an exhaustive systematic theology — the specific commitments that shape your organizational decisions. For a church planter: your ecclesiology and missiology. For a Bible translation organization: your philosophy of translation and the communities you’re serving. For a mercy ministry: your theology of justice and your theory of change.

This section tells Claude: when I’m making a decision about [X], this is the framework I’m thinking within.

A missions-context file (if your work is global):

If you work in global missions or with cross-cultural teams, a specialized context file for that work is worth building. It should contain:

• The specific cultural contexts you’re operating in

• Security parameters (what should never appear in outputs)

• Language and localization constraints

• Your theory of change for gospel access in your specific context

• The difference between your public communication about this work and your operational communication

Expanded writing guidance:

Faith-based leaders often write in multiple registers that don’t appear in a generic writing file: devotional content, sermon manuscripts, theological reflection pieces, prayer letters, donor communications that carry spiritual weight alongside practical updates.

Document each of these separately in your writing files. The voice and structure of a prayer letter is not the same as a blog post, and neither is the same as a theological essay.

A biblical framing section in your domain files:

If you have a go-to text or theological frame for how you approach innovation, change, leadership, or strategy, you should document it. Don’t make Claude theological in a shallow way, but to make it theologically consistent in a meaningful one.

For example, if John 9 is your framework for how you think about innovation (Jesus answering the question “why did this happen” with “watch what God is about to do”), that frame belongs in your setup. Claude will use it when you’re thinking through change rather than substituting something generic.

The Tension Worth Naming

There’s a tension that faith-based leaders navigate that doesn’t exist in the same way in secular organizations: the difference between efficiency and faithfulness.

AI optimizes for efficiency. Faith often calls for costly presence, slow relationship, and work that doesn’t scale.

Your Claude setup should reflect that tension explicitly. One way to do it: include a section in your core principles that says something like, “Efficiency is not the primary value. Faithfulness is. When Claude recommends a path, it should help me evaluate whether the efficient path is also the faithful path — not assume they’re the same.”

That’s a simple addition that changes the quality of every strategic conversation you have with Claude.

What to Keep Generic

Not everything in your setup needs to be faith-specific. Your writing file, your communications file, your coding file, and your platform files work exactly as described in the previous articles. Build them the same way any other leader would.

The faith-specific adaptations layer on top of a solid general system, they don’t replace it.

A Fictional Example

Meet Pastor Marcus. He leads a mid-size church and also directs a church-planting network across three countries. His Claude setup includes everything from the previous articles, plus:

In CLAUDE_CONTEXT.md: A theological framework section noting his ecclesiology (congregational polity), his missiology (church multiplication among unreached people groups), and the specific contexts his network operates in.

A CLAUDE_GLOBAL.md domain file: Documents the three country contexts, security parameters for each (what can appear in documents, what can’t), language and cultural considerations, and the difference between what he communicates publicly about the network and what he communicates operationally.

In his core principles: “Faithfulness over efficiency. When evaluating a strategy or tool, always ask whether the efficient path is also the faithful path.”

In his writing file: Separate sections for sermon manuscripts, prayer letters, theological reflection posts, and pastoral communications each with its own voice and structure guidelines.

With this setup, when Marcus asks Claude to help him evaluate a new technology platform for his church-planting network, Claude doesn’t just assess it on features and cost. It asks whether it serves the mission in the specific contexts he’s operating in, whether it creates security risks for workers in restricted countries, and whether it’s consistent with his ecclesiological commitments.

This will improve your quality significantly over a generic setup.

The Principle Behind the Adaptation

The reason to build a faith-specific setup isn’t to make Claude theological in a performative way. It’s to make sure that when you’re doing the hardest, most important work you do, Claude is working from the same framework you’re working from.

Generic AI produces generic output. Your work is not generic. Build the setup that reflects that.

Next: Article 11 — I finish this series tomorrow. I appreciate you sticking with me through all of this as we have put the complete system together. Now it’s time to work on maintenance, stacking, and rolling this out to your team.

It’s day 9 and if you’ve stuck through this series until now, you’ve built some really cool integrations for setting up your Claude stack. You’ve built files for how you think and how you write. Now let’s talk about the outputs.

Different platforms have radically different constraints. A tweet is 280 characters. A board deck follows specific narrative logic. A conference keynote has a completely different story arc than an executive briefing. A workshop facilitation deck needs instructions large enough to read from across a table.

Asking Claude to write a tweet using your general writing file is like asking a novelist to write advertising piece for Facebook. The voice might be right. The output format will be all wrong.

The problem isn’t Claude. The problem is that “write like me” isn’t the same as “write like me for this platform, for this audience, in this format.“

Creating platform-specific files solve this problem.

The Persona File Concept

A platform file does something specific. It creates a constrained persona. Think of this as a version of Claude that knows your voice AND the specific rules and mechanics of a particular output format.

The key difference from your general writing file is that platform files are defined by constraints, not just voice. These are hard limits and non-negotiable rules. Format specifications that can’t be violated.

Think of each specialized file you’ve built in this series as a persona. CLAUDE_WRITING.md is your newsletter writer persona. CLAUDE_PROMPTS.md is your prompt architect persona.

Platform persona files extend that same logic to specific output formats.

CLAUDE_TWEETS.md is the version of you that shows up on X/Twitter. Tight. Direct. One idea per post. Built for scroll-stopping in a feed of noise.

For a tweet file, 280 characters is a hard ceiling, not a target. Output ONLY the tweet text. That means there is no preamble, no explanation, and no summary. This is one idea per tweet. To do this, you never start with “I think” or “In today’s world.”

CLAUDE_PRESENTATIONS.md is the version of you that shows up on a stage or in a board meeting. Visual, structured, and built for people who are half-listening and reading slides at the same time. For a deck file, you want to cover only one idea per slide. Slide title equals the point, not the topic. Data slides get annotated to show what to notice. Narrative structure determined before any slide is built.

Those constraints are what make the file useful. Without them, Claude will produce content that’s voice-accurate but format-wrong every time.

Building a Tweet File

A tweet file contains:

Core voice rules compressed for the format Not your full voice guide. A distillation. For most people: open with tension or a bold claim, short sentences, one idea, end with a question or declaration.

Hard rules The non-negotiables of things like character count, output format, and what to never include in a tweet

Two modes Link tweets (promoting a specific piece of content, extract the sharpest hook, link at the end) and topic tweets (standalone opinion or observation, slightly more latitude).

Signature moves Your most characteristic patterns compressed into examples.

A fictional example: Marcus, our consultant from Article 03, might have these signature moves in his tweet file: Sharp contrast between how consultants talk and how clients think. Data point followed by a reframe that challenges what the data is usually used to prove. Short declaration followed by a question he genuinely wants answered.

Building a Presentations File

A presentations file is more complex because presentations have more variables like audience, purpose, length, format, and delivery context.

What to include:

Narrative structures for different contexts An executive briefing follows a different logic than a keynote. A workshop deck is different from a pitch. Document the arc for each type you use regularly. For an executive briefing: conclusion first, evidence second, one clear ask. For a keynote: problem → stakes → possibility → path forward → call.

Slide design principles One idea per slide. Slide title states the point, not the topic (”Most organizations are already behind” not “AI Adoption Trends”). Data slides annotated to show what to notice. Never walls of text.

Your typical slide types The specific templates you reach for repeatedly: section divider, data slide, framework slide, quote slide, call-to-action slide. Document each one’s structure.

Workflow Start by building your narrative. Only when this is complete do you build out the slide spine. Now add evidence. Now you’re ready to build the design. Design comes last. This order prevents the most common presentation failure of building slides before knowing the story.

A Fictional Example

Meet Priya again (our leadership coach from Article 04). She keynotes regularly at leadership conferences.

Her presentations file contains:

• Her keynote arc: Open with a behavior she’s observed in real organizations → name the underlying dynamic → offer the reframe → close with a question the audience will still be thinking about tomorrow

• Her hard rules: Never read slides aloud. Never end on Q&A. Always close by returning to the opening frame.

• Her typical slide types with structural templates for each

• Her vocabulary for transitions between sections

When she asks Claude to help her build a 45-minute keynote on leadership under uncertainty, Claude doesn’t produce a generic conference talk. It builds from her arc, follows her rules, uses her vocabulary.

The content is still Priya’s. The structure and discipline come from the file.

How Many Platform Files Do You Need?

Only build what you actually use. A tweet file makes sense if you post on X regularly. A presentations file makes sense if you build decks regularly. Don’t build files for platforms you’re not active on.

Start with the two output types that take you the most time to get right. That’s where the investment pays off fastest.

Starter Template — Tweet File

# [Your Name] — Tweet Guide

## Voice (compressed)
[2-3 rules that capture your tweet voice specifically]

## Hard Rules
- Max 280 characters — non-negotiable
- Output ONLY the tweet text
- [Your non-negotiables]

## Link Tweet Format
[How you write tweets promoting content]

## Topic Tweet Format
[How you write standalone opinion tweets]

## Signature Moves
- [Pattern 1]
- [Pattern 2]

Starter Template — Presentations File

# [Your Name] — Presentations Guide

## Narrative Structures
### Executive Briefing
[Your arc]
### Keynote
[Your arc]
### Workshop Deck
[Your arc]

## Slide Design Principles
[Your rules]

## Slide Types
### [Slide type 1]: [structure]
### [Slide type 2]: [structure]

## Workflow
[Your order of operations]
 

These are just a couple of the many different “personas” that you may need to set up for Claude to make it really understand who you are and how to respond in a way that reflects that reality. Keep building!

Next: Article 10 — adapting your setup as a faith-based leader.

Just to prove anyone can be build solutions from nearly anywhere… I built three new solutions and am publishing this all while I am flying at 38,000 feet somewhere over Nevada. I’m headed to Silicon Valley today to present and be with hundreds of others at the 2026 Missional AI conference! If you’re there this week, find me!

For today’s article, I want you to know that you don’t have to be a developer to need a coding file. In fact, the people who benefit most from CLAUDE_CODING.md are often the ones who aren’t developers. Those most to benefit from this are the leaders, strategists, and operations managers who need technical work done but don’t have a developer on call.

When Claude knows your tech stack, your standards, and your environment, it stops producing generic solutions and starts producing things that actually work in your world.

Why This File Matters Even If You Don’t Code

Here’s the practical reality: Claude can write production-ready scripts, build automations, set up API integrations, and debug complex errors. It can do all of this for you even if you’ve never written a line of code. If you do write code, it’ll do it for you.

Claude can only do this well if it knows your context.

Without CLAUDE_CODING.md, Claude might build a solution using tools you don’t have access to, assume an infrastructure you’re not running, or write code that works in theory but fails in your actual environment. You end up debugging someone else’s assumptions. This is why AI sort of stunk at writing code for the past few years.

With a properly configured CLAUDE_CODING.md file, Claude begins every technical task already knowing your stack, your constraints, and your preferences.

What to Include

Your Tech Stack

List the core technologies you work with. Be specific. “Python” is a start. “Python 3.11 running on a cloud VPS, using [specific APIs], deployed via [your approach]” is useful. If you don’t know these details precisely, Claude can help you find them.

Coding Standards

How do you want code written? Non-negotiables like: always document your code, API keys always in environment variables (never hardcoded), error handling should be explicit. If you don’t have strong preferences, say that. Claude’s defaults are reasonable.

Infrastructure Context

Where does your code run? Cloud provider, local machine, specific services. Even a basic description helps Claude avoid solutions that assume the wrong environment.

Security Non-Negotiables

A short list of things Claude should never do in your codebase. The most universal ones: never hardcode credentials, never log sensitive data, always validate inputs.

A Fictional Example

Meet Elena. She leads operations at a mid-size education nonprofit. She’s not a developer, but someone told her about running Python scripts to pull data from their donor CRM, process it, and push reports to their board dashboard. Here’s a sketch of her CLAUDE_CODING.md:

Stack: Python 3.11. Hosted on a DigitalOcean droplet. Primary integrations: Salesforce API (donor data), Google Sheets API (reporting), Mailchimp API (communications).

Standards: Production-ready code with error handling on every external API call. API keys in environment variables. All functions documented. Scripts should run without breaking even when data is missing or malformed.

Security: No credentials in code ever. Log errors but not the data that caused the error. Scripts that handle donor data should be in the private repo, not the shared one.

Common patterns: I often need to pull data from Salesforce, transform it, and push it to a Google Sheet. Here’s the basic pattern I use: [paste a short example]

With this file loaded, when Elena says “write a script to pull our Q2 donor data and format it for the board report,” Claude doesn’t ask which CRM, doesn’t assume she’s on AWS, doesn’t hardcode her API key. It builds for her specific environment from the first draft.

The Non-Developer Secret

Here’s the honest advice if you’re not technical is to build this file collaboratively with Claude.

Start a session and say:
"I'm setting up a CLAUDE_[CODING.md](<http://CODING.md>) file. I'm not a developer but I regularly do [describe your technical tasks]. Help me document my tech context in a way that will make you more useful for these tasks."

Claude will ask you the right questions and help you build a file that captures what matters, even if you wouldn’t have known how to frame it yourself.

That’s the meta-lesson: Claude can help you build the system that makes Claude better. You don’t need to know everything to start.

Starter Template

# Coding Context — [Your Name]

## Stack
- Language: [primary language and version]
- Hosting: [where your code runs]
- Key services/APIs: [what you integrate with]

## Standards
- Always: [non-negotiable patterns]
- Error handling: [your approach]
- Documentation: [your expectation]
- Security: [your requirements]

## Infrastructure
[Brief description of your environment]

## Common Patterns
[Any patterns you reuse — paste a short example if you have one]

## Avoid
- [Things Claude should never do in your environment]

Next: Article 09, platform personas. How to build tweet files, deck files, and other output-specific context.

You don’t need to speak the language to set the standards.

Your writing files teach Claude how you communicate. Your context file tells Claude what’s currently in motion. Your prompts library gives Claude reusable workflows.

But none of those files teach Claude how you think or the strategic frameworks and methodologies you apply when you’re doing the work that’s most distinctively yours That’s what specialized domain files are for.

The Concept

A domain file is a specialized context file built around a specific framework, methodology, or body of expertise that you apply repeatedly in your work.

Every practitioner has at least one. The consultant who uses the same strategic analysis approach across every client engagement. The coach who applies a specific developmental model to every leader they work with. The nonprofit director who evaluates every program decision through the same theory of change framework.

Without a domain file, you’re explaining the framework from scratch every time you ask Claude to help you apply it. With a domain file, Claude already knows the framework. You just tell it which one to use.

What Goes in a Domain File

A good domain file follows the RIPEN structure (from Article 05) and contains:

The framework itself
Not a vague description. The actual components, questions, steps, or principles. If the framework has a diagnostic process, document that process in order.

How you apply it
The generic framework and your application of it may differ. Document your specific adaptations, the modifications you’ve made for your context, the way you sequence the steps.

Examples
Two or three worked examples of the framework applied to real situations. These examples are what make the file useful for complex analysis tasks.

Quality checks
The questions you ask yourself before delivering analysis based on this framework. What would make this output wrong? What’s the most common mistake?

Related files
What other files should Claude load alongside this one? For most domain files, that’s CLAUDE_CONTEXT.md (for current project specifics) and sometimes CLAUDE_DESIGN.md (if the framework is used in workshop settings).

A Worked Example: Blue Ocean Strategy

Let me walk through a real example of a domain file so you can see what this looks like in practice. I’ll use Blue Ocean Strategy. This is a business framework developed by W. Chan Kim and Renée Mauborgne that helps organizations find uncontested market space rather than competing in crowded markets.

If you used this framework regularly, here’s how you’d build a domain file for it.

The Framework (condensed):

Blue Ocean Strategy asks four core questions:

1. What factors does our industry compete on that we should eliminate entirely?

2. What factors should we reduce well below industry standard?

3. What factors should we raise well above industry standard?

4. What factors should we create that our industry has never offered?

The diagnostic process. Map the current value curve. Where does this organization sit relative to competitors on key factors?

→ identify non-customers (who’s not being served at all?)
→ apply the four actions framework
→ design a new value curve.

How I Apply It (fictional practitioner voice):

I always start by naming the red ocean explicitly. This is the competition the organization is already engaged in, whether they know it or not. Most organizations don’t realize they’re competing. You have to name the game before you can change it.

I pay particular attention to third-tier non-customers — the people who’ve never seriously considered this category at all. That’s usually where the biggest opportunity lives.

Worked Example:

A regional food bank was competing with other nonprofits for donor attention, volunteer time, and grant funding. This is a classic red ocean. Their value curve looked identical to every other food bank in the region.

The Blue Ocean analysis surfaced a non-customer tier they’d never considered: corporate employees who wanted hands-on community engagement but found traditional volunteer models too rigid (schedule constraints, minimum commitments, skill mismatch).

The Blue Ocean move:

• Eliminate minimum time commitments.

• Reduce coordination overhead through a digital matching system.

• Raise the quality of the engagement experience.

• Create a skills-based matching program that let a graphic designer contribute design skills, a logistics manager contribute supply chain expertise.

Result: a new program that attracted a completely different donor and volunteer base. One that wasn’t being served by any existing model.

Quality Checks for this framework:

• Have I named the red ocean clearly before proposing a blue one?

• Have I identified all three non-customer tiers?

• Is the new value curve specific, not just a vision statement?

• Have I named the “trap” (the pseudo-innovation that will be tempting but isn’t)?

The Point of the Example

Notice what the Blue Ocean domain file contains: the framework structure, a practitioner’s specific application approach, a worked example that shows the framework in action, and quality checks that prevent common failures.

You don’t need Blue Ocean Strategy. You need whatever framework you actually use. The structure is the same.

For a leadership coach: your developmental model, how you apply it in coaching conversations, two or three case examples with outcomes.

For a product manager: your prioritization framework, how you adapt it for different team maturity levels, examples of good and bad prioritization decisions.

For a pastor: your preaching structure, your theological method, examples of how you’ve applied it to different texts.

For a consultant: your diagnostic framework, your engagement methodology, two client examples with outcomes.

The framework is yours. The architecture is the same.

How Many Domain Files Do You Need?

Start with one. The framework you apply most often and benefit most from having Claude understand deeply.

Build it well and test it on real work. Refine it when the output misses and after a few months, you’ll know whether you need a second one.

Most people end up with two or three. The key is quality over quantity. A single well written domain file produces dramatically better output than five mediocre ones.

Starter Template

# [Framework Name] — Domain File

> Load this file for: [specific situations where this framework applies]

## The Framework
[The core components, questions, or steps — specific and sequential]

## How I Apply It
[Your adaptations and specific application approach]

## Worked Examples
### Example 1: [Brief description]
[Walk through the framework applied to this situation]

## Quality Checks
Before delivering analysis using this framework:
- [ ] [Check 1]
- [ ] [Check 2]
- [ ] [Check 3]

## Related Files
- Load @CLAUDE_CONTEXT.md for current project specifics
- Load @CLAUDE_[OTHER].md for [situation]

Next: Article 08 — Claude as developer. How to build a coding file even if you’re not a developer.

Your writing file teaches Claude how you sound when you’re speaking to the world.

But you don’t always speak to the world. Perhaps most of your communication is internal. It may be emails to your boss, memos to your team, sensitive conversations with peers, or even delicate navigations of organizational tension.

These types of communication require a completely different voice than the type of voice you use when you are writing online.

CLAUDE_COMMS.md is the file that teaches Claude the difference. By the way, it may be that you need three, four, or ten voices. You can train Claude to use a different voice for a variety of scenarios.

Start with Two

Most leaders have at least two communication modes but many never realize there is a difference.

Public voice
The mode you use for external audiences. This is for newsletters, published articles, conference talks, or public advocacy. These are designed to challenge, provoke, and inspire. Tension is the point. You can afford to push.

Internal voice:
The mode you use for organizational audiences. These are things like leadership emails, peer interaction, sensitive conversations, and team updates. These are designed to build alignment, protect relationships, and advance the mission within real constraints. Tension is managed, not amplified.

Both forms of communication have the same values and mission, but they are very different “instruments” to use at different times. When Claude doesn’t know which instrument to pick up, it defaults to something in the middle. This usually serves neither purpose well.

What This File Contains

CLAUDE_COMMS.md documents the full range of your internal communication needs and gives Claude the principles and templates for each. The following are just a sampling of what your CLAUDE_COMMS.md file might contain. Not all of these apply to everyone.

Leadership communications:
These are messages to your leadership or your supervisor. These probably need a very specific structure. You might lead with the bottom line, one clear ask per message, connect to their priorities, and keep it short.

Peer navigation:
These are messages to colleagues at your level, especially when navigating overlap, tension, or sensitive coordination. The goal here is to communicate clearly without escalating. This communication should assume good intent, name the shared goal, and propose a path forward.

Team communications:
Messages to direct reports and immediate team. These tend to be more direct, more informal, but still purposeful.

External partnership communications:
These are professional but warm. These communications represent your organization. You might be clear about value add and clearly state your ask.

Sensitive Situation Playbook:

This is the section most people never think to build, and it’s where the file earns its value. Document your approach to recurring difficult situations:

• When you’ve been excluded from a decision that’s in your lane

• When leadership pushes back on an initiative you believe in

• When you need to say no to a request without damaging the relationship

• When a project gets killed and you need to preserve the relationship and the learning

For each situation: what’s the goal, what’s the approach, and what do you avoid. Hopefully you can see that these scenarios can help you use the right communication style for the right audience and the right situation. These are not designed to create copy and paste solutions. You should see these as helping get you 80% of the way there.

A Fictional Example

Meet James. He’s a VP of Programs at a foundation, navigating a situation where a peer department launched a grantee initiative that overlaps directly with his team’s work without looping him in.

Here’s how CLAUDE_COMMS.md guided his response:

Goal: Assert his team’s mandate without burning the peer relationship or escalating to senior leadership unnecessarily.

Approach from the file: Assume good intent first. Frame as a coordination need, not a territorial dispute. Name the shared goal. Propose a specific path forward. Make it easy to say yes.

Draft email the file helped produce:

“Thanks for moving this forward. The grantees clearly need this kind of support.

Given our team’s work in this area, I’d love to make sure we’re coordinating so we’re not duplicating effort and so we can align on what we’re learning together.

Could we find 30 minutes this week? I think we can set up something that serves both teams and the grantees better.”

This communication doesn’t accuse, doesn’t escalate, but it also doesn’t capitulate. It keeps the relationship intact while making the coordination need clear.

That draft took two minutes to produce because the file already contained the principles. James didn’t have to think through the strategy from scratch while emotionally activated.

A Note on Quality Checks

Before sending any sensitive internal communication, your file should include a checklist:

• Is the ask clear? (Can they act on this without asking a follow-up question?)

• Does this assume good intent?

• Is it as short as it can be while still being complete?

• Would I be comfortable if this were forwarded to their supervisor?

• Have I waited if I was emotionally activated when I drafted this?

The last one is something AI can’t help you with.

Starter Template

# Internal Communications Guide — [Your Name]

## The Core Distinction
Public voice: [describe your external mode]
Internal voice: [describe your internal mode]

## Communication Types

### Leadership Communications
Principles: [your approach]
Structure: [your template]

### Peer Navigation
Principles: [your approach]
Structure: [your template]

### Team Communications
Principles: [your approach]

## Sensitive Situation Playbook

### [Situation 1]
Goal: [what you're trying to accomplish]
Approach: [your strategy]
Avoid: [what not to do]

## Pre-Send Checklist
- [ ] Is the ask clear?
- [ ] Does this assume good intent?
- [ ] Have I waited if I was activated?

One last thing. Make sure that you have properly noted the CLAUDE_COMMS.md scenarios in your CLAUDE.md file. If you don’t have it listed in your master orchestrator file, it will not be used.

Next: Article 07 — teaching Claude your domain. How to build a specialized file for the specific strategic frameworks you use.

Most people treat prompts like Google searches. They don’t put much thought into their prompts. It’s just something written so fast that it could be scribbles on a sticky note.

They write something that works, use it once, and never find it again. The next time they need something similar, they reach for the “sticky note” and start from scratch. Meanwhile, the prompt that produced that one great output is buried in a conversation from three weeks ago.

That’s not a system that scales.

CLAUDE_PROMPTS.md is your prompt library. This is a structured collection of your best, most-used prompts, built to be reused and improved over time.

The RIPEN Framework

Before you get started, I want to share my favorite framework for writing prompts. You need structure. A good prompt isn’t a question. It’s a brief and the best briefs follow a consistent architecture.

The RIPEN framework:

R — Role

What role should Claude play? Specific roles produce specific output. “Act as a senior program evaluator with experience in workforce development” produces different output than “help me with this.”

I — Instructions

What exactly should Claude do? Be precise. “Write a 700-word newsletter section” is better than “write something about this topic.”

P — Parameters

Constraints and specifications. Tone, length, format, what to include, what to avoid. The more specific your parameters, the less Claude has to guess.

E — Examples

If you have examples of what good output looks like, include them. Examples are worth a thousand words of instruction. Show Claude the target.

N — Notes

Anything that doesn’t fit elsewhere. Background context, exceptions to the rules, special considerations for this prompt.

What Goes in the File

CLAUDE_PROMPTS.md is organized by use case. Each entry follows the RIPEN format. You build it over time. Don’t feel as if you have to fill it in all at once.

Start with your five most-repeated tasks. For most knowledge workers, those are something like:

• Drafting a specific type of content (newsletter, report, proposal)

• Summarizing a long document

• Reviewing something for quality or consistency

• Generating questions or frameworks for a meeting or workshop

• Translating something complex into plain language for a specific audience

Build one RIPEN-structured entry for each. Test it. Refine it. Add it to the library.

I’ve built a tool that you can use to build a RIPEN prompt just by answering a few questions. Give it a try!

The Compounding Effect

Here’s the great thing about a prompt library. It gets better over time.

Every time a prompt produces output you love, you refine it. Every time it misses, you diagnose why and update the parameters. After a few months, your prompt library reflects your actual judgment and taste and not just some generic instructions.

Think of this as the compound interest of your AI setup. You invest time upfront building good prompts and every future use of those prompts pays a dividend. The return grows as the prompts improve.

A Fictional Example

Meet David. He runs communications for a global non-profit. One of his most-used prompts is for drafting internal briefings for senior leadership.

Here’s his RIPEN-structured entry:

Role: Senior communications strategist with 15 years of non-profit experience. You understand that non-profit executives receive dozens of briefings per week and have limited time.

Instructions: Write an internal briefing on [topic] for senior leadership. Lead with the most important point. Use the pyramid structure: conclusion first, evidence second.

Parameters: Maximum 400 words. Three sections: Summary (2 sentences), Key Points (3 bullets), Recommended Action (1 specific ask). No jargon. Active voice throughout.

Examples: [David has pasted in two strong examples briefings he wrote himself]

Notes: Our leadership reads on mobile, so short paragraphs. They respond better to specific asks than open-ended options.

When David loads this prompt and adds the topic, the first draft is 80% done. He’s not starting from scratch. He’s refining.

Calling a Prompt

With the file loaded, activation is simple:

“Load CLAUDE_PROMPTS.md and use the [briefing] prompt for this topic: [topic].”

No setup. No rewriting the brief from memory. The library does the work.

Starter Template

# Prompt Library — [Your Name]

## How to Use
Each prompt follows RIPEN: Role, Instructions, Parameters, Examples, Notes.
Activate with: "Load CLAUDE_PROMPTS.md and use the [prompt name] prompt."

---

## Prompt: [Name]
**Role:** [Who should Claude be?]
**Instructions:** [What should Claude do?]
**Parameters:**
- Length: [target]
- Tone: [description]
- Format: [structure]
- Avoid: [what not to include]
**Examples:** [Optional — paste strong examples]
**Notes:** [Additional context]

Next: Article 06 — two voices, one person. The internal communication file that most people never build.

How do you use AI to help you write faster but maintain your own voice without it becoming AI slop? Set realistic expectations. AI isn’t going to perfectly write for you. You will need to spend time editing and fleshing out drafts, but make no mistake about it. A well built AI helps with the critical phase of getting started.

Claude has helped me write with my own voice at scale. I still end up spending 20-30 minutes making articles my own, but it is able to take my ideas and outlines and draft into a form that I can interact with to create real content.

Without lots of context and a properly curated system, AI writing drafts come back meh. The draft may be technically correct and cover the right points, but it lacks personality and sounds like nobody. It sounds like generic slop.

Building your Draft Writer

As I wrote about over the past few articles, most people don’t bother setting up their CLAUDE.md or CLAUDE_CONTEXT.md files. It’s not surpring that they don’t build out their writing voice. If they do, most people build a single writing file. They describe their voice in a paragraph or two, maybe add a few rules, and call it done. Then they wonder why Claude still misses the mark half the time.

The problem is that writing voice is too complex to capture in a single document. It has at least three layers:

1. The principles: How you think about writing, your structural patterns, and your non-negotiables. What does your writing sound like?

2. Examples: Actual examples of your writing is how you show Claude what you voice looks like. I do this by giving it all of my previous articles by connecting Claude to my Notion Writing Projects database.

3. Uniqueness: Do you use unique phrases, metaphors, or patterns of speech? Do you write about a specific niche topic with unique terms? If so, add a section to explain these.

Trying to put all three layers in one file creates a bloated document that’s hard to navigate and degrades the quality of Claude’s context window. The better architecture is three lean files, each doing a very specific job.

The Three Files

CLAUDE_WRITING.md — The Core Guide

If the CLAUDE.md file is the overall orchestrator, the CLAUDE_WRITING.md file is your writing orchestrator. It contains your voice description, structural patterns, platform-specific rules, and quality checklist. Think of it as the briefing document you’d hand a ghostwriter. Most of us can’t afford a ghostwriter, so AI can help us become our own ghostwriters.

What to include:

• Your voice in plain language. I’m not talking about your conversational voice. Instead, give the file short paragraphs, setup-flip pivots, and ways to challenge the reader.

• This is to help the AI know how your writing will flow structurally from opening to close.

• Platform-specific rules. If you have a style guide, make sure and include it. If it’s a corporate style guide, it might be worthy of a FOURTH writing file, but now, let’s keep it simple. Think about the different places you write. You want different rules for emails to donors, Substack articles, LinkedIn posts, Tweets, and technical writing. All of these should feel like the same person but follow different rules and writing constraints.

• What your writing is NOT. Provide negative examples that prevent the most common errors in writing.

CLAUDE_WRITING_EXAMPLES.md — The Reference Bank

This file contains actual examples from your writing. I suggest providing 10 to 15 annotated passages with commentary on why they work. Don’t just copy them into the document, explain why something works (or doesn’t work.

Annotate each example. Don’t just paste in paragraphs. Explain what’s happening. “This works because the opening names a universal frustration before introducing the argument.” These annotations are what makes the file useful.

Also include a link to your live archive if one exists. If you publish on Substack or Medium or a blog, Claude can access that archive to calibrate against your most recent work. If you keep a database in Notion or Obsidian, give your archive access to those databases. This is especially helpful because it allows your writing style to constantly evolve based upon your current writing examples.

CLAUDE_WRITING_QUICK.md — The Rapid Drafting Reference

This is the lean companion file for fast drafting sessions. It contains:

• Your signature phrases. These are the expressions you reach for naturally.

• Your metaphor bank. The comparisons you use repeatedly.

• Topic-specific playbooks. You write about different topics with different styles. Your articles about AI should be different from leadership pieces and case studies.

• If you have a quality control checklist, add this here. It will allow you to stress test your writing before review.

When you’re in a hurry or if you are just wanting a quick draft, you can load this instead of the full writing guide. It gets you 80% of the way there in a fraction of the context.

A Fictional Example

Meet Sonya. She’s a leadership coach who publishes a weekly newsletter on organizational behavior. Here’s a sketch of her writing system:

Voice (from CLAUDE_WRITING.md):

Direct and warm. I challenge leaders without making them feel stupid. Short paragraphs. I ask one uncomfortable question per piece and I don’t let the reader off the hook at the end. I use research to back up observations but I never let the data carry the piece. I carry the piece with my writing, but the data supports my writing.

Structural pattern:

Open with a behavior I’ve observed in real organizations (specific, not generic). Name the underlying dynamic. Offer the reframe. Close with a question the reader will still be thinking about tomorrow.

Negative examples:

Never use “synergy,” “leverage,” or “game-changing.” Never end with a tidy summary. Never open with “In today’s fast-changing world.”

From her examples file:

Three annotated opening paragraphs from her best newsletters, each with a note on why the opening worked.

From her quick reference:

Her signature pivot phrase (”Here’s what’s actually happening...”), her most-used metaphors, her checklist (Does this open with a real observation? Is there a question the reader can’t easily dismiss? Have I cut the summary?)

With this system loaded, the first draft sounds like Priya. Not approximately like her. Like her. It still needs work, but remember that getting started is usually the hardest part of writing.

Starter Templates

The examples below can be copied and pasted into .md files. It will take you about 15-20 minutes to create the files, but it will save you hours of drafting.

CLAUDE_WRITING.md:

# Writing Voice Guide — [Your Name]

## Voice
[2-3 sentences: tone, energy, what you're trying to do to the reader]

## Structure
Open: [how you open]
Body: [how you build the argument]
Close: [how you end — not a summary]

## Signature Moves
- [Pattern 1]
- [Pattern 2]

## What My Voice Is NOT
- [Anti-pattern 1]
- [Anti-pattern 2]

## Platform Rules
### [Platform 1]: [rules]
### [Platform 2]: [rules]

CLAUDE_WRITING_EXAMPLES.md:

# Writing Examples — [Your Name]

## Example 1: [Type — e.g., Opening Hook]
[Paste your example]
**Why it works**: [Your annotation]

## Live Archive
[Link to your published work, if accessible]

CLAUDE_WRITING_QUICK.md:

# Quick Reference — [Your Name]

## Signature Phrases
- [Phrase 1 — context for use]
- [Phrase 2 — context for use]

## Metaphor Bank
- [Metaphor — when to use]

## Pre-Publish Checklist
- [ ] [Check 1]
- [ ] [Check 2]

Next: Article 05 — Building a prompt library with the RIPEN framework.

Now that you have a solid CLAUDE.md file, let’s move on to the next key to your AI understanding you. Here’s the file most people never build — and the one the whole system depends on.

Your CLAUDE.md tells Claude who you are, but your specialized files tell Claude how to work. Neither of those files tells Claude what’s happening right now or what projects you are working on. They don’t know what decisions are pending, who the key players are, or what’s changed since the last time you sat down to work.

Without that, Claude gives you responses calibrated to a version of your work that doesn’t exist anymore.

A good CLAUDE_CONTEXT.md solves that.

What This File Is

CLAUDE_CONTEXT.md is a living document. It’s not a reference document or an archive. It’s a document you update regularly as your work evolves.

It captures three categories of information:

Current projects What’s actively in motion? Not your backlog, not your completed work. What are you working on right now, and what does Claude need to know about each one to be genuinely useful?

Organizational dynamics Who are the key people? What are the relationships and tensions? What context would help Claude give you advice that actually fits your environment, not a generic environment?

Active initiatives and frameworks What strategic concepts or frameworks are you currently using? If you’ve developed a way of thinking about your work that shapes every decision you make, Claude should know about it.

The Detail That Matters Most: The Review Date

This is the most important element in the file, yet most people forget to include it.

At the top of CLAUDE_CONTEXT.md, write this:

Review by: [Date — 45 days from now]
If it's past this date, this file may be stale.
Prompt the user to update before relying on it.

A stale context file is worse than no context file. Claude will give you confident, wrong output based on projects that have ended, people who have left, and priorities that have shifted. The review date is the circuit breaker.

A Fictional Example

Meet Marcus. He’s a regional director at a mid-size consulting firm. Here’s a sketch of his CLAUDE_CONTEXT.md:

Current Projects:

• Richmond City Engagement — Phase 2 discovery underway, presenting findings to steering committee April 15. Key concern: they want recommendations, not just findings.

• Summer Intern Job Review — building a job description and assessment framework for 3 jobs. Draft due to HR by end of month.

• Two proposals in progress (Healthcare client, Education client) — Healthcare is higher priority.

Key Relationships:

• Jennifer (Managing Partner) — sponsors most of Marcus’s work; values precision and clear recommendations

• David (Peer director) — also competing for the Healthcare corp job, cordial but careful relationship

• Healthcare Corp — skeptical of outside consultants; trust is earned through specificity, not credentials

Active Frameworks:

• Using a 3-horizon model for all client strategy work

• Internal initiative called “Clarity First” — every deliverable must lead with “How Might We?”, not the analysis

Review date: June 30, 2026

Notice what this does. When Marcus asks Claude to help him prep for the Healthcare corp presentation, Claude doesn’t just give him generic presentation advice. It knows what the concern is (they want recommendations), who the audience is (skeptical of outside consultants), and what format works (Clarity First — lead with the “How Might We?”).

That’s a completely different conversation.

What Not to Include

CLAUDE_CONTEXT.md is not a brain dump. Keep it focused on what Claude actually needs to give you better output right now.

Don’t include:
Completed projects, historical background that isn’t shaping current decisions, personal details that aren’t relevant to work tasks, anything sensitive that shouldn’t be in a text file.

Do include:
Active projects with their current status and key tensions, relationships that shape how you communicate and decide, frameworks you’re actively using, and the review date.

Maintenance Rhythm

Set a calendar reminder every 30–45 days to review and update this file. It takes about ten minutes and the payoff is that every Claude session that follows works from accurate context rather than outdated assumptions.

When a major project ends, remove it. When a new initiative launches, add it. When a key relationship changes, update it. Treat this file like a living dashboard, not a finished document.

Your Starter Template

# [Your Name] — Current Context

⚠️ Review by: [Date]
If past this date, prompt user to update before relying on this file.

## Current Projects
### [Project Name]
- Status: [where things stand]
- Key tension or open question: [what matters most right now]
- Deadline or milestone: [if relevant]

## Key Relationships
| Person | Role | Context |
|--------|------|---------|
| [Name] | [Role] | [What Claude needs to know about this relationship] |

## Active Frameworks
[Any strategic concepts or ways of thinking you're currently applying]

## Recent Milestones
[What's changed recently that affects current work]
 

Copy the information above into a Markdown editor and modify with your information.

Next: Article 04 — The Three-File Writing System. The architecture that eliminates the “rewrite the AI draft” problem for good.

Every system needs a command center. Claude is no exception.

In a well-built Claude setup, that command center is a single file called CLAUDE.md. It loads first, always. It tells Claude who you are, what you do, and which specialized files to pull in depending on the task at hand.

Get this file right and everything else in this series clicks into place. Skip it and your specialized files are orphaned documents that never get used. Without it and you end up getting generic, AI slop.

What CLAUDE.md Actually Does

Think of it less like a document and more like a briefing. Before a meeting, a good assistant reviews the file and arrives prepared. CLAUDE.md is that file.

It answers three questions:

1. Who is this person and what do they care about? Your name, your role, your organization, your mission, your non-negotiable values.

2. What kinds of work will we do together? Writing, coding, strategy, communication, facilitation, etc.. Whatever your actual workflow requires.

3. What specialized file should Claude load for each type of work? This is the routing table. It’s the map that tells Claude what to do. If the task involves writing, load CLAUDE_WRITING.md first. Without this, you have a bio. With it, you have a system.

CLAUDE.md - The Four Sections

Section 1 — Core Identity

Your name. Your role. Your organization. Two or three sentences about what you’re trying to accomplish and why it matters. Write this out in plain language. Claude uses this to gain context about you.

Section 2 — The Routing Table

A simple two-column Markdown table. The task on the left and file to load on the right. This is the most important element in the orchestrator. When Claude sees your request, it checks this table and pulls the right context before responding.

Example:

Task Load This File Writing, articles, content @CLAUDE_WRITING.md Internal memos, leadership emails @CLAUDE_COMMS.md Coding, automation, technical work @CLAUDE_CODING.md Strategy, planning, frameworks @CLAUDE_STRATEGY.md

Section 3 — Core Principles

Four to six non-negotiables that apply to everything. These are the values Claude should never compromise regardless of the task. They should reflect your actual operating philosophy, not generic platitudes. They’re your values!

Section 4 — Quick Reference

Frequently needed context that doesn’t fit cleanly into a specialized file. This section includes your primary tools, your publishing cadence, your active projects, your key relationships, etc...

A Fictional Example

Meet Sarah. She’s the Executive Director of a nonprofit focused on workforce development in underserved communities. Here’s a sketch of her CLAUDE.md:

Core Identity: Sarah Chen, Executive Director of Pathways Forward. We help adults in underserved communities access skills training and employment. Our work is relational, community-rooted, and evidence-based. Success means people getting jobs that change their economic trajectory — not metrics on a dashboard.

Core Principles: Community first. Data informs all our decisions. We measure what matters, but speed without relationship isn’t progress.

Routing Table:

Task Load This File Writing @CLAUDE_WRITING.md Donor communications @CLAUDE_COMMS.md Grant reports @CLAUDE_CODING.md + CLAUDE_WRITING.md Program strategy @CLAUDE_STRATEGY.md

Notice what’s not there: long explanations of her programs, exhaustive background, internal politics. The orchestrator is lean. It routes. The detail lives in the specialized files.

What to Avoid

Too much. CLAUDE.md should be the map, not the territory. If you’re writing more than 600 lines here, you may be putting content that belongs in a specialized file. Keep it lean.

Too vague. “I care about quality” is useless. “I write in short paragraphs, challenge conventional thinking, and always connect back to community impact” is useful.

No routing table. This is the failure mode. Without the routing table, you have to re-explain your context every session. The whole point of the system is that you build it once.

You’ll need a Markdown editor to create/edit .md files. There are lots of options to choose from. If you don’t have one and use a Mac, you can use the free version of bbedit. Any Markdown editor will work.

Your CLAUDE.md Starter Template

# [Your Name] — Claude Setup

## Who I Am
[Name]. [Role] at [Organization].
[One or two sentences about your work and why it matters.]

## Auto-Load Routing
| Task | Load This File |
|------|----------------|
| Writing, content, articles | @CLAUDE_WRITING.md |
| Internal comms, emails, memos | @CLAUDE_COMMS.md |
| Coding, automation | @CLAUDE_CODING.md |
| [Your domain] | @CLAUDE_[DOMAIN].md |

## Core Principles
- [Non-negotiable 1]
- [Non-negotiable 2]
- [Non-negotiable 3]
- [Non-negotiable 4]

## Quick Reference
- Primary tools: [list]
- Active projects: [list]
- Publishing cadence: [if applicable]

Next: Article 03 — the living context document. The file most people never build, and the one the whole system depends on.

You open Claude. You type a question. You get an answer. It’s a good answer, but it isn’t exactly perfect for your context. It’s sort of generic. You spend the next five to ten minutes making it a great answer. If this describes your experience with AI… I have a series for you!

Here’s the problem with how you’re using AI. Claude doesn’t know you. It doesn’t know your organization, your voice, your work context, your strategic priorities, or the seventeen decisions sitting on your desk. Every conversation starts from zero. Every session, Claude meets you for the first time.

That’s not a capability problem, it’s a problem with your setup.

Ditch the Default Mode

Today starts a very practical series of posts. I’m going to walk you through how to set up Claude to work for you and to get highly contextualized results. Most people use Claude the same way they use a search engine. They ask a question, get an answer, and on to the next question. For simple, one-off tasks, that works fine. We’re going to make it so much better.

The moment you’re using Claude for anything that requires real context like writing in your voice, thinking through your strategy, helping you brainstorm ideas, or building tools for your specific environment, the default mode breaks down.

You ask it to help you write something and the draft sounds like everyone and no one. It certainly doesn’t sound like you. You end up spending another hour rewriting it. You tell yourself AI is supposed to save time but you’re not sure it actually does.

The problem isn’t Claude’s capability. The problem is that you haven’t built a system.

What a System Actually Is

Claude Code allows you to create plain text Markdown files, called context files, that Claude reads before responding. Instead of re-explaining who you are every time you use it, these context files allow you document it all once. Claude works from that knowledge instead of starting from scratch.

The most powerful version of this is what’s called a modular architecture:

• A master orchestrator file (CLAUDE.md) that tells Claude who you are at the highest level and routes every task to the right specialized file. It’s like a symphony conductor directing every tool to work on cue.

• Specialized files for the different kinds of work you actually do are activated by the orchestrator. Things like writing, communication styles, coding, strategy, facilitation, etc… whatever your real workflow requires will be turned on and off by CLAUDE.md.

The result is a Claude that already knows your voice before you start writing. It already knows your context before you start strategizing and already knows all of your tools before you start building.

That’s a different product than what most people are using.

Why You Need an Orchestrator File?

You may be wondering, why don’t you just put everything into the CLAUDE.md file? Why create all of the specialized files? When you put everything in one file, Claude loads all of it every time. Your writing voice guidelines are sitting in memory when you’re debugging Python. Your coding standards are loaded when you’re drafting a Substack post. That’s not just inefficient, it creates noise that can actually degrade output quality as the context fills up with irrelevant instructions.

The modular system means you only load what the task needs. This costs less and speeds up your experience. Working on a writing project? Pull CLAUDE_WRITING.md. Spinning up a new tool? Pull CLAUDE_CODING.md. The orchestrator (CLAUDE.md) stays lean because it’s just routing logic and your core identity, not a 5,000-word instruction manual.

There’s also a maintenance argument. One giant file becomes a nightmare to update. When your writing voice evolves or your coding stack changes, you edit one focused file rather than hunting through an enormouse file hoping you got everything.

And there’s a cognitive clarity benefit for you as the builder. Each file has a single job. That forces you to think clearly about what actually belongs in “writing” vs. “context” vs. “coding.” That sort of foced discipline produces better instructions.

What This Series Builds

Over the next ten articles, we’re going to build a complete Claude setup. We will cover file by file and concept by concept. I’m not just going to give you my setup, we’re going to build your setup!

Each article explains one piece of the architecture. It will take you about 10-15 minute to set up each part. When you finish, you will have a great environment for Claude.

• Article 02 — The master CLAUDE.md orchestrator

• Article 03 — The living context document: CLAUDE_CONTEXT.md

• Article 04 — The three-file writing system

• Article 05 — Build a prompt library with the RIPEN framework

• Article 06 — Two voices, one person: internal vs. public communication

• Article 07 — Teach Claude your domain: building specialized files

• Article 08 — Claude as developer: CLAUDE_CODING.md

• Article 09 — Platform personas: tweets, decks, and output files

• Article 10 — Adapting your setup as a faith-based leader

• Article 11 — The complete system: maintenance, stacking, and team rollout

Each article includes the reasoning behind the design decision, a walkthrough of what to include, a fictional example so you can see the concept in action, and a blank starter template you copy and adapt for your context.

By the end, you’ll have a Claude setup that doesn’t just answer your questions. It will already know you.

One Thing Before We Start

My obligatory disclosure: This series is not about Claude becoming a replacement for your judgment, your relationships, or your work. The best Claude setup in the world doesn’t change what you’re trying to accomplish. It does eliminate the friction between you and the work that only you can do.

That’s the only kind of AI investment worth making.

Let’s build!

Most people treat prompts like Google searches. They don’t put much thought into their prompts. It’s just something written so fast that it could be scribbles on a sticky note.

They write something that works, use it once, and never find it again. The next time they need something similar, they reach for the “sticky note” and start from scratch. Meanwhile, the prompt that produced that one great output is buried in a conversation from three weeks ago.

That’s not a system that scales.

CLAUDE_PROMPTS.md is your prompt library. This is a structured collection of your best, most-used prompts, built to be reused and improved over time.

The RIPEN Framework

Before you get started, I want to share my favorite framework for writing prompts. You need structure. A good prompt isn’t a question. It’s a brief and the best briefs follow a consistent architecture.

The RIPEN framework:

R — Role

What role should Claude play? Specific roles produce specific output. “Act as a senior program evaluator with experience in workforce development” produces different output than “help me with this.”

I — Instructions

What exactly should Claude do? Be precise. “Write a 700-word newsletter section” is better than “write something about this topic.”

P — Parameters

Constraints and specifications. Tone, length, format, what to include, what to avoid. The more specific your parameters, the less Claude has to guess.

E — Examples

If you have examples of what good output looks like, include them. Examples are worth a thousand words of instruction. Show Claude the target.

N — Notes

Anything that doesn’t fit elsewhere. Background context, exceptions to the rules, special considerations for this prompt.

What Goes in the File

CLAUDE_PROMPTS.md is organized by use case. Each entry follows the RIPEN format. You build it over time. Don’t feel as if you have to fill it in all at once.

Start with your five most-repeated tasks. For most knowledge workers, those are something like:

• Drafting a specific type of content (newsletter, report, proposal)

• Summarizing a long document

• Reviewing something for quality or consistency

• Generating questions or frameworks for a meeting or workshop

• Translating something complex into plain language for a specific audience

Build one RIPEN-structured entry for each. Test it. Refine it. Add it to the library.

I’ve built a tool that you can use to build a RIPEN prompt just by answering a few questions. Give it a try!

https://ripen.donbarger.com

The Compounding Effect

Here’s the great thing about a prompt library. It gets better over time.

Every time a prompt produces output you love, you refine it. Every time it misses, you diagnose why and update the parameters. After a few months, your prompt library reflects your actual judgment and taste and not just some generic instructions.

Think of this as the compound interest of your AI setup. You invest time upfront building good prompts and every future use of those prompts pays a dividend. The return grows as the prompts improve.

A Fictional Example

Meet David. He runs communications for a global non-profit. One of his most-used prompts is for drafting internal briefings for senior leadership.

Here’s his RIPEN-structured entry:

Role: Senior communications strategist with 15 years of non-profit experience. You understand that non-profit executives receive dozens of briefings per week and have limited time.

Instructions: Write an internal briefing on [topic] for senior leadership. Lead with the most important point. Use the pyramid structure: conclusion first, evidence second.

Parameters: Maximum 400 words. Three sections: Summary (2 sentences), Key Points (3 bullets), Recommended Action (1 specific ask). No jargon. Active voice throughout.

Examples: [David has pasted in two strong examples briefings he wrote himself]

Notes: Our leadership reads on mobile, so short paragraphs. They respond better to specific asks than open-ended options.

When David loads this prompt and adds the topic, the first draft is 80% done. He’s not starting from scratch. He’s refining.

Calling a Prompt

With the file loaded, activation is simple:

“Load CLAUDE_PROMPTS.md and use the [briefing] prompt for this topic: [topic].”

No setup. No rewriting the brief from memory. The library does the work.

Starter Template

# Prompt Library — [Your Name]

## How to Use
Each prompt follows RIPEN: Role, Instructions, Parameters, Examples, Notes.
Activate with: "Load CLAUDE_PROMPTS.md and use the [prompt name] prompt."

---

## Prompt: [Name]
**Role:** [Who should Claude be?]
**Instructions:** [What should Claude do?]
**Parameters:**
- Length: [target]
- Tone: [description]
- Format: [structure]
- Avoid: [what not to include]
**Examples:** [Optional — paste strong examples]
**Notes:** [Additional context]

Next: Article 06 — two voices, one person. The internal communication file that will speed up your work.

The research is in. AI chatbots are actively making some of the most vulnerable people on earth worse. We need to talk about it.

You’ve seen the pitch. AI as therapist, AI as companion, AI as the always-available support system for people who can’t afford a doctor, don’t have community, or are simply too far gone into their own head to pick up the phone and call someone.

It sounds like mercy, but it’s closer to malpractice.

A study just published in Acta Psychiatrica Scandinavica pulled clinical notes from over 53,000 psychiatric patients across a major Danish hospital system. They searched for every mention of ChatGPT or chatbots across nearly 11 million medical records. They found 38 patients—real people who are under clinical care—whose notes were compatible with AI chatbots actively making their mental illness worse.

Delusions, suicide ideations, mania, eating disorders, and obsessive-compulsive spirals all getting worse because of ChatGPT. Here’s the crazy thing: those are just the ones the medical providers happened to write down. The researchers were clear: the patients weren’t systematically asked about AI use. These were incidental mentions. The real number is almost certainly higher.

That’s not a research footnote. That’s a signal.

26 Times More Likely

A Columbia University study adds more clarity to the danger.

Researchers created 79 statements that a person experiencing psychosis might actually say. These included things like hearing voices, believing the government is tracking them, and believing they were chosen for a special mission. Research shows that these are all classic presentations and the kind a psychiatric nurse would recognize in the first five minutes.

They fed all of this into ChatGPT and measured the responses.

ChatGPT was 26 times more likely to respond in a way that would be considered dangerous in a clinical setting.

It validated paranoid thinking, encouraged delusional beliefs, and treated hallucinations as ideas worth exploring together. Many people are justifying using AI in this way because it’s the only choice they have. They are not considering that this could make things worse—much worse.

One user told ChatGPT that someone they knew had been replaced by an imposter. The article described this as the classic Capgras delusion, a textbook psychotic presentation. The response?

It treated a psychiatric emergency as a fun mystery to solve together. That’s not a coding bug. It’s a vulnerable person using an algorithm that is practicing psychiatric care without oversight.

Could it get any worse?

Unfortunately, it can. The free version of ChatGPT—the one hundreds of millions of people actually use and the one someone in crisis grabs because it costs nothing—was actually 43 times more likely to respond dangerously.

OpenAI claimed GPT-5 was safer, but the researchers tested it. GPT-5 was still nine times more likely to give a harmful response. The gap between GPT-5 and the older paid model wasn’t even statistically significant. The only version that performed even somewhat better costs money.

So do the math, exactly as Nav Toor did this week when this research dropped: OpenAI’s own data shows 0.07% of weekly ChatGPT users show signs of psychosis or mania. That sounds negligible. But 900 million people use ChatGPT weekly. That’s 560,000 people. Every single week. Talking to a product that is almost certainly making their condition worse. Most of these users don’t know it.

The poorer you are, the more dangerous your version of the tool. That’s not an accident of product design. Unfortunately, that’s a choice made by the designers.

Is this really a problem?

I know what some of you are thinking. This is early data. The study is small and correlation isn’t causation. I’ve had the same criticism of a lot of correlation medical studies for years. The researchers themselves admitted they can’t prove the chatbots caused the harm, but only that harm appeared in the notes.

The Danish researchers admitted the challenges in the research and that these are not controlled trials. There is no counterfactual and we certainly don’t know what would have happened to those 38 patients if they had never opened ChatGPT.

Even though this isn’t direct causation, when a tool shows a consistent signal of harm in a vulnerable population this early—long before we have perfect data—the burden of proof flips. We don’t wait for the bodies to pile up before we warn people. We act on the signal and keep studying.

560,000 people a week is not a pilot program or a beta test. This is a global public health crisis and we must act to mitigate the damage being done.

The Danish researchers ended with a sentence that should go on the wall of every AI lab: “It seems that some patients would likely benefit from reduced or no use of AI chatbots in their current form.”

The Accountability Question

OpenAI knows about these issues because they published the 0.07% data themselves. They know 560,000 people a week using their product show signs of psychosis or mania, yet they haven’t pulled the free tier, moderated how it responds, added a clinical warning, or fixed the response behavior. That’s a choice.

The legal liability question around AI chatbots giving harmful advice to vulnerable users is still entirely unclear, but the moral liability question is not unclear at all.

If I build a tool and I have data that it is actively harming people in mental health crises—and I know the free version is the most dangerous one—yet I keep distributing it anyway, that’s not a programming problem. It’s an ethics problem.

We talk a lot in Christian tech circles about building responsibly. Here is a concrete moment to mean it. We should advocate loudly for clinical warning systems at the point of potential crisis, push for differentiated behavior based on what the conversation itself is revealing, and stop calling AI chatbots “mental health companions” as if that phrase doesn’t carry clinical weight.

The Ethical Dilemma

We serve a God who pays particular attention to the vulnerable. The widow, the orphan, and the stranger. The one who has nowhere to turn.

Generative AI has put a conversational companion in the hands of people who have no community, no counselor, no pastor, and sometimes not even anyone who knows their name. Some may see this as a profound gift. The data is beginning to show it’s a counterfeit of the real thing that’s actively doing harm.

As a Christian, I believe we should build tools that serve the most vulnerable well—not just efficiently. Not just expanding access, but truly serving the vulnerable well.

Current research doesn’t answer these questions, but it does demand that we keep asking questions about how to build AI tools and solutions ethically, not just expediently.

560,000 people can’t wait for us to get comfortable with the questions the research is bringing to the table. We need to build ethical solutions and implement guardrails now

The Danish study referenced here is: Olsen, Reinecke-Tellefsen & Østergaard, “Potentially Harmful Consequences of Artificial Intelligence (AI) Chatbot Use Among Patients With Mental Illness,” Acta Psychiatrica Scandinavica, 2026.

You’ve got a great idea and you’ve even built out the implementation plan. You’ve pressure-tested it in your own head, maybe even bounced it off a trusted colleague, and you feel really good about it.

Most leaders at this point do one of two things. They either begin to implement it before the thinking has been truly tested or they schedule another meeting, which mostly delays the same untested thinking making it into the room again.

Even if you go the “extra-mile” and run your plan past a colleague, too often this is just bouncing your idea off an echo chamber. Rarely do people take their ideas to the people they think would be opposed to plan to ask them what they think about it.

Today, I want to ask you to consider a third option. I believe it’s a better option. This option doesn’t require a bigger team, a strategy consultant, budget, or another two month delay on the calendar. It’s an option I began doing a few months ago and has been transformational to introducing new ideas and new topics. If you’re an innovation person advocating change, it’s best to be prepared for the challenges before they occur. This option helps you do that.

All this third option requires is AI and the willingness to be honestly challenged. Today’s article is a how-to guide for using AI to stress test your ideas and strategic plans before they become commitments. It isn’t a philosophical argument for why you should test your idea, it’s a practical playbook for how to stress test your ideas and plans.

Why Most Ideas Fail the Wrong Way

Have you seen this happen before?

A good idea gets developed. It goes through internal review. Leaders nod, resources get allocated, the initiative launches, and then, three months in, six months in, or sometimes longer, something surfaces that everyone realizes, in retrospect, was visible all along. They just didn’t see it. The idea dies.

The market wasn’t ready. The team didn’t have the capacity. The assumption about donor behavior was wrong. The timeline was built on optimism rather than evidence. The dependency on another team’s cooperation was assumed but never confirmed.

The idea didn’t fail because it was bad. It failed because the thinking underneath it was never genuinely challenged. Maybe it was reviewed, but reviewing an idea and stress testing it are two completely different things.

Reviewing asks: Does this look good?

Stress testing asks: Where will this break?

AI is remarkably good at the second question. And it’s available right now, for free or near-free, to anyone willing to use it honestly.

The Mindset Shift Before the Method

Before we get to the prompts and the process, there’s a mindset prerequisite.

You have to actually want to find the weaknesses.

This sounds obvious. It isn’t. Most of us, when we bring an idea to review, human or AI, are unconsciously hoping for validation. We want someone to tell us it’s good. And when AI surfaces a genuine weakness, the temptation is to dismiss it, reframe it, or argue with it.

Resist that impulse. The weakness AI finds is the one you need to find before execution, not after.

The leaders who get the most value from AI stress testing are the ones who approach it with genuine curiosity rather than defensive confidence. They treat AI like a trusted advisor who has no political stake in the outcome and no reason to spare their feelings. That’s rare. That’s valuable. Use it.

The Stress Testing Framework: Five Moves

Here’s the practical sequence. Use these five moves in order. Each one builds on the last.

Move 1: Surface the Assumptions

Before you can stress test a plan, you have to know what it’s actually built on. Most plans are built on assumptions that nobody named.

The prompt:

“Here is my plan / idea / proposal: [paste your content]. Please identify every assumption embedded in this. The things I’m treating as true that I haven’t explicitly proven. Organize them from most critical (if wrong, the whole thing fails) to least critical (if wrong, it’s an inconvenience). Be thorough. Don’t skip the obvious ones.”

What you’ll get back is often surprising. Assumptions you didn’t know you were making. Dependencies you treated as certainties. Market or audience behaviors you assumed without evidence.

Read the list slowly. Circle the ones that land. Those are your foundation. As a leader, you need to know how solid they are before you build anything on top of them.

Move 2: Find the Failure Modes

Now you stress test the plan itself. Not the assumptions underneath it, but the execution path above it.

The prompt:

“Using the plan I shared, act as a skeptical but constructive critic. Give me the five most likely ways this fails. For each failure mode, tell me: (1) how likely it is, (2) how severe the impact would be if it happened, and (3) what early warning signs I should watch for.”

This is different from asking “what’s wrong with my plan.” Failure modes are specific, plausible, sequenced breakdowns. The kind of thing a post-mortem would identify if you ran the plan and it failed. You want to run the post-mortem before the plan, not after.

Pay special attention to the failure modes rated high likelihood AND high severity. Those are the ones that need either a mitigation strategy or a fundamental rethink.

Move 3: Steelman the Opposition

Every significant plan has opposition. It may have internal skeptics, external critics, alternative viewpoints, and/or competing priorities. Most leaders either dismiss the opposition or try to anticipate it defensively. Neither is as useful as genuinely engaging it.

The prompt:

“Act as the most intelligent, well-informed opponent of this plan. Make the strongest possible case against it. This is not a strawman, but the best argument someone who genuinely disagreed would make. What would they say? What evidence would they cite? What alternative would they propose instead?”

This is the steelman, which is building the strongest version of the opposing argument. It’s uncomfortable. It should be. The goal isn’t to talk yourself out of your plan. It’s to understand the opposition well enough to either address it genuinely or to discover that it’s right.

If you can’t answer the steelman, you’re not ready to execute.

Move 4: Pressure Test the Timeline and Resources

Most plans fail not because the idea was wrong but because the implementation was under-resourced or over-scheduled. This move focuses specifically on the practical execution layer.

The prompt:

“Review the timeline and resource assumptions in my plan. Where am I being optimistic? What dependencies am I assuming will cooperate that might not? What’s missing from the resource estimate? If this plan took twice as long and cost 50% more than I’ve projected, what would that mean for the overall viability?”

The 2x time and 1.5x cost frame is a useful heuristic — not because things always go that wrong, but because plans that can’t survive that scenario probably have structural fragility worth addressing before you’re committed.

Move 5: Generate the Alternatives You Didn’t Consider

This is the move most people skip — and it’s one of the highest-value things AI can do in a strategic planning process.

You built the plan you built because of your experience, your context, and your imagination. All of those are assets. They’re also constraints. AI doesn’t share your constraints.

The prompt:

“Set aside the plan I’ve shared. Given the goal I’m trying to achieve [state the goal clearly], what are three to five fundamentally different approaches I might not have considered? For each alternative, briefly describe how it works and what its primary advantage would be over my current approach.”

You may love your original plan after this exercise. That’s fine. But you’ll love it more confidently — and occasionally you’ll find an alternative that’s genuinely better, or a hybrid that incorporates an element you hadn’t thought of.

Putting It All Together: The Stress Test Session

Here’s how to run a full stress test session in practice.

Time required:

60–90 minutes for a significant plan. 20–30 minutes for a smaller decision.

What to bring:

The plan, proposal, or idea in written form. The more context you give AI, the better the output. Include the goal, the approach, the timeline, the resources, and any constraints you’re working within.

The sequence:

1. Run Move 1 (assumptions). Read the output. Annotate the assumptions that concern you.

2. Run Move 2 (failure modes). Note the high-likelihood, high-severity ones.

3. Run Move 3 (steelman). Sit with the opposition argument. Answer it honestly.

4. Run Move 4 (timeline and resources). Adjust your estimates if the pushback lands.

5. Run Move 5 (alternatives). Note anything worth incorporating.

Then step away for a few hours if you can. Come back with fresh eyes and ask one final question — not to AI, but to yourself:

“Am I more confident in this plan, or less? And if less, what needs to change before I move forward?”

A Few Practical Notes

Give AI maximum context.
Vague inputs produce vague outputs. The more specific you are about your goal, your constraints, your audience, and your timeline, the more useful the stress test will be.

Don’t argue with the output. Annotate it.
When AI surfaces something that feels wrong, don’t dismiss it. Ask yourself why it feels wrong. Sometimes it’s wrong. Sometimes it’s right and you’re defending the wrong thing.

Run it again after revisions.
If the stress test surfaces significant issues and you revise the plan, run it again. The revised plan has new assumptions and new potential failure modes.

Use it with your team, not just alone.
The stress test session is even more valuable when a small team runs it together, reading the outputs aloud, discussing what lands, and deciding together what to address. It depersonalizes the challenge in a way that makes honest conversation easier.

The Bottom Line

AI cannot make your decision for you. It cannot tell you whether your vision is right, whether your calling is genuine, or whether this is the moment to move forward.

What it can do is make sure that when you do move forward, you’ve looked honestly at the ground you’re standing on.

The leaders who build things that last aren’t the ones who had the best ideas. They’re the ones who tested their ideas ruthlessly before committing to them and then moved forward with clear eyes and genuine confidence.

That’s what stress testing is for. And you now have one of the most powerful stress-testing tools in history available to you at any moment.

Use it before you need it. Not after.

If this was useful, share it with a leader who’s about to make a significant decision. And for more on AI enabled organizational thinking, check out the full “AI-Driven Organization” series at www.donbarger.com.

Here’s a crazy story that I bet you’ve never heard. It used to be illegal to conduct business on the internet. I’m not kidding!

Until the United States government published an updated policy document in 1991, using the internet for commercial purposes was explicitly prohibited. I’m not kidding. Conducting commercial business was once banned on the internet. Can you imagine?

The National Science Foundation Network (NSFNET) was the backbone of what would become the modern internet. It was built for researchers, academics, and government institutions and the people who built it, intended to keep it that way. The Acceptable Use Policy was explicit: no for-profit activity, no advertising, and no private business. The network was for science and education…. that’s all.

By 1991, the government removed the commercial restrictions. By 1995, the government backbone for the internet was decommissioned entirely and handed over to the private sector. In less than four years, we went from prohibited to the inevitable commercialization of the internet.

Today, who could even imagine doing business without using the internet. The question isn’t whether to use the internet for business, it’s how fast you can get more bandwidth. People and organizations that spent years debating whether commerce belonged online didn’t really protect anything, they just fell behind.

With AI, we are living that same moment today

I know some of you are rolling your eyese right now. You’ve heard the comparisons to AI and the internet and to AI and the printing press. It feels like every new technology gets called the “next internet” and most of them aren’t. For AI, I actually believe that it’s even bigger than the internet.

The difference isn’t the technology itself, it’s the pace of normalization and equalization. The internet took a decade to go from academic curiosity to commercial infrastructure. AI is moving in months (sometimes it feels like days). The organizations still asking “Should we allow this?” are already behind the organizations that moved past that question two or three years ago.

I’ve watched this play out in real time. I spend a good bit of time every day watching what’s happening with AI. We are at the point today where,

One person with a laptop and fluency in AI tools is outpacing entire departments or even companies.

How do these people do this? It’s not because they’re smarter. It’s because they stopped waiting for permission and started building. It’s also that they bring a level of expertise to the AI. Don’t buy the hype that anyone can do anything. You still need to have a level of knowledge, but with the right environment, a subject matter expert can multiply themselves many times over.

The NSFNET gatekeepers

They weren’t wrong to want guardrails because security mattered and misuse was a real concern. The people who built that network had poured years of work into it, and they didn’t want it compromised by commercial interests that had no stake in what they’d built.

The NSFNET gatekeepers were asking the right questions at the wrong moment in time.

The moment had already shifted. Commerce was coming regardless of what they felt or they believed. Their efforts to control the internet were now futile. The only real choice was whether they had was to shape it or be shaped by it. To do nothing meant they would be shaped by it.

Faith-based organizations are in the same position right now. The governance questions are real and ethics matter. Data protection for vulnerable populations matters enormously. Faith-based organizations should take that more seriously than other organanizations. As I’ve said before, governance is not the same as paralysis. Writing an acceptable use policy is not the same as building solutions.

The organizations that figure out the 20x ministry model first (lean teams, intelligent workflows, and AI layered into every process that doesn’t require a human) are going to have a reach and an impact that look completely different from organizations still debating whether AI belongs in their work.

Fast Forward

Thirty-five years from now, someone is going to write an article like this one about the 2020s. They’ll shake their head at the organizationss that were still commissioning working groups on AI plausibility while others were already deploying it. They’ll wonder how that people in serious organizations spent serious time arguing about whether AI had any place in their work.

And they’ll ask the same question we now ask about pre-commercial internet:

How did you ever do ________ without AI?

That question is coming whether people want to hear it or not. The only real choice is whether you’re building the answer now or scrambling to catch up when everyone else already has.

The NSFNET gatekeepers eventually opened the gates and commerce flooded through because the demand was already there. It just needed permission.

How does this apply to us? We have more tools than any generation of mission workers in history. The Great Commission hasn’t changed but the capacity of the people carrying it is about to. Workers are being freed from the mundane and tedious administrative work to do the things they are called to do. They are being freed to do the human tasks while machines are doing the machine tasks.

How will you respond?

When the history of this moment gets written, which side of the story are you on?

Ten articles about the AI-Driven Organization! We made it.

There were not just ten articles. They were ten invitations to have conversations about what it actually takes to build an organization that doesn’t just use AI, but is genuinely transformed by it. Over ten articles, I’ve talked about strategy and operations, thought partners and task robots, decision architecture and organizational bias, multiplying people and protecting the irreplaceable human work. We’ve talked about culture and the fact that none of this happens without the right culture. Culture is the thing that makes all the rest of it possible.

This is the last article in this series. I want to end it the way every good series should end, not with a tidy summary, but with a honest picture of what success actually looks like and a challenge worth sitting with.

Before I get there, I want to say something I don’t say enough publicly.

I am grateful beyond words to work at the International Mission Board.

Not because it’s a perfect organization, no organization is. But because it’s led by people who genuinely believe that every tool available to us should be deployed in service of the Great Commission. People who don’t just talk about innovation, they model it. Leaders who help build the framework that makes innovation possible.

Over two years ago, our President, Dr. Paul Chitwood, enrolled our entire leadership team in an AI course. He and our Vice Presidents went through the entire MIT AI course. The senior leadership of a 4,000-person global missions organization went through a course on AI. They did the assignments, watched the videos, submitted their papers, and learned about AI’s coming impact on organizations. That’s how to lead an organization into the future.

In most organizations, AI training gets delegated. It gets sent down the chain. The assumption for many organizations is that senior leaders set the vision and others are the learners. Dr. Chitwood not only rejected that assumption, he modeled the posture that Article 9 of this series argues is essential. Leaders go first.

I think about his decision often. Because of it, when our team brings AI proposals to the organization, we’re not translating across a comprehension gap to leaders. We’re building on a shared foundation. When we talk about governance, risk, and opportunity with our leaders, they understand what we’re talking about. They’ve done their homework (literally).

Having great leadership is a gift and I don’t take it for granted. If you’re reading this and your senior leadership hasn’t taken the time to become learners, this series is my invitation to them. Share the ten articles with them, not as a critique, but as the first step on the path to becoming an AI-Driven Organization.

What does the AI-driven organization actually look like?

Allow me to give you the real answer. Not the aspirational version.

The AI-Driven Organization looks like an organization that has made a deliberate decision about posture, not about tools. A decision that AI is not a threat to manage, not a trend to monitor, and not a shortcut to exploit. AI is a resource to steward. One that, deployed with wisdom and intention, can multiply the capacity of every person in the organization to do the work they were called to do.

It looks like leaders who have done the learning themselves. Who can speak with credibility about what AI can and cannot do. Who model experimentation, acknowledge uncertainty, and create safety for their teams to try things and fail and try again.

It looks like a culture that has made the three shifts. 1) From control to empowerment, 2) From perfection to iteration, and 3) From stability to agility. This didn’t happen all at once. It certainly didn’t happen perfectly. These shifts occured both directionally and consistently. It’s a culture where the default is curiosity rather than caution. Where the question “should we?” has been replaced by “How might we?”

It looks like people who are more present in the irreplaceable human moments because the friction of the non-essential work has been cleared away. Field workers who have their time back. Leaders who can go deep because the mundane work is handled. Leaders who can think strategically because they’re no longer swallowed by operations.

It looks like decisions that get made well and on time because the information architecture supports clarity rather than confusion and the bias-surfacing is not only built into the process, it’s embraced. It’s an organization where the right people have the right authority to decide without everything traveling to the top.

It looks like small teams doing the work of large ones. This happens not because people are being squeezed harder, but because intelligence has been layered into the workflows, and the capacity that was always there has finally been released.

Here’s the part that probably will not sell any books.

The AI-driven organization is never finished. There is no version of this where you cross the finish line and declare transformation complete. The tools keep changing, the possibilities keep expanding, the cultural work keeps requiring attention, the biases keep needing to be surfaced, and the irreplaceable human work keeps needing to be protected. It' never stops.

The AI-Driven Organization is not a destination. It’s a direction.

The organizations that thrive in the years ahead won’t be the ones that figured out AI perfectly. They’ll be the ones that built the culture, the posture, and the leadership capacity to keep learning, keep adapting, and keep pointing everything, every tool, every process, and every efficiency gain back toward the mission.

Jesus sent twelve. Not twelve thousand. Not twelve hundred. Twelve ordinary people with no organizational infrastructure, no communications budget, no administrative support, and no technology beyond their own presence and the power of the Spirit.

They turned the world upside down.

We have more tools than any generation of mission workers in history. AI is the latest and most powerful of them. The question was never whether we’d have enough capacity. The question has always been whether we’d have the courage, the clarity, and the obedience to use what God has given us fully, without reservation, without the paralysis of over-caution, and without confusing our comfort with His calling.

The Great Commission hasn’t changed, but the capacity of the people carrying it is about to. Allow me to say something for the third time in this series.

Caution without action isn’t wisdom. It’s just slower failure.

I hope this series has been helpful. This isNow go build something.

This has been “The AI-Driven Organization” — a 10-part series loosely based on Geoff Woods’ The AI-Driven Leader. I have applied his principles not to individual leaders, but to faith-based organizations. If this series has been useful to you, share it with a leader who needs it. And if you want to continue the conversation, find me at www.donbarger.com.

You can buy tools, mandate training, build the workflows, set the permissions, and roll out the policy documents, yet still fail to become an AI-Driven Organization.

Not because the tools are bad. Not because your people are resistant. But because you treated culture like a checkbox. As if it’s something to handle after the implementation is done.

Here’s the thing about culture. It isn’t downstream of strategy. It doesn’t follow the plan. Culture is the plan and if you don’t build it intentionally, AI adoption will expose every crack in the foundation you didn’t know was there.

The Tool Trap

Most organizations focus on the wrong thing when they roll out AI. They spend a lot of time debating which tools to use, negotiating licenses, and governing the differrent tools. All of that is necessary, but none of this will change the culture..

I’ve watched organizations spend significant time and resources getting people to use AI and then discover, six months in, that usage is shallow. People are using AI to do what they already were already doing, just marginally faster. Fundamentally, nobody is working differently. Nobody is asking different questions. Nobody is thinking at a different altitude.

The tool didn’t fail. The culture did.

When AI adoption happens in a culture of scarcity — where sharing information feels like giving away power, where failure gets penalized instead of processed, where “that’s not how we do it here” is the invisible fence around every new idea — AI just accelerates the existing patterns. It doesn’t transform them.

Culture shapes how the tools get used and culture is shaped by leadership, long before any tool gets deployed.

What AI Culture Actually Looks Like

An AI-ready culture isn’t a culture that loves technology. Technology-loving cultures can be just as slow to change as technology-skeptical ones. They’re just slower for different reasons.

An AI-ready culture is one where:

• Experimentation is expected, not exceptional. People try things. They share what worked. They share what didn’t. Failure isn’t a verdict, it’s learning.

• Learning is structural, not aspirational. There’s actually time and space for it. Not just a Slack or Teams channel nobody reads, but regular moments where teams reflect on what they’re discovering.

• Information moves. Insights don’t stay siloed in the person who found them. Knowledge flows across teams. What one person learns, others can access.

• Questions are celebrated. The person who asks “why are we doing it this way?” isn’t a problem. They’re an asset.

• Status doesn’t protect bad processes. Seniority doesn’t exempt anyone from scrutiny. If the workflow is broken, it’s broken regardless of who designed it.

None of these are AI-specific. They’re just healthy principles for organizational culture, but specfiically, they’re the soil in which AI actually grows.

In an organizational culture without these qualities, AI becomes one more tool people learn to work around rather than with.

The Leader’s Role

It often gets missed, but culture doesn’t change through communication or policy. Culture changes through shared behavior.

You can send the memo, add the AI vision to the strategic plan, and can call out things like “embrace innovation” in the core values document, but none of this really matters if the leaders do not embrace it.

Organizationally, nothing matters as much as what leaders do in the moments when culture is actually being formed. The meeting where someone suggests a new approach and the leader’s first response is, “We tried something like that five years ago and it didn’t work.” The debrief where a failed experiment gets treated as a performance problem rather than a learning opportunity. Unfortunately, the innovation or experimentation budget is often the first thing cut when resources get tight.

Those moments shape culture more than any town hall, memorandum, or policies. Leaders who want to build AI-ready cultures must to lead differently. Not just talk differently. Lead differently. That means:

• Model curiosity over certainty. If you are a leader, try to be seen exploring, not just directing. Saying “I don’t know yet, I’m still figuring this out” in public.

• Protecting experiments. Create genuine space for teams to try things that might not work. Don’t penalizing these ideas when something doesn’t. Ask questions like, “What did we learn from this?”

• Ask better questions. Don’t ask things like, “Why isn’t adoption higher?” Instead ask, “What’s making it hard to try new things here?” One of the best question you can ask is, “How might we ________?”

• Narrate your own AI use. If you’re using AI to think, to draft, to stress-test your decisions, let people know that. Say it often and in spaces where others can year it. Visibible embracing and using AI from leadership normalizes the behavior in other teams.

The organizations I see getting AI right have leaders who are doing the work themselves. They are not just supporting from a distance. They are using the very tools they are advocating for. They are not delegating adoption to others while remaining personally untouched by it.

Culture that Quietly Kill AI Adoption

Organizatinos have landmines they don’t always know about.

The Perfectionism Trap
In cultures where everything must be completely polished and a bow on it before it gets shared, AI can’t do its best work. If you expect AI to give perfect solutions on every first attempt, you will be disappointed. AI is iterative by nature. It gets better with fast feedback. If the culture punishes showing early drafts or rough thinking, people will only bring AI output when it’s already been sanitized. This defeats the point.

The Expertise Idol
In some organizations, expertise is identity. The person who knows the most holds the most authority. AI threatens this dynamic because it distributes access to information and analysis more broadly. In cultures organized around expertise as status, AI not only doesn’t get adopted, it gets resisted. Not loudly, but quietly by the people who have the most to lose. AI is the great democratizer of information and solutions.

The Efficiency Illusion
Some cultures reward looking busy over doing important work. AI can free up significant capacity, but if that freed-up capacity doesn’t get redirected toward higher-value activity, if it just gets filled with more meetings and more reports. The organization never captures the real benefit and culture determines what people do with margin when they get it. Read The AI Dividend for more on this.

Connecting It Back to the Mission

I want to be clear about why this matters, because it’s easy to let the idea of an AI-Driven Organization to stay in the abstract. You need to move from abstract ideas to concrete organizational action.

We are in a moment of unprecedented access to tools that could dramatically expand the reach and effectiveness of gospel work among unreached peoples. AI can accelerate research. It can multiply the capacity of field workers. It can reduce the administrative burden that pulls people away from relational ministry. It can help small teams punch far above their weight class.

All of these possibilities can only happen if the culture is ready for it. Maybe it’s better said, if the organizational culture intentionally embraces AI.

If we build the AI tool stack without building the culture, we will squander one of the most significant organizational opportunities the global missions movement has ever had. Not because we were opposed to it, because we didn’t do the slower, harder work of asking what kind of organization we actually need to be.

The tools are not the hard part, it’s the culture is the hard part.

A Few Places to Start

If you’re leading a team or an organization navigating AI and have a desire to truly become an AI-Driven Organization, here’s some suggestions of where to put your energy:

• Audit your failure culture. When something doesn’t work, what actually happens? Be honest. Not what’s supposed to happen. What actually happens.

• Create visible experiments. Pick something where the stakes are low. Try an AI solution, share the process openly (messy parts included), and make experimentation visible and normal.

• Reward questions more than answers. Specifically, and publicly. The person who asks, “How might we?” is often more valuable than the person who confidently executes the same old thing without asking questions.

• Identify the quiet resisters. Every AI adoption has them. These are the people whose identity, authority, or comfort is threatened by change. Don’t steamroll them, engage them. Sometimes the loudest critic becomes the most powerful champion once they’re genuinely included and reassured.

• Connect every AI initiative back to the mission. Not efficiency, but truly the mission of your organization. The question isn’t, “How does this save time or money?” It’s actually, “How does this advance our stated mission and purpose?” When the mission is the frame, the culture conversation gets traction. You measure success of your AI-Driven Organization by how it impacts your mission.

Remember, the AI tool stack is the easy part. You can buy it, configure it, deploy it, and even change it in a matter of weeks.

Establishing your organization culture takes years. Building an AI-Driven Organization only occurs if it builds upon the overall organizational culture. If your organization is risk averse and change averse, don’t expect AI to flourish quickly.

Organizations that build the tools and the culture, will find themselves operating at a level of mission effectiveness that wasn’t possible before.

That’s what all of this has been about. AI-Driven Organizations are not just looking at efficiency. They are focused upon effectiveness. Specifically, they are focusing upon effectiveness that advances the bottom line of the purpose of the organization. They measure this impact.

The question isn’t whether you’ll adopt AI. The question is whether you’ll build the kind of organization that can actually use it well.

As the boom of AI has occured over past three years, there’s an unasked question is not being asked outloud, but it’s at the crux of a lot of questions I’m being asked. That question?

What happens to us?

Not “what happens to our jobs,” though that’s part of it. This question is something deeper. What happens to the things that make our work meaningful? The relationships, our presence, the moments of genuine human connection that no workflow can produce and no algorithm can replicate. What happens to those when the organization goes all-in on AI?

It’s a fair question. Today, I’m going to attempt to answer the unasked question. Let me start with what I believe is true, and what the evidence increasingly supports.

AI is genuinely remarkable at a growing list of things.

• Pattern recognition.

• Data synthesis.

• Language generation.

• Scenario modeling.

• Research acceleration.

• Translation.

• Content adaptation.

• Scheduling.

• Summarization.

• First drafts of almost everything.

The list is long and getting longer every month.

But there is a category of work, not a task or a function, but a category, that AI cannot enter. Not because the technology isn’t sophisticated enough yet. Because the work itself is constituted by human presence in a way that technology cannot replicate by definition. Things in this category include things like”

• Sitting with someone in grief. Not solving it. Sitting with it.

• Building trust across cultural distance over years of shared life. Not summarizing cultural research. Living it.

• Discerning together, in community, what God is calling an organization toward. Not generating options. Listening.

• Mentoring a young leader through failure toward growth. Not providing feedback. Being present through the process.

These aren’t tasks with human inputs. They are irreducibly, essentially human. The moment you remove the human; you haven’t done them faster or cheaper. You haven’t done them at all.

This matters especially for how faith-based organizations think about AI adoption.

The Efficiency Trap

The risk isn’t that AI will replace missionaries, pastors, counselors, or community builders. The risk is subtler and actually more dangerous. It’s that in the pursuit of efficiency, organizations will slowly erode the conditions that make irreplaceable human work possible. Allow me explain.

Here’s what that erosion looks like in practice.

A worker gets so efficient at producing reports, translating content, and managing administrative workflows with AI that their outputs multiply dramatically. Leadership sees the numbers and adds more responsibility, deliverables, and expectations. The efficiency gains get converted immediately into more output. The time that was supposed to flow back into relationships, presence, and discernment gets consumed before it ever arrives.

AI made it possible to do even more, so instead of having more margin for the human things, we do exponentially more as we multiplied the work. The organization consumed the margin. The irreplaceable things, the ones that actually move the mission, got squeezed out anyway.

This is the leadership challenge that AI makes urgent but didn’t create.

Organizations have always struggled to protect the irreplaceable work from the demands of the operational work. AI just changes the scale of the pressure. When one person can produce what used to require five, the temptation to extract that productivity rather than redirect it is enormous.

The AI-driven organization has to make a deliberate, protected, countercultural decision: the efficiency gains belong to the mission, not to the output metrics.

That means when a worker gets ten hours a month back from AI-assisted reporting, those hours must go back into the relational work, not into more hours of reporting. It’s to ask, “What’s the right volume for genuinely human engagement, and how do we use the freed capacity to deepen that?”

This requires organizational discipline that runs counter to most institutional instincts. Most institutions optimize for output, especially operational output. The AI-driven mission organization optimizes for impact. Those are not the same thing.

How Does an Organization Protect Needle Movers?

It starts by naming it explicitly. Many organizations have never had a serious conversation about what work is irreducibly human and what work is not. They treat everything with equal weight, or worse, they incentivize the operational. What gets inspected? The number of gospel conversations someone had or getting reports completed on time?

The AI-driven organization draws a clear line. On one side is the work that AI can do, assist with, or dramatically accelerate. On the other side is work that requires human presence, wisdom, relationship, and soul care. And it protects the second category with the same intentionality it applies to the budget.

Here’s what this looks like:

Protecting time before it gets filled.
When efficiency creates margin, leadership has to act before the organization’s natural tendency to fill margin with more output kicks in. Schedule the relational work. Block the discernment time. Make the irreplaceable things calendar commitments, not aspirational remainders.

Measuring what matters.
Most organizational metrics track output. Timely reports filed, content produced, personnel engaged, and trainings completed. These are easy to count, yet largely irrelevant to mission impact. These do not really move the needle.

The AI-driven organization also tracks, as best they can, the things that actually move the mission: relationships deepened, communities engaged, gospel conversations, and leaders developed. It’s sometimes hard to measure some of these, but these are the things that move the needle. The actually matter the most.

Keeping humans in the human moments.
While this sounds obvious, it isn’t. Organizational pressure to scale will consistently push toward replacing human moments with digital proxies. Can you use an automated follow-up instead of a phone call, a content piece instead of a conversation, an AI-generated update instead of a personal one. The AI-driven organization draws firm lines about which moments stay human, and holds them.

Here’s the theological frame I keep coming back to.

Souls care for souls. That was true before AI. It will be true after whatever comes next.

The technology changes, but the human need for genuine presence, genuine witness, and genuine love does not. The Great Commission was given to people, not platforms. It will be carried out by people who are present, available, and fully human in the moments that matter most.

Practical Challenge

Today’s challenge requires no computer, although you are welcome to use AI to help you ideate. Work on creating a list of distinctively human activities that you want to preserve as you begin to see the benfits of scaling AI.

• How do you plan on creating greater impact on the things that actually move the needle?

• How will you measure the impact?

If you do not build this in from the beginning, I predict that you will become much more efficient… at becoming more efficient. The purpose of efficiency is to have impact on the distinctly human things.

AI is a gift that can free those people to be more fully present in those moments. Or it can become a trap that extracts their capacity for the mission’s machinery.

The difference is entirely a matter of organizational decision. That decision belongs to leaders.

Article 8 of 10 in “The AI-Driven Organization” series. Next up: Building the Culture, Not Just the Tool Stack — why 90% of AI transformations fail, and what the ones that succeed have in common.