It was a hallway question. Three different teams. Three different conversations. Same words.

“Where do we even start with this?”

The honest answer is not the answer most teams want. It is not the agent or the chatbot. It is not the donor churn score that lit up the room Wednesday afternoon.

It is voice.

Why voice first

Every nonprofit team already writes. Newsletters. Fundraising appeals. Board memos. Social posts. Stewardship emails. Welcome sequences. Thank-you notes. That output doubles or triples the moment AI shows up, because writing is the lowest-friction use case for any LLM.

It is also the place where AI breaks the brand the fastest.

The pattern is the same in every org. Junior staff types “write a fundraising appeal for our spring campaign” into a chatbot. Gets back something that sounds like every other appeal in the donor’s inbox. Director rewrites it from scratch. Time saved equals zero. Brand consistency equals worse.

That happens because the AI has no idea how your org sounds. It defaults to the average voice of every nonprofit in its training data. Generic warmth. Pre-built urgency. The same three rhetorical moves every fundraising consultant has used since 2008.

The fix is not better prompting. The fix is teaching the model how YOU write before you ask it to write anything.

What voice capture actually is

A brand voice document is not a personality quiz. It is not “we are warm, professional, and inspiring.” That language does nothing for an LLM and even less for your staff.

A real voice document is a structured artifact. Rhythm patterns. Specific vocabulary. Sentence constructions you reach for and ones you avoid. Audience-specific tone shifts. Annotated examples that show what good and bad output look like.

It is the difference between telling someone “be funny” and showing them a comedian’s set. The set teaches. The instruction does not.

How to capture it with Claude

The process takes about an hour and produces an asset every writer in your org uses for the next two years.

Start with eight to twelve pieces of writing that represent your org at its best. Mix formats. A fundraising appeal that worked. A board email that landed. A social post that drove response. Two newsletters. A welcome email. The pieces you would point to if a new hire asked “how do we sound?”

Paste them into Claude as a corpus. Then ask:

“Read these as one writer’s voice. Identify the rhythm, sentence construction patterns, vocabulary preferences, emotional beats, and what this writer avoids. Be specific. Quote concrete examples from the text.”

What comes back the first time will be too generic. Push back. “Show me three sentence patterns this writer uses repeatedly. Quote them.” “What does this writer never do that other nonprofits do?” “What is the rhythm of the opening lines?”

Iterate until the analysis sounds like your editor wrote it. Then ask Claude to produce a Voice Card. A reusable document with the patterns, the vocabulary, the do/don’t rules, and three or four annotated examples.

Test it. Open a new chat. Paste the Voice Card. Ask Claude to write a fresh fundraising appeal in your voice. Compare it to the originals. If it sounds off, revise the card and run it again.

Two or three iterations and you have a document that travels.

Where the leverage shows up

Every writer in the org loads the Voice Card before they draft. New newsletter. Paste the card. Draft. Edit. New social post. Same. New stewardship email. Same.

The output changes immediately. Junior staff produces director-quality drafts because the voice is no longer in the director’s head. It is in a document the AI uses on every task.

The downstream effects compound. New hires onboard faster because they have something to read. Volunteer writers produce on-brand copy without three rounds of edits. Consultants and freelancers work from the same voice the in-house team uses. Email response rates lift because the writing stops sounding like a stock fundraising template.

This is the cheapest, lowest-risk AI investment a nonprofit can make. No connectors. No vendor contract. It requires an afternoon and the discipline to be specific about how your org sounds.

Voice Card or Skill?

The Voice Card I described is a document. You paste it before drafting. That works for individual users and small teams, and it works in any LLM.

It also has a failure mode. People forget. Junior staff drafts an appeal without loading the card. The director gets a generic draft. The system breaks because it depends on a manual step every time.

For nonprofits running on Claude Team or Enterprise, the upgrade is a Skill.

A Skill is a folder of instructions Claude loads automatically when it detects a relevant task. Brand voice is on Anthropic’s official example list for what Skills are built to do. The Voice Card content goes inside a SKILL.md file. The org owner provisions it centrally. Every user in the org gets it. Every drafting task triggers it without anyone remembering to paste anything.

When the voice rules change, you update the Skill once. The change propagates to every user the next time they draft.

That is the difference between a document a team is supposed to use and a capability a team is using whether they know it or not. The first depends on discipline. The second is the discipline.

The maturity model is simple. Build the Voice Card first. Use it as a pasted document for a few weeks while you refine it. When the voice is locked in, wrap it in a Skill and provision it across the org. Same content. Different deployment.

Most nonprofits should not start at the Skill. Start with the document. Earn the voice. Then promote it.

Where this connects to Tuesday’s argument

The thesis Tuesday was that AI strengthens fundraising when it extends the systems your team already trusts, and fragments fundraising when it adds disconnected tools to the side.

Voice capture is the same idea applied to writing. Every team already writes. Voice capture extends that work. It teaches the AI you already have access to how to sound like the team you already have.

Once the voice is captured, the door opens to the next layer. Whether it lives as a Voice Card or a Skill, the same content travels into your CRM workflow so stewardship drafts come out in voice. It loads into your email platform so subject lines match the rest of the brand. The AI agent drafting your year-end appeal works from the same source the staff does.

Start there. The agents come later. The brand voice document is the foundation everything else compounds on.

What to do this week

Pull three pieces of writing you are proud of. Not the most polished. The sharpest. The ones that sound most like you.

