Having More vs. Being More: The Moral Architecture of AI Operations

In May 2026, Pope Leo XIV published Magnifica Humanitas, the first encyclical of his pontificate. Most of the coverage focused on the document's warnings about war and inequality. The more useful part, for anyone trying to deploy AI inside a business, is the frame it sets in the first ten paragraphs.

The encyclical opens with two biblical images: Babel and Nehemiah.

Babel is the tower built for its own height. A single language, a single technology, a single direction. A project conceived without reference to the people inside it, supported by a uniformity that eliminated diversity and chose homogenization over communion. Nehemiah is the wall built to make a city possible. An undertaking with God at the center, the encyclical says, which rebuilds relationships before rebuilding with stones.

The pope's argument is that the primary choice in front of any technological civilization is not whether to use the technology. It is whether the project is Babel or Nehemiah. Whether the tower is being built for its own height, or whether the wall is being built to make something else possible.

This is also, almost exactly, the architectural choice in front of anyone deploying AI inside a business.

What the pilot data actually says

78%

of enterprises have run an AI pilot

14%

have scaled one into production

78 percent of enterprises have run an AI pilot. 14 percent have scaled one to production. The 64 point gap is the most studied number in enterprise software, and the consensus across MIT, BCG, McKinsey, Gartner, RAND, HBR, Deloitte, KPMG, EY, and the Vovance synthesis of these studies is that the gap is not technical. The models work. The pilots usually return a reasonable output in a sandbox. They die in the move from sandbox to operation.

When researchers dig into why, they find the same three failure modes, in the same rough proportions, every time. The pilot has no private context to draw on, because the source of truth of the business lives in someone's head or in three half-used CRMs. The pilot has no clean handoff into the workflow it was supposed to support, because the workflow was implicit. The pilot has no governance answer for what happens when it is wrong, because the operating model was never written down.

This is Babel. A tall, impressive, narrow project, built on no foundation, that cannot live in the city it was supposed to serve.

Technology is never neutral, because it takes on the characteristics of those who devise, finance, regulate and use it. Pope Leo XIV, Magnifica Humanitas, §27

The encyclical's line about neutrality is exactly right. An AI deployed onto a business with no source of truth takes on the characteristics of that business. It will route ambiguous information to ambiguous workflows and produce ambiguous output, faster. The model is not the variable. The architecture is.

Babel: the pattern in the failed pilots

	Babel (the failed pilot)	Nehemiah (operations designed to perform)
Built for	Its own height. The demo.	To make the city possible. The operation.
Order of work	Tower first, on no foundation	Walls first, then everything else
Metric	Tasks completed, demo numbers	What the people can now do
Result	Having more	Being more

The pattern is the same in almost every failed engagement we have audited. A single tool gets bought. A single workflow gets automated. A single dashboard gets built. The tool does not connect to the rest of the operation. The dashboard reflects metrics nobody owns. The automated workflow saves time on a process the business did not need to be doing in the first place.

The leadership team is told the pilot is working. The numbers cited are demo metrics, not operational metrics. Then someone tries to extend the pilot into a second workflow and discovers that the first one was held together by manual cleanup nobody mentioned. The pilot quietly stops being talked about. The next AI initiative starts as if the first one never happened.

Pope Leo XIV names the underlying ideology directly. He calls it the technocratic paradigm: the tendency to let the logic of efficiency, control and profit alone shape personal, social and economic decisions. When efficiency is the only metric, the work of operations becomes invisible. When invisible, it does not get built. When it is not built, the pilots that depend on it cannot scale.

The encyclical quotes the German theologian Romano Guardini, writing in 1956 about a different technological inflection point: contemporary man has not been trained to use power well. The line is sharper today than it was then. Most AI consulting is selling more power. Almost none of it is training the people inside the business to use the power well.

Nehemiah: walls before towers

The alternative is the project Nehemiah ran in Jerusalem in the fifth century BCE. The city had been ruined. Most of the rebuilding programs available to him were about the temple, the visible institution, the symbol of return. He did not start there. He started by rebuilding the walls.

The walls are the unglamorous part. They are the part nobody photographs. They are also the only reason anything else inside the city could survive.

For an operation, the walls are the source of truth, the handoffs, the judgment points, and the feedback loops. They are the parts of the operating model that exist whether or not anyone has written them down. They are also the parts that, when missing, kill every AI pilot the business will ever run, no matter how good the model is.

