The Pope's AI Encyclical Is Actually an Agent Deployment Checklist

By Lazar Milicevic · Published June 10, 2026 · 8 min read

Pope Leo XIV published a sixty-page encyclical on AI last week and the internet immediately split into theology camps. I read it differently. I ship Claude and n8n agents into paying clients' Gmail inboxes every week, and the document reads less like doctrine and more like the pre-deployment checklist I wish every solopreneur ran before turning their agent loose.

The encyclical lists five concerns: human dignity, labor displacement, surveillance, autonomy erosion, and truth. Every one of them is a production bug I've already hit and patched. Here's the technical translation, with the actual gates you can wire up this weekend.

Gate 1: Human-in-the-Loop Approval (Dignity)

If your agent drafts a message to a paying client, the agent does not press send. A human does. That's the whole pattern. In production I run this through Telegram because it's free, fast on mobile, and the Bot API is two lines to wire up.

The agent prepares the draft, posts it to a private chat with inline buttons, and only on approval does it touch the Gmail API. Reject button kills the action and optionally logs the reason for fine-tuning the prompt.

# n8n / Python pseudocode for the approval gate
import requests

def request_approval(draft: dict, chat_id: str, bot_token: str) -> str:
    payload = {
        "chat_id": chat_id,
        "text": f"📧 Draft to {draft['to']}\n\nSubject: {draft['subject']}\n\n{draft['body']}",
        "reply_markup": {
            "inline_keyboard": [[
                {"text": "✅ Send", "callback_data": f"send:{draft['id']}"},
                {"text": "❌ Reject", "callback_data": f"reject:{draft['id']}"}
            ]]
        }
    }
    r = requests.post(
        f"https://api.telegram.org/bot{bot_token}/sendMessage",
        json=payload
    )
    return r.json()["result"]["message_id"]

# Gmail send only fires from the callback handler, never from the LLM directly

Cost: roughly 20 seconds per message of your time. Return: the one client email that would have gone out with a hallucinated price never goes out.

• Approve/reject lives in a chat you already check
• The LLM never holds Gmail send permissions directly
• Reject reasons become training data for the next prompt iteration

Gate 2: Augmentation Framing (Labor Displacement)

The encyclical's labor concern translates cleanly: your agent drafts, summarizes, prioritizes, prepares. The human sends, decides, owns. The line between "replaces a role" and "multiplies a role" is literally where you place the final irreversible action.

This is not philosophy. It's a workflow topology decision. Here's the same agent wired two different ways:

# Replacement topology — agent owns the outcome
trigger: new_inbound_email
steps:
  - classify_intent
  - draft_reply
  - send_email          # ← irreversible, no human
  - log_to_crm

# Augmentation topology — human owns the outcome
trigger: new_inbound_email
steps:
  - classify_intent
  - draft_reply
  - queue_for_review    # ← human gate
  - on_approve: send_email
  - log_to_crm

Same code, same model, same prompt. Different business model. The augmentation version is what I sell. The replacement version is what gets a client refund request when the model hallucinates a 40% discount.

Gate 3: Data Minimization (Surveillance)

Most builders dump entire customer records into the context window because tokens feel cheap. They are cheap. PII leakage across logs, vector stores, and provider-side prompt caches is not.

The fix: project only the fields the agent needs for this specific task. If the agent is writing a follow-up email, it does not need a phone number, a billing address, or a payment method ID. Strip everything else before it hits the model.

ALLOWED_FIELDS = {
    "draft_follow_up": ["first_name", "last_inquiry_topic", "last_contact_date"],
    "draft_invoice_reminder": ["first_name", "invoice_id", "amount_due", "due_date"],
    "summarize_thread": ["messages"],  # no contact metadata
}

def minimize_context(task: str, customer: dict) -> dict:
    fields = ALLOWED_FIELDS[task]
    return {k: customer[k] for k in fields if k in customer}

# Anything not in ALLOWED_FIELDS literally cannot reach the model
prompt_context = minimize_context("draft_follow_up", customer_record)

I treat the model provider the same way I treat a third-party subprocessor in a DPA. If I wouldn't send the field over an unencrypted webhook, it doesn't enter the prompt.

• Whitelist fields per task, never blacklist
• Strip before serialization, not in the prompt template
• Log the minimized payload, not the original record

Gate 4: Explicit Consent at Execution Time (Autonomy)

Signup checkboxes are not consent for an agent action. Consent is a prompt that shows the actual content of what's about to happen, at the moment it's about to happen.

Before the agent sends an email, charges a card, posts to a social account, or modifies a CRM record, the user sees the exact payload. This is different from Gate 1 — Gate 1 is your approval as the operator. Gate 4 is the customer's consent when the agent acts on their behalf.

In practice the two collapse for solo operators (you are both). For client-facing tools they're distinct:

def execute_external_action(action: dict, user_id: str) -> dict:
    # Show actual payload, not a generic checkbox
    confirmation = present_to_user(user_id, {
        "action": action["type"],
        "target": action["target"],
        "payload_preview": action["payload"],
        "reversible": action.get("reversible", False),
    })
    
    if not confirmation.approved:
        return {"status": "cancelled", "reason": confirmation.reason}
    
    return dispatch(action)

The rule I use: any action that costs money, sends a message under someone else's name, or writes to a system of record requires a per-execution prompt showing the actual content.

Gate 5: Grounded Retrieval With Citations (Truth)

Never use a raw language model for factual claims about your business, your pricing, your policies, or your customer's data. Ground every factual output in a retrieval call against a source of truth, and surface that source in the response.

If the agent claims an invoice was paid on the 14th, it's quoting your database, not improvising. If it quotes a refund policy, it's pulling the current policy doc and citing the version.

def answer_with_source(question: str, customer_id: str) -> dict:
    # Retrieve first, generate second
    facts = db.query(
        "SELECT invoice_id, paid_at, amount FROM invoices "
        "WHERE customer_id = %s ORDER BY paid_at DESC LIMIT 5",
        (customer_id,)
    )
    
    if not facts:
        return {"answer": "I don't have invoice records for this account.", "source": None}
    
    response = llm.generate(
        system="Answer ONLY using the facts provided. If the answer isn't in the facts, say so.",
        user=question,
        context={"facts": facts}
    )
    
    return {
        "answer": response.text,
        "source": {"table": "invoices", "rows": [f["invoice_id"] for f in facts]}
    }

The system prompt is doing real work here. "Answer ONLY using the facts provided" plus a structured facts payload reduces hallucination on factual queries to near zero in my deployments. The citation in the response is the audit trail.

Why bizflowai.io helps with this

The five gates above are the default architecture I deploy for clients at bizflowai.io — every Gmail-Telegram agent, every invoicing automation, every lead-gen pipeline ships with the approval flow, the field whitelist, the per-action consent prompt, and the grounded retrieval pattern baked in from day one. It's not a premium tier or a compliance add-on. It's the only way I'm willing to put an agent in front of a paying customer, because I've personally hit every failure mode these gates prevent. If you want the architecture without rebuilding it from scratch, that's what we install.

The Uncomfortable Part

An institution that took four centuries to apologize to Galileo just published cleaner agent design principles than most VC-funded AI startups have in their internal docs. That should embarrass the industry. It should encourage you. The bar for responsible deployment isn't a mystical engineering achievement — it's five gates a solo builder ships in a weekend.

Open the agent you're building this week. Walk it through:

• Approval before send
• Augmentation over replacement
• Minimum data in context
• Explicit consent for external actions
• Grounded retrieval for factual claims

Yes on all five and you're ahead of most production AI deployments I see in mid-sized companies. No on any of them, you have a concrete punch list. The Pope didn't hand us a debate. He handed us a checklist.

Frequently asked questions

What is the Pope Leo XIV AI encyclical?

Pope Leo XIV released an encyclical focused on artificial intelligence, unveiled alongside one of Anthropic's co-founders. An encyclical is the highest form of papal teaching document, meant to outline doctrine for decades. The roughly sixty-page document centers on five concerns about AI: human dignity, labor displacement, surveillance, autonomy erosion, and truth. Anthropic's presence signals the Church is engaging directly with AI builders rather than commenting from the sidelines.

How do I add a human-in-the-loop approval gate to an AI agent?

Build an approval flow where the agent drafts the action but never executes it directly. One practical pattern uses Telegram: the agent prepares a draft email, posts it to a private chat with approve or reject buttons, and only on human approval does it call the Gmail API. This adds about twenty seconds per message and eliminates roughly ninety percent of catastrophic agent failure modes.

Why does data minimization matter for AI agents?

Most builders dump entire customer records into an agent's context because tokens feel cheap, but this spreads PII across logs, vector databases, and prompt caches you'll never audit. Data minimization means only injecting the specific fields the agent needs for the current task and stripping everything else before it reaches the model. If the agent doesn't need a phone number to write a follow-up email, it shouldn't enter the prompt.

How do I prevent AI agent hallucinations on business facts?

Never use a raw language model for factual claims about pricing, policies, invoices, or customer data. Use grounded retrieval: every factual output should come from a retrieval call against a source of truth, like your database, and the response should cite that source. If the agent says an invoice was paid on the fourteenth, it should be quoting the database directly, not improvising from model weights.

When should an AI agent require explicit user consent?

Require an explicit consent prompt at execution time before any external or irreversible action, such as sending an email, charging a card, posting to social media, or modifying a CRM record. The prompt should display the actual content of what is about to happen, not a generic checkbox buried at signup. This execution-time gate is what separates a trusted tool from one that surprises users.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.