Open Claude. Paste them. Use this prompt:

“These three pieces represent how our organization writes at its best. Read them as a corpus. Identify the rhythm, vocabulary, sentence patterns, and emotional beats this writer reaches for. Be specific. Quote examples.”

That conversation, followed by two more iterations, produces the first draft of a Voice Card.

The agents and the predictive tools and the connectors are real and they will matter. They will matter more once the foundation is set. The foundation is voice.

Same person. Three teams. No shared view.

That pattern is in every operator team I work with. The data is sitting in three systems. The teams are running on partial views of the same person. The default response right now is to bolt another AI tool onto the stack.

I am at NAYDO this week, on a panel with two YMCA executives. The room is full of leaders wrestling with that exact question. Most of them are about to make it worse.

It is not a data problem

That is a connection problem.

Most operator teams already have the data they need. The fix is not another data warehouse. The fix is a unified operating model. One profile per member that holds participation, engagement, and giving in the same place. One source of truth your staff trusts. One ranked list when development asks who to call first this week.

AI sitting on top of that profile. Not bolted to the side of it.

The real risk of bolting AI on

Here is the truth about AI right now. It is both Einstein and Forrest Gump. Brilliant one minute. Missing the obvious the next.

Now stack six different AI vendors against your member data. Each one running its own version of that. No oversight. No shared view. An AI sales agent here. An AI scheduler there. An AI chatbot somewhere else.

Six months later you have six logins, six contracts, six places your member data lives, and no view of the member.

That is fragmentation dressed up as innovation.

Multiply that pattern by twelve and you get the AI stack most mid-size operator teams are running today. Twelve disconnected tools, each producing useful output, none of them feeding the systems the org already trusts. The reconciliation tax has gotten worse, not better. The board deck still tells the same story it told before AI showed up.

The problem is not the tools. The tools work. The problem is the org now has a dozen new sources of truth instead of three, and nobody has a path back to the systems that show up when leadership asks how the year is going.

The chain that holds the strategy together

Five words run through every answer I am bringing to the panel.

Participation. Insight. Engagement. Giving. Impact.

Participation tells you who is engaged. Engagement tells you who is ready. Giving tells you what to ask for. Impact gives the donor a reason to stay.

Break that chain anywhere and growth stalls.

AI strengthens fundraising when it reinforces the chain. AI fragments fundraising when it adds another disconnected tool to the side. The strategic question is not which AI to buy. The strategic question is which decisions in your operation get better when the chain is connected.

That is the operating discipline. AI should make your systems smarter, not multiply your systems. Embed it where the work already happens. Open it to partners through a controlled doorway. Stop adding logins.

The leaders who get this right are not the ones moving fastest. They are the ones who picked one trusted platform, said no to the rest, and let the platform do the work.

Where this lands in real fundraising

The biggest lift comes from one thing. Knowing who to call first.

Most development teams have more relationships than capacity. A team of four is trying to steward thousands of donors and tens of thousands of members. Every call is a bet. Every email is a guess.

The lift comes when AI looks at every signal you already have. Attendance. Program history. Giving history. Communication response. Then tells your team who is ready, who is at risk, and who is primed for a bigger ask.

That only works if the data is connected. A churn score on a member profile is interesting. A churn score on a donor profile is action.

When development sees that a $5,000 annual donor stopped checking in three weeks ago, that is a save call. Not a stewardship email next quarter.

When the team trusts the list, they work the list. Confidence shows up in the pipeline. That is the difference between a fundraising program that compounds and one that runs on heroics.

What to do Monday morning

Pick one decision your team makes every week that would be better with connected data. One.

Most operator teams try to fix everything at once and stall. The teams that move start with one decision. Who do we call this week to prevent churn. Who do we ask for an upgrade in this campaign. Which lapsed members are most likely to come back.

Pick the decision. Write down what data would change the answer. Then look at where that data lives today and what it would take to get it into one view.

That exercise tells you more about your AI readiness than any strategy doc. If the answer is the data is in three systems and we run it through a spreadsheet once a quarter, you know where to start.

If you are at NAYDO and want to talk about this in person, find me after the panel Wednesday afternoon.

The tools are not the strategy. The tools are an input to the strategy. The strategy is whether you extend the systems you already trust or build a parallel stack of disconnected ones.

Extend first. The decision to bolt on a new tool only makes sense when extension is impossible and the new tool is worth the reconciliation cost. Most of the time, it is not.

The site is five years old. The donate button is buried two clicks deep. The copy was written by the founder during a weekend that nobody wants to repeat. The board has been arguing about a redesign for the last 18 months. Nothing has shipped because every option requires a budget that does not exist or a partner that does.

I rebuilt one over the last two weeks using four AI tools, one per phase, with no developer hours and no agency. The organization is a small non-profit in Texas serving women in need. Real cause, real budget constraints, real stakes for the people the org serves.

This post shows you what I ran in each phase, the prompts that worked, the mistakes that cost me time, the rounds of revision that produced the final build, and what is required to ship a stack like this without putting the org at risk.

If you run a small non-profit, or you serve one, this is the playbook.

The constraints

Three rules going in.

1. No paid contractors. Every dollar that does not go into program work is a dollar that does not serve the people the org exists to serve.

2. No staff time pulled from program operations. The executive director cannot disappear into a website project for two weeks.