This is not an argument against AI deployment. It is an argument about the order of operations. The Operations Audit comes first because you cannot redesign a workflow you have not understood. The Architecture Sprint comes second, when the audit finds that the source of truth is missing, fragmented, or living in one person's head. The Implementation Sprint comes third, simple or complex depending on what the audit and architecture revealed. The Advisory Partnership keeps the system honest as the business evolves around it, because what breaks an AI system is never the code, it is the business quietly moving.

1 · Audit

Operations Audit · 2 weeks

Produces the friction map and maturity stage that every later step is scoped from.

↓ scopes

2 · Architecture

Architecture Sprint · 1 week

Builds the single source of truth, the wall the agents will stand on.

only if the audit finds no source of truth

↓ supports

3 · Implement

Sprint · simple or complex

Puts agents on the wall, where they have context to draw on, not on sand.

↓ sustains

4 · Maintain

Advisory · ongoing

Keeps the system honest as the business quietly moves underneath it.

Skip the Audit and the architecture gets built against the wrong picture.

Skip the Architecture and the implementation sits on sand.

Each step is small. The sequence is the whole point. The five operational failures behind the pilot-to-production gap are all addressable, but they have to be addressed in this order. Skip the audit, and the architecture is wrong. Skip the architecture, and the implementation sits on sand.

The measure that matters: being more, not having more

The sharpest line in Magnifica Humanitas, for anyone designing systems, is this one:

If technological development advances without a corresponding ethical and social progress, the result may be an increase in means without a growth in humanity: having more without being more. Pope Leo XIV, Magnifica Humanitas, §39

This is the exact failure mode of bad AI deployment, stated in religious vocabulary. The pilot adds means. The business does not grow in any sense that matters. The dashboards multiply. Output goes up. The people inside the operation are not doing more meaningful work. They are doing the same work, with more interfaces.

The measure of a good AI deployment is not how many tasks the agent did. That is having more. The measure is what the people in the business are now able to do that they could not do before. Better judgment, less administrative drag, more capacity to lead. That is being more.

This is what operations designed to perform means in practice. Perform meaning the business becomes more capable, not just more active. Perform meaning the principal is freed up to do the work only the principal can do, not freed up to monitor an agent that is doing the wrong work faster.

The line we use with clients is older than the encyclical, but it points at the same idea: agents do not eliminate the need for human judgment. Agents eliminate the friction around human judgment. The human is the thing the system serves. The model is the tool the human uses. When that order is right, the deployment grows the business. When it is inverted, the deployment is Babel.

What this looks like in an engagement

In practical terms, every engagement starts with the Operations Audit. Two weeks. Standardized scope. Four lenses: systems and infrastructure, process and workflow, visibility and metrics, scale and AI readiness. The deliverable is a clear picture of where friction lives in the operation, which workflows are ready for automation, and which ones need to be rebuilt first.

The audit is also a maturity diagnosis. Mobilize, Activate, Amplify, Sustain. The stage we place a business in determines what the next engagement is. A business in Mobilize, with no formal systems and a founder doing everything, does not need an agent. It needs a wall.

If the audit reveals that the source of truth lives in someone's head or is spread across competing tools, the next step is the Architecture Sprint. One week. The wall gets built. Only after the wall is built do we put any AI agents on top of it. Because agents on top of bad architecture inherit the bad architecture and amplify it.

This is also the answer to the most common question we get from technical founders: why not just deploy the agent and see what happens? Because the agent is the easy part. The agent is a commodity. The hard part is everything underneath it. And the hard part is what determines whether the deployment grows the business or becomes another expensive pilot that quietly stops being mentioned.

Designed to perform

The portfolio our founder runs across three brands is held together by a single phrase: designed to perform. Spaces designed to perform. Operations designed to perform. Tools designed to perform. In every case, performance means the thing serves the human, not the other way around.

An operation designed to perform is one in which the people inside the business are doing more meaningful work, with better judgment, in less time. The dashboards reflect that. The agents support it. The architecture makes it possible. None of the parts work without the others, and the order they get built in determines whether the system is Babel or Nehemiah.

The encyclical's closing image is a community of builders rather than architects of a single tower. Be builders of communion, it says, rather than architects of Babel. That is also the right closing image for an AI program. The tools are the easy part. The community that runs the operation, holds the judgment, and uses the tools well is the whole point. The work is to build the conditions under which that community can do its best work, and then to put the right tools in their hands.

If you have an AI pilot stuck in production purgatory, or you are about to start one and would rather not, our approach begins with the honest work of understanding the operation. More perspectives on the operational discipline behind AI deployment, and the frequently asked questions for the practical edges.