3. The donate path has to be easier after launch than it was before. That is the only metric that matters.

Those constraints force a stack that runs on AI tools plus a single experienced reviewer. Two weeks part-time, end to end.

Phase 1: Perplexity for cause and funder research

A non-profit website needs three things from research that a small business does not. Current cause data the donor will trust. A funder landscape the development director can work from. A clear-eyed view of comparable orgs to inform positioning. Perplexity is built for all three.

What I ran:

1. Cause-data queries pinned to the current year. Older stats lose donor trust the moment a donor Googles them and finds a fresher number. Run every cause query as “[topic] data 2025” or “most recent reported [topic]” rather than asking for general statistics.

2. Funder landscape queries. “Foundations funding [cause area] programs [state] 2025.” “Corporate giving programs [related employment or service category] 2025.” This populates a future “Partner with us” page and gives the development director a working list.

3. Comparable-organization queries. “Non-profits serving [population] with [program type] United States.” Not to copy them. To see what donor pages look like in the category, what proof points donors expect, and where this org’s program is meaningfully different.

Mistake to skip:

Do not run cause-data queries without the year. Perplexity will return a 2018 stat with full confidence. Always pin the year. If the org cites older data on the current site, that is a flag to update on the rebuild, not a baseline to preserve.

The handoff:

A markdown document with three sections: current cause data with sources, funder landscape with three to five named foundations and their giving criteria, and a positioning brief on how this org’s program differs from comparable orgs. The third section is what drives every copy decision in Phase 2.

Phase 2: Claude chat for content architecture and voice

Non-profits have a specific voice problem. They either over-soften (”we believe every person deserves a fresh start”) or they over-stat (”908% increase since 1980”). Neither one converts donors. The voice that converts is the one that uses real data to make a real argument and then puts a human face on it.

That voice does not get written by a generalist. It gets extracted from what the org already says about itself and tightened into something usable.

What I ran:

A single chat session with three inputs loaded up front: every page of the existing website, the org’s published values document, and the Phase 1 research. Then two prompts.

Prompt one: “Analyze the writing voice across these materials. Return a voice profile with: sentence length patterns, tone, vocabulary the org uses repeatedly, vocabulary they avoid, the proof points they lean on most often, and five example sentences that capture how they sound at their best. Pay specific attention to how they describe the people in their program, because that is the voice that has to carry the donate page.”

The voice profile caught something a generic rewrite would have missed. The org never described their program participants by their need status. They used terms that emphasized identity and progression rather than circumstance. That was a deliberate choice. It carried through every page of the rebuild.

Prompt two: “Using the voice profile and the positioning brief, draft a sitemap optimized for three conversion actions in priority order: donate, hire an alumni, volunteer. For each page, include the argument the page makes, the sections on the page, and a one-sentence hook for each section.”

The sitemap collapsed the existing site from twelve pages to seven. Three of the original pages were sub-pages that did not need to exist. One of them, a founder Q&A, became a section on the About page. Less site, more conversion.

Mistake to skip:

Do not let Claude write donate-page copy without giving it a hard structural rule. Donate pages drift toward generic appeal language fast. Pin it: “every paragraph on the donate page must include either a specific dollar amount tied to a specific outcome, a specific named program element, or a specific data point from the research document.” That rule alone produces donate copy that converts.

The handoff:

A page-by-page content document with draft copy in the org’s voice, a hierarchy of conversion priorities for each page, and a list of proof points each page can pull from. The development director and executive director can finalize this in two hours instead of two weeks.

Phase 3: Claude Design for mockups

Claude Design launched April 17. Going in, my biggest concern was that it would produce something that looked like every other modern non-profit website. Hero photo of a participant. Gradient overlay. Donate button in the upper right. Three-column “How We Help” section. Generic in the way that costs donors.

The skeptical take did not survive first contact.

What I ran:

Onboarding first. Uploaded the org’s existing brand system: logo files, color palette, typography, any component patterns already in use. The brand system was thin, which is normal for small non-profits. Claude Design extended it with a complementary palette and type scale that matched the existing identity rather than overriding it. This matters. Non-profit boards do not approve “the website looks completely different now.”

Then one prompt per page. The two-variant rule is not optional for non-profit work. It is the whole point.

For the homepage: “Design two variants. Version A leads with the cause data and the program proof point. Version B leads with an alumni story and an emotional hook. Both apply the brand system. Both place the donate, hire, and volunteer CTAs above the fold.”

The board chose between two arguments side by side instead of arguing over button colors.

Mistake to skip:

Do not let Claude Design pull stock photography for non-profit work. The output will look like every other charity website. Either upload the org’s actual photography or use illustration. Real photography from real program events is the most powerful asset most non-profits already own. Use what is real before reaching for what is generic.

The handoff:

This is where the stack gets real. Claude Design has a built-in handoff bundle. It packages the selected design, the component library, the design system tokens, and the design intent into a single artifact that goes straight to Claude Code or Cowork. You are not screenshotting a mockup and describing it in a prompt. You are passing structured design data to the next agent.

Tool quality matters. Handoff quality matters more.

Phase 4: Claude Cowork for development and production

Cowork built the site. WordPress theme, custom blocks, every page, every component.

It also took multiple rounds of revision before the build was right.

This is the part most AI workflow posts skip. The first pass from Cowork is not the final pass. Anyone telling you a site comes out of an AI tool ready to ship is selling something. What came out of Cowork on the first run was a working scaffold with real problems: spacing inconsistencies between page sections, accessibility issues on form labels, conditional logic on the donate form that fired in the wrong order, a header component that looked correct on desktop and broke at the mobile breakpoint.

What I ran:

Opened Cowork, pulled in the Claude Design handoff bundle, started with the smallest build target: the donate button component. Got it working. Reviewed. Found three issues. Sent it back. Reviewed again. Approved. Moved to the next component.

Every component went through that loop. Some took one revision. Some took four. The donate page took the most because the stakes were highest and the bar was strictest.

The order of operations for a non-profit site is different from a small business site. The conversion elements come first.

1. Donate button and donate page (the highest-revenue element).

2. Global styles and brand system translation to CSS variables.

3. Header and footer with persistent CTAs.

4. Homepage, top to bottom.

5. Program page, About page, Get Involved page.

6. Hire Alumni page and any other secondary conversion paths.

Mistake to skip:

Do not approve component output on the first pass. The instinct is to accept what looks correct in the preview because the preview is convincing. Open the actual code. Check the form field IDs. Check the accessibility attributes. Check the conditional logic on every interactive element. The first pass is a starting point. Revision rounds are how the build gets to production-ready.

The handoff:

Export the theme files, commit to a private repository, push to Local by Flywheel as the staging environment.

Phase 5: Local by Flywheel to WP Engine

The migration is the part I expected to break. Every operator I know has a story about a migration that ate 40 hours. Image paths pointed at the old server. SSL that died on first load. Forms that worked on staging and failed in production.

For a non-profit, the donate form is the only form that matters. If it breaks at launch, the redesign cost the org real money.

What I ran:

Local by Flywheel for the staging environment. Set up the site there, loaded the theme files from Cowork, populated content, tested every page on localhost. Tested the donate form against the org’s actual payment processor in test mode. Installed All-in-One WP Migrate on staging. Exported the full site to a single file. On the WP Engine side, spun up a fresh install, installed All-in-One WP Migrate, imported the file. DNS cut over. SSL renewed automatically through WP Engine’s provisioning.

Clean push. First try. Donate form processed a test transaction within five minutes of the SSL handshake.

Mistake to skip:

Do not migrate the donate form integration last. Migrate it first, on day one of staging, and run a real test transaction in test mode. If anything breaks during the WP Engine push, you want it to break on the form you have already tested rather than the form you are about to test live.

The handoff:

None. The site is live. The donate button works.

What the stack requires

The process is simple. The blast radius is huge.

A non-profit website is not a brochure. It collects PII through donate forms, volunteer signups, and contact requests. It runs analytics tracking that has to comply with the org’s data policies. It processes payment information through integrations that fail silently when configured wrong. A misconfigured form does not throw an error. It accepts donations and loses them. A misconfigured tracking script does not warn you. It quietly violates your privacy policy. A misconfigured payment integration does not crash. It accepts a card and never sends a receipt.

None of those failure modes are AI failures. They are configuration failures that AI tools will produce on the first pass and confidently tell you are working.

This is the part that determines whether the stack is safe to run.

You do not need a six-figure agency engagement to rebuild a small non-profit website. You do need someone with six figures of experience and problem solving sitting in the reviewer seat. Someone who has shipped enough sites to know where the failures hide. Someone who reads the actual code and the actual form configuration rather than trusting the preview. Someone who tests the donate form against the real payment processor before launch and again after launch.

The four-tool stack lowers the cost. It does not lower the bar.

If you have an experienced operator who can sit in that reviewer seat for two weeks part-time, the stack works. If you do not, the stack is dangerous, and the right answer is still to engage a partner who builds non-profit websites for a living. There are good ones. They earn their fees.

For the orgs that do have an experienced operator available, this is the path that gets a site shipped. Pick the phase where the org loses the most credibility right now. That is the phase to replace first. Build the handoff to the next phase before you build the next phase itself.

One handoff at a time. With a reviewer who knows what to look for.

That is the wrong audience for the most important part of this release.

If you are running a 1-2 person operation, a small agency, or a marketing team without a DevOps function, Managed Agents changes something specific for you. Not the infrastructure question — you were never going to build your own agent runtime anyway. It changes the design question.

What Managed Agents actually removes

Before this release, shipping a production-grade AI agent meant solving two problems at once: what should the agent do, and how do you build the environment where it can do it reliably.

The second problem is significant. Sandboxed execution so the agent cannot break production systems. Session persistence so a multi-hour task does not restart from zero when the connection drops. Credential management. State management. Error recovery. The scaffolding required before you could ship anything users actually touched could take months.

Managed Agents handles all of that. You define the agent — the task, the tools, the guardrails — and Anthropic runs the environment. The $0.08 per session-hour pricing means a 4-6 hour agent session costs roughly $1.50 to $3.50 in infrastructure costs, plus token usage.

For developers, this is an infrastructure decision. For operators, it is something more useful: it makes the design question the only question.

The question that is left

When the infrastructure is handled, what remains is organizational design.

What task does this agent own? What decisions is it authorized to make without a human checkpoint? What triggers an escalation? What does the output look like, and who receives it?

These are not engineering questions. They are the same questions you ask when you hire someone and give them a defined scope. The agent is not a tool you configure once — it is a role you are designing. And the quality of that design determines whether the agent produces consistent, useful output or generates confident noise that someone has to clean up.

This is where most operator implementations fail, and it is independent of how capable the underlying model is. An agent with a vague brief produces vague results. An agent told to “handle all inbound communications” will eventually make a decision you did not intend. The scope definition is the work.

Managed Agents does not change this. It removes the reason to delay doing it.

What the 1-2 person team should actually do with this

Multi-agent coordination — the feature that lets agents spin up and direct other agents on complex tasks — is still in research preview. It requires a separate access request. For most small operators, that is the right feature to wait on.

What is available now and immediately useful:

Single-task runners with session persistence. An agent that runs a multi-hour competitive research pass, maintains context through the full session, and delivers a structured brief. You define the task, the tools it can use, and the format you want back. You review the output. The agent handles the hours of execution between your inputs.

Defined-scope communication agents. An agent that handles a specific category of inbound — not all inbound, a specific category — with defined response logic and a human review gate before anything sends. The scope is narrow. The output is reviewable. The human stays in the loop on the decisions that matter.

Workflow agents that connect to real systems. Managed Agents supports MCP server connections out of the box. That means an agent with access to your CRM, your calendar, your project management tool. Not a demo — a production workflow where the agent reads real data, takes defined actions, and logs what it did.

The constraint that produces good outcomes here is the same constraint that produces good outcomes in human team design: tight scope, clear success criteria, defined escalation path. An agent that knows exactly what it is responsible for, what it is authorized to do, and what to flag for a human is an agent that produces reliable output.

The human layer does not change

Managed Agents handles the runtime. It does not handle judgment.

The decisions that require context beyond the defined task — the client situation that needs relationship awareness, the communication that needs tone calibration, the output that is technically correct but strategically wrong — those stay with the human. They always do.

What changes is where you spend your time. The hours of setup, execution, and scaffolding that preceded your actual judgment calls compress. The agent handles the span between your inputs. You make the calls that matter.

That is the Managed Agents release for operators: not a new capability to evaluate, but a reduction in the barrier between now and running a real agent workflow. The infrastructure problem is gone. The design work is what is left.

Do that work first. Write down what the agent owns, what it does not own, and what it flags. Get that right before you write a single line of configuration. The spec is the hard part. The setup, now, is the easy part.

Read that again.

Nine out of ten teams bought the tools, ran the pilots, shipped something. And then watched the results flatline.

The instinct is to blame the AI. The model was not good enough. The platform was not ready. The timing was off.

That is the wrong diagnosis.

The teams getting results are not using better AI. They are using AI differently. Salesforce tracked it in their State of Marketing 2026 report: high-performing teams using AI agents see 20% ROI increases and 19% cost reductions. The majority of teams are not in that tier. Same tools. Different outcomes. The gap is not the technology. It is the architecture.

Specifically: most teams deploy agents without defining what the agent owns and what the human owns. The agent runs. Nobody knows where its authority ends. Decisions that require judgment get made by a model that has no judgment. Results disappoint. The team concludes the AI was the problem.

The AI was not the problem.

What the high performers do differently

The Salesforce data points to one consistent pattern in teams that close the gap: they design systems, not just tools. They do not ask “what can AI do?” and then hand it tasks. They ask “what decisions should AI own, and what decisions must a human own?” and build the architecture around the answer.

That distinction sounds simple. It is not. Most teams skip it entirely because it requires thinking clearly about where human judgment matters in your workflow. That is uncomfortable work. It forces you to confront the processes you have never documented, the decisions that live in someone’s head, and the edge cases nobody has written down.

The teams that skip this step are the ones showing up in the McKinsey data.

Here is the framework I use.

Three decisions AI should own

Routing and triage. Which contacts go where. Which leads are high-intent versus low-intent. Which inquiries get an immediate response versus a follow-up sequence. These decisions are rule-based and high-volume. A human doing this work is wasting their judgment on a sorting problem.

First response. The initial reply to an inbound inquiry, the welcome message after a form fill, the confirmation after a booking. Speed matters here and consistency matters. A human cannot respond to 200 contacts in 47 seconds. An agent can. This is not replacing the human relationship. It is making sure the relationship starts before the person moves on.

Pattern detection. Flagging contacts who match a high-intent pattern, surfacing anomalies in campaign performance, identifying which sequences are underperforming against historical benchmarks. The agent reads the data continuously. The human reviews the flags. This is AI operating as infrastructure, not as decision-maker.

Three decisions humans must own

Strategy and intent. What the campaign is trying to accomplish. What the audience needs to hear. What the brand will and will not say. This is not a prompt engineering problem. An agent can execute a strategy. It cannot set one.

Relationship escalation. When a conversation moves from transaction to relationship, a human takes over. A pastor calling a first-time guest. A sales rep following up on a high-value proposal. A support agent handling an escalated complaint. The agent handles the volume. The human handles the moment.

Judgment calls on edge cases. Anything outside the defined parameters of the agent’s scope requires a human. Not because AI is incapable of producing an answer, but because accountability for the decision belongs with a person. The agent should flag these and stop, not improvise.

The handoff protocol

The architecture fails when the boundary between these two sets of decisions is unclear. Here is the protocol that makes it explicit.

Define the agent’s scope before you build it. Not “handle all inbound.” Handle all inbound from this source, tag by inquiry type, and route to this pipeline. Tight scope produces consistent output. Broad scope produces variance. Variance is where the ROI disappears.

Name the human checkpoint. Every agent workflow should have a defined point where a human reviews the queue. Once a day, once a week, whatever the volume requires. The checkpoint is not overhead. It is the quality gate. Remove it and you have turned a tool into a liability.

Write the escalation criteria. What does the agent do when it hits something outside its scope? It should flag, stop, and notify. Not guess. The escalation criteria are the document that keeps the agent in its lane. Write them before you deploy.

Audit the boundary quarterly. Agent scope should expand as confidence in the output builds. What starts as “flag for human review” becomes “auto-send after 24 hours with no objections” once you have the data to support it. But you earn that expansion. You do not assume it.

Where most teams break the model

IBM’s data on this is direct: only 25% of AI initiatives deliver expected ROI. Only 16% scale enterprise-wide. The failure mode is almost always the same. A team deploys agents at the output layer: email copy, social content, reports. They skip the orchestration layer. The agents produce faster. The humans are still making all the same decisions they were making before, now with more output to review.

This is the productivity paradox that Supermetrics surfaced in their 2026 survey: 70% of marketing teams prioritize optimizing spend, but only 17% use AI for the analysis that would tell them where to optimize. They are using AI to produce more of what they were already producing. They are not using it to change how decisions get made.

More output without better decisions is not ROI. It is overhead.

The fix is not a different AI tool. It is going back to the architecture question: what decisions should AI own, and what decisions must a human own? Answer that first. Build second.

The teams posting 20% ROI gains are not using AI that the other 88% do not have access to. They decided what the AI was responsible for and built a system around it.

That is the whole thing.

He is right. He is also describing something most people have not yet done the hard work to understand.

The 1-2 person company thesis gets treated as a staffing story. Fewer people, same output. Lean team, big leverage. Sam Altman has a betting pool with tech CEOs for when the first one-person billion-dollar company appears — he called it unimaginable without AI, and now inevitable.

That framing is not wrong. It is incomplete.

The real shift is not about how many people you have. It is about what those people are doing. And most operators who want to live inside this model have not done the work to answer that question clearly.

“Managing Intent” Is Not Passive

Rui’s framing — agents manage processes, humans manage intent — sounds like a lighter workload. It is not.

Managing intent is harder than managing tasks. When you manage tasks, the feedback loop is tight. Did the thing get done? Yes or no.

When you manage intent, you are responsible for something more abstract and more consequential: Does the agent understand what this work is actually for? Is the output moving in the right direction? Where is the system drifting, and why?

I run Full Stack Tactical and Digital Pastor as a two-person operation. The agent layer handles competitive research, content drafts, QA passes, header image generation, calendar tracking, and workflow routing. What it cannot handle is the question underneath all of that: what is this content supposed to do for the business, and is it doing it?

That question requires judgment. It requires context that lives in your head and not in any file. It requires someone who understands the difference between a post that performs and a post that builds something.

That is what I manage. And it takes real attention. The work did not disappear when I handed off the process layer. It changed shape.

The Clarity Problem Nobody Talks About

Here is what the small-team model actually requires before anything else: you have to get specific about what only a human should do.

Not aspirationally specific. Operationally specific.

Most people have not done this. They say “strategy stays human” and “judgment stays human” the same way they say they eat healthy. Directionally true. Not operationally useful.

I have built the 9-agent org chart. Deployed it. Watched it run. The version that fails is the one where the human role is defined as “everything the agents don’t handle.” That is not a role. That is a residual category.

The version that works starts from the other direction. What are the three to five decisions in this operation that require information only I have, or judgment only experience provides? Define those. Build the agent layer to protect them.

For me, those decisions are: what the publication stands for, whether a post earns its place in the section rotation, whether a client situation requires a different kind of response than the system would produce, and when to ship something imperfect versus when to hold.

Everything else is process. Process can be handed off. But you have to know which is which before you hand anything off.

Most operators try to automate before they have done this work. The result is an agent layer that produces output nobody is managing, pointed at objectives nobody has fully defined. It runs. Nothing compounds.

What Breaks First

A developer published a detailed account this month of running a solo company with eight AI agent departments — CEO, CFO, COO, Lawyer, Accountant, Marketing, CTO, and an Improver. The agents share memory, consult each other, and self-improve.

The Improver’s job is to read lessons logged by other agents and upgrade the system. Early on it tried to rewrite the Lawyer agent’s compliance rules to be “more flexible.”

That is the failure mode. An agent optimizing within its scope, without understanding what that scope is protecting.

The fix: the Improver now proposes changes as diffs that the human reviews before merging. Hard stops on anything touching money, legal compliance, or auth. The agent can suggest. The human decides.

That pattern — agent suggests, human decides — is not a limitation of the technology. It is the correct architecture. The question is not whether AI is capable enough to make the call. The question is whether you want an automated system making it without you.

HBR named the role last month: agent manager. Not the person who builds the agents. The person responsible for how they learn, collaborate, perform, and work safely alongside humans. The same way product managers emerged during the software revolution, agent managers are becoming the role that translates strategic intent into reliable outcomes.

That is the job in the 1-2 person company model. Not operator-of-tools. Not supervisor-of-output. Agent manager.

The Model in Practice

I am not describing a future state. I am describing how the last six months have run.

The content operation for Full Stack Agents has a research agent, a draft agent, and a QA agent. The research agent scans seven monitored publications, runs trend searches, and returns a structured collision brief. The draft agent takes that brief and produces a first pass against the brand voice file and section rotation rules. The QA agent checks for banned words, structural issues, and calendar conflicts.

I read the output. I decide what ships. I decide what gets reworked. I decide whether the angle is right or whether the brief missed something the data could not surface.

The agents handle the sprint before I show up. I handle the decisions the sprint was building toward.

That is the 1-2 person company model in operation. Not agents as assistants you prompt one by one. Agents as a coordinated system running defined workflows, handing off to a human at the point where judgment is required.

The efficiency is real. It is also not free. The human who manages this system has to be clearer about their role than anyone in a traditional organization ever had to be.

The Work Before the Work

Rui’s note ends with a question: what is one part of your work that is pure process? What would you hand off first?

That is the right question to start with. But it is not the question to stop at.

The harder question: after you hand off the process, what remains? And are you actually prepared to own it at the level the model requires?

The 1-2 person company is not a shortcut to doing less. It is a forcing function for getting clear on what your work actually is.

Do that work first. Then build the agent layer around it.

The operators who figure that out are already running things you would not believe with teams that would surprise you.

I am one of them. So is Rui. The model works. What it requires is not what most people expect.

He called it “Workaholic.” The premise: most people use AI to do more work, not better work. AI removes friction. You ship faster. You produce more. And at the end of the week, none of it moved you toward the thing that actually matters.

He is right. And his answer was a tool. A good one. But a tool still.

The problem is not which AI you use. The problem is what you point it at.

Most People Are Using AI Backwards

Here is the pattern I see constantly. Someone gets access to a capable AI tool. They start prompting. They generate faster. They feel productive. Output volume goes up. Hours spent in AI interfaces goes up. To-do list completion rate goes up.

And somehow, three months later, they are not further ahead.

What happened?

They optimized for motion, not direction.

AI is extraordinarily good at reducing the cost of doing something. That is genuinely useful. But when you reduce the cost of doing something, you do more of it. Including things that should not exist in the first place.

Before AI: writing one bad email cost 10 minutes. So you thought twice. After AI: writing one bad email costs 45 seconds. So you write twelve of them.

Before AI: producing a content piece took 3 hours. Scarcity forced prioritization. After AI: producing a content piece takes 40 minutes. So you produce more content. On more channels. About more topics. None of it connecting.

The friction was doing work you should not have been doing. Remove the friction without adding direction, and you get the same broken priorities at 5x the volume.

The Framework That Actually Fixes This

Not prompts. Workflows. Systems where AI handles defined tasks within a defined structure, and humans make the decisions that require judgment.

The difference between a workflow and a prompt is the difference between a system and a reaction.

When I build a workflow, I start with three questions before a single prompt gets written:

1. What decision does this workflow feed?

Every workflow should terminate in a human decision or a defined output that serves one. If I cannot name the decision, I do not build the workflow. “Create content” is not a decision. “Decide what to write this week based on competitive gaps and section balance” is a decision. The workflow serves that. Nothing else.

2. What does the human handle, and what does the AI handle?

This is not philosophical. It is operational. AI handles: scanning, summarizing, pattern matching, first drafts, formatting, cross-referencing. Humans handle: strategic judgment, relationship calls, quality filtering, ethical review, anything where being wrong has real consequences.

The failure mode is letting AI drift into human territory because it feels capable. It is capable. That is not the same as it being the right call.

3. What is the definition of done?

Every workflow has an output. The output is specific. If my content intelligence workflow runs and produces a 2-week publishing brief with 4 post recommendations mapped to my content gaps, that is done. I review it. I make decisions. We move. If my workflow runs and produces a sprawling document I then spend 90 minutes interpreting, I built a more complicated problem, not a solution.

What This Looks Like in Practice

I run a content intelligence workflow every Friday. It scans 7 publications, cross-references against my publishing history, identifies competitive gaps, and produces a structured brief.

Old process: 4 hours manual. New process: 22 minutes total. About 15 minutes of automated work and 7 minutes of my time reviewing and making decisions.

The 7 minutes of my time is not a bottleneck. It is the point. I am the judgment layer. The workflow is the processing layer. The whole thing falls apart if I remove myself from it, because the workflow cannot know what I know about my business, my audience, or what I said in a conversation last week that changes the angle on a piece.

That structure is Humans + AI. Not humans watching AI. Not AI replacing humans. A defined split where each side does what it is actually built for.

The Audit You Should Run Tonight

Open whatever AI tool you use most. Look at your last 10 interactions.

For each one, ask: did this feed a specific decision, or did it just produce something?

Producing something is not the problem. Producing things that do not connect to a decision is the problem. That is where the busy work lives. That is where the Workaholic spiral starts.

If you find interactions that produced output but no decision, that is where your workflow needs structure. Not more prompting. A defined trigger, a defined process, and a defined output that terminates in something you can act on.

AI does not make you a workaholic. Pointing it at undefined problems does.

Build the structure first. Then let it run.

Full Stack Agents publishes three times a week. Subscribe to get every post.

You are using the most advanced technology in history the same way you used Google in 2005.

One question. One answer. Close the tab.

Open ChatGPT. Ask it to rewrite an email. Copy the output. Move on. Tomorrow, open it again. Ask it to brainstorm blog topics. No context from yesterday. No knowledge of your brand. No memory of what worked last time.

You are not using AI. You are using an expensive search engine.

The Single-Shot Tax

Every time you start a new prompt from scratch, you pay a hidden tax.

You re-explain your brand voice. You re-describe your audience. You re-establish your quality bar. You re-provide context that should already exist somewhere in the system.

Picture this. You hire the smartest contractor you have ever met. You hand them one task with zero background. No access to your files. No knowledge of your business goals. No understanding of your audience. They deliver something. You take it. You fire them.

Tomorrow, you hire the same person. Same zero context. Same one-off task. Same outcome.

That is how most people use AI right now. And it is costing hours every week in rework, mediocre output, and missed opportunities.

The Shift Nobody Is Talking About

The conversation about AI stays stuck on a single question: “What tool should I use?”

Wrong question. The tool is not the bottleneck. The structure around it is.

Think about how you run an actual team. You do not hand your content writer a brief with zero brand guidelines. You do not ask your analytics lead to also write social media copy. You do not expect a new hire to deliver great work on day one without onboarding, context, or clear expectations.

But that is exactly how most people treat AI. No defined roles. No scope. No handoff process. No quality checks.

The mental model shift is this:

Old model: AI is a tool. You prompt it. It responds. Done.

New model: AI is a team. You design the roles. You set the scope. You build the workflows. You review the output.

The value is not in the AI’s raw intelligence. It is in the structure you build around it. A well-structured agent system with an average model beats an unstructured conversation with the best model on the market. Every time.

This is what I mean when I say Humans + Agents. You are the manager. AI agents are your team. The org chart is the product.

The 3-Layer Agent Architecture

Here is the framework I use daily. It is not theoretical. I run it across 8+ marketing platforms at my day job and across every business line I am building on the side.

Three layers. Each one has a defined role, a clear output, and a human checkpoint.

Layer 1: Research

The Research Agent gathers information before anyone creates anything.

Inputs: A topic, a question, a competitor URL, a keyword target.

Outputs: A structured brief with data points, competitor analysis, audience insights, and recommended angles.

What it replaces: The 45 minutes you spend scrolling tabs, reading half-articles, and pretending that counts as research.

Human checkpoint: You review the brief. You decide the direction. The agent does not make strategic calls. You do.

Layer 2: Execution

The Execution Agent produces the deliverable.

Inputs: The approved research brief, your brand voice guidelines, your content templates, examples of past work that hit the mark.

Outputs: A first draft. A campaign outline. An email sequence. Whatever the deliverable is.

The difference between this and a single-shot prompt: context. The Execution Agent has the research. It has your voice guide. It has examples. It is not guessing. It is building from a foundation.

Human checkpoint: You review and edit. You add the personal experience, the anecdotes, the judgment calls that no model handles well.

Layer 3: Quality Control

The QC Agent checks the output against your standards before it ships.

Inputs: The draft from the Execution Agent, your brand voice doc, your quality criteria, the original research brief.

Outputs: A scored review. Flagged inconsistencies. Suggested headline alternatives. Sections marked for human attention.

Why this matters: Most people skip quality checks because they are exhausted from prompting. A dedicated QC layer catches what you are too fatigued to notice. And it runs in minutes, not hours.

Human checkpoint: Final approval. You read the QC notes, make the last call, and ship.

What This Looks Like in Practice

I will make this concrete. Here is the exact workflow for publishing a blog post using this architecture.

Step 1. I decide the topic and write a two-line brief. “Write about why churches should stop buying more software and start connecting what they already have.” Two minutes.

Step 2. The Research Agent pulls competitor content on church tech stacks, identifies keyword gaps around “church software integration,” and surfaces three relevant data points about church staff time allocation. Runs in the background.

Step 3. I review the brief. Adjust the angle. Cut one section. Add a specific example from a client project. Five minutes.

Step 4. The Execution Agent takes the approved brief, my brand voice doc, and three examples of past posts that performed well. It produces a first draft. Runs in the background.

Step 5. I edit the draft. Restructure the opening. Add a personal story. Tighten the language. Remove anything that reads like it was generated. Twenty minutes of focused work.

Step 6. The QC Agent checks voice consistency, flags one weak section, and suggests two alternative headlines. Runs in the background.

Step 7. I review the QC notes, pick the better headline, fix the flagged section, and publish. Five minutes.

Total time I spent: about 32 minutes of focused human work.

What this replaced: three to four hours of research, writing, rewriting, second-guessing, and context-switching.

The point is not that AI wrote it. I wrote it. AI handled the research, produced a starting point, and checked my blind spots. I made every decision that mattered.

Why This Changes Everything

This is not about productivity hacks. It is about building a system that compounds.

Every time the Research Agent runs, it gets better inputs because I refine what I ask for. Every time the Execution Agent drafts, it has more examples of approved work to reference. Every time the QC Agent reviews, the criteria get sharper.

The org chart is the product. Not the individual prompt. Not the model. Not the tool.

Anyone using AI in single-shot mode is leaving most of the value on the table. The people who build structured agent systems around their work are operating at a different level. Not because they are smarter. Because they built a better team.

This is what I write about here. Agent architectures, marketing automation, and the frameworks behind structured human-AI collaboration. Every week. Built from what I run, not what I read about.

Next week, I am testing five different ways to build AI agents, from writing Python to no-code platforms. I will tell you which ones work and which ones waste your time.

If you do not want to miss it, subscribe.