Technology · 15 min read
Church First. Open by Design.
Ediphai as the open intelligence platform for the local church, empowering churches to innovate with agents, choose their own vendors, and keep control of their ministry data.
The Church owns its mission. Technology should remain its servant.
Churches are becoming builders. A ministry director, a volunteer with a weekend and an AI assistant, or a multi-site team can now create a check-in tool, a discipleship intake, a gifts assessment, or a follow-up agent without waiting for a software vendor to ship it. That is good news for the local church. It also creates a new problem: when creation is cheap, the hard part is no longer building the tool. It is governing what the tool knows, who may use it, and what happens next.
At the same time, the church technology market is consolidating. The largest vendor now sells giving, church management, apps, streaming, and pastoral-care intelligence as one stack: “one login, one vendor, and one support team.” Intelligence about your people is being bundled with ownership of your people's data. Churches are being asked, quietly, to answer a question they never chose to ask: must your whole ministry stack come from one company in order to understand your congregation?
Ediphai's answer is no. Ediphai is the open intelligence platform for the local church, and it is church first. The church chooses its giving, church management, communications, and specialist tools. Its leaders build their own ministry experiences. Ediphai supplies the layer that makes those choices work together responsibly: access, security, governance, integration, and orchestration, with ministry intelligence that keeps the evidence visible and the human in charge.
Two benefits follow. First, churches can innovate with agents and apps safely, because identity, permissions, audit, and coordination are handled once rather than rebuilt inside every tool. Second, churches keep the freedom to choose the best vendor for each job, and to change their mind, because their ministry context lives above the applications rather than inside any one of them.
This paper describes what church first means, what the five layers do, what churches are already building, how an open layer compares with a single-vendor suite, and the commitments Ediphai makes so that it never becomes the dependency it exists to solve.
The moment: churches are becoming builders
For two decades the local church consumed software. It bought what vendors built and adapted its ministry to the vendor's workflow. That era is ending. Low-code tools and AI assistants have moved the ability to build from the vendor's engineering team to the church's own staff and volunteers. Churches in Ediphai's partner network have already produced their own attendance and check-in applications, a spiritual-gifts assessment app, and intake experiences for assimilation and care. None of these waited for a product roadmap.
The bottleneck has moved. A church can now build a form or an agent in an afternoon; what it cannot build in an afternoon is a trustworthy answer to five questions:
- Who is this person, really, and is the “Sarah” in the check-in app the same Sarah in giving and in the care team's spreadsheet?
- Who is allowed to see what, especially for children, counseling, prayer requests, and giving?
- Who is accountable for what this agent does, and until when?
- How does it connect to the systems the church already runs, without a fragile custom integration for each one?
- What happens next, and how do we prevent three agents from contacting the same family with three conflicting messages in one week?
Those five questions are the five layers of the Ediphai platform. Every church that builds will need answers to them. The only question is whether the answers come from a governed layer the church controls, or from the vendor that also holds its data.
The consolidation pattern
Ediphai makes no claim about any company's motives. The public record is sufficient, and churches deserve to see it laid out plainly.
Dec 2019
Pushpay acquires Church Community Builder (ChMS) for US$87.5 million, combining giving with church management.
Aug 2021
Pushpay acquires Resi Media (church video streaming) for US$150 million.
Oct 2022 – May 2023
Pushpay is taken private by a consortium of BGH Capital and Sixth Street in a scheme valued at roughly US$895 million, and is delisted from the NZX and ASX.
Apr 2026
Pushpay acquires Nurture.io, a pastoral-care and engagement-intelligence platform that aggregated signals from 17+ church systems, positioned to close the “shepherding gap” across Pushpay, Resi, and Nurture.
2026
ChurchStaq is marketed as “the all-in-one platform for giving, management, and engagement,” with AI-powered people search and AI Summaries, on “a single record — with one login, one vendor, and one support team.”
Each step is a rational business decision, and a tightly integrated suite can serve a church well. The pattern, however, has a structural consequence that churches should weigh with open eyes:
When the vendor that holds your data is also the vendor that sells you the intelligence about it, your data and your insight become the same company's asset, and whether anyone else may serve your church becomes that company's decision.
An independent intelligence platform that only exists at a vendor's pleasure can be priced, throttled, or disconnected the moment it becomes strategically inconvenient. Private ownership with a return horizon does not make that outcome certain; it makes the incentive explicit. The remedy is not to distrust any particular company. It is to place the church's ministry context (its identities, permissions, history, and decisions) in a layer the church controls, fed by whichever vendors the church chooses, and portable when those choices change.
What church first means
Church first is an allocation of authority, not a slogan. The church determines ministry purposes, theological boundaries, vendor choices, data permissions, pastoral escalation paths, and the named people accountable for each decision. Ediphai serves those decisions through technology. It never replaces them.
Three consequences follow, and Ediphai holds itself to all three:
- A member is never reduced to a score. No donor score, engagement score, or automated spiritual diagnosis stands in for a pastor's discernment. Ediphai surfaces context and evidence; people decide.
- The church's stack is the church's choice. A church may use a nonprofit giving platform such as MyWell, run operations on Planning Center or Rock, keep a specialist streaming or communications tool, and deploy locally built apps for its own ministries. Ediphai normalizes permitted signals from all of them into one coherent ministry context without requiring any single vendor to own the relationship. Interoperable ecosystems already work in practice: MyWell documents integrations with both Rock and Planning Center today.
- Ediphai claims no spiritual authority. The platform can tell a leader that a family's attendance pattern changed. It cannot tell the leader why, and it will not pretend to. Distinguishing a change in data from a change in someone's life is the pastor's work; Ediphai's job is to make sure the pastor sees it in time.
Church-built agents and apps
Check-in tools · intake forms · care follow-up agents · gifts assessments
Chosen vendors
Giving · ChMS · communications · streaming · specialist tools
Ediphai: the open intelligence layer
Access · Security · Governance · Integration · Orchestration, with ministry intelligence that keeps the evidence visible and the human in charge
Systems of record (replaceable)
The church's data stays the church's (portable, exportable, with provenance), whichever vendor holds it this year
The five layers
Ediphai does not need to host every custom church app, replace any system of record, or be the only interface a church uses. It supplies five things that every church-built tool and every chosen vendor would otherwise have to reinvent alone.
| Layer | The church's problem | What Ediphai does | What the church keeps |
|---|---|---|---|
| Access | Every app and vendor needs its own login, its own person list, and its own way in, so identities fragment and “who is this person?” has five answers. | One authorized front door for approved systems and church-built tools: a documented data contract (person identity, event, role, timestamp, source, consent, provenance) with identity matching that exposes uncertainty and offers correction paths instead of silently merging people. | Control of who and what may connect, and the final say on every identity match. |
| Security | Sensitive categories (pastoral care, children, counseling, prayer requests, giving) leak into tools no one hardened. | Scoped credentials and least-privilege access for every agent and integration; tighter boundaries by default for sensitive categories; financial signals never expose amounts to leaders who do not need them. | Its own policy on what is sensitive and who may see it, enforced everywhere at once. |
| Governance | No one knows which agents exist, who owns them, what they are for, or when they should be retired. | Every agent and integration carries a named human owner, a limited purpose, permitted data, allowed actions, an expiration or review date, and an audit history. Consent, retention, deletion, export, and breach response are explicit in agreements and in product controls. | Accountability that survives staff turnover and vendor changes. |
| Integration | Each new tool means another custom connector, another export, another spreadsheet. | Connectors, APIs, webhooks, and import paths chosen for reliability and church usability, including a standards-based agent interface so any AI tool the church trusts can query its data under the church's rules. | Freedom to add, replace, or retire tools without losing history. |
| Orchestration | Three well-meaning agents contact the same family with conflicting messages. Insights arrive with no evidence and no next step. | A single coordination layer across ministry roles: a connections agent recognizes an uncontacted guest, a care agent surfaces a request for a pastor, a discipleship agent proposes a next step. Deduplicated, sequenced, with the evidence visible and human approval required before sensitive outreach or consequential action. | The decision. Always. |
Together these produce what Ediphai calls ministry intelligence: authorized context combined to identify patterns worth human attention, then handed to the right person with the reasoning attached. The goal is not more automated ministry. It is better-informed human ministry: seeing people in context, coordinating appropriate follow-up, and giving churches durable control over their own technology choices.
What churches build when the layer is there
Three composite scenarios drawn from Ediphai's partner churches show the division of labor. In each, the church builds the thing that fits its ministry; Ediphai supplies what the church should never have to rebuild.
The Sunday check-in app. A ministry team builds its own attendance and check-in application because the vendor tool did not fit the way its campuses actually run. The app is excellent at the door. On its own, however, it creates a second person list, and its attendance signals never reach the people who care about them. Connected through Ediphai, check-in events flow into the church's ministry context with provenance attached, ambiguous identities are flagged for a human rather than merged, and a leader can see, without opening a second system, that a family who attended weekly has not been seen in six weeks.
The spiritual-gifts assessment. A multi-site church builds a gifts-and-design assessment tailored to its own discipleship language and asks whether its platform partner will host it. The church-first answer is not to absorb the app into Ediphai's roadmap; it is to let the church keep innovating while Ediphai handles what the app cannot: authorized access to the person record, results stored with consent and retention rules, and a governed hand-off so a completed assessment becomes a discipleship next step in the hands of the right leader, not a PDF in an inbox.
The care follow-up agent. A pastor configures an agent to watch for prayer requests, hospital notices, and life events and to draft a follow-up. Without governance, that agent is a liability: it may see counseling notes it should not, message a family already being visited, or run indefinitely after the pastor moves on. Under Ediphai, the agent has a named owner, a purpose, a scope that excludes counseling records, an expiration date, and a rule that every outbound message is approved by a person. Orchestration ensures the care agent and the connections agent know about each other. The pastor gets a draft with the evidence behind it, and the family gets one caring, coordinated contact.
The pattern is the same each time. Churches build the ministry-specific tool. Ediphai provides access, security, governance, integration, and orchestration. Neither has to become the other.
Single-vendor suite or open intelligence layer?
Both are legitimate choices. Churches should make the choice knowingly.
| Dimension | Single-vendor suite | Open intelligence layer (Ediphai) |
|---|---|---|
| Vendor choice | Best-of-suite: each function is as good as the suite's version of it. | Best-of-breed: the church picks the strongest tool for giving, ChMS, streaming, and communications. |
| Where intelligence lives | Inside the system of record, owned and priced by the same vendor. | Above the systems of record: the church's context, fed by any vendor the church authorizes. |
| Church-built apps and agents | Permitted where the suite allows; governed by the suite's roadmap. | First-class citizens with the same access, security, and governance as vendor tools. |
| Who governs agents | The vendor's controls, at the vendor's pace. | The church, through named owners, scopes, expirations, and audit. |
| Data portability | Exports as offered; history often tied to the suite's data model. | Portable records with provenance, documented exports, and replaceable connectors: a signed commitment. |
| Cost of switching | High: giving, ChMS, apps, and insight move together or not at all. | Low: replace one component; ministry context and permissions remain. |
| When you leave | Insight leaves with the suite. | Insight stays with the church, and Ediphai publishes its own exit process. |
| Commercial terms | Multi-product contracts; bundled pricing. | Month-to-month, priced against the staff time it saves rather than against the suite. |
Our open commitments
Openness that cannot be measured is marketing. Ediphai therefore commits, in its church agreements and in its product controls, to the following. If Ediphai itself makes exit difficult, it has recreated the dependency it promises to solve.
- The church owns its data. Ediphai is a steward, never an owner, of ministry information.
- Full export at any time, in documented formats, with provenance, at no penalty.
- Documented, standards-based interfaces for connecting systems and agents, so a church is never limited to the tools Ediphai chose to support.
- No exclusivity. Ediphai will not require a church to abandon a vendor, nor require a vendor to abandon a competitor, as a condition of working together.
- A published exit process that a church can execute without Ediphai's permission.
- Partner data is never turned against the partner. Ediphai will not claim to own a partner's customer, disintermediate a partner's product, or use a partner's data to compete with it.
These sit alongside six design commitments that are product requirements, not slogans: church-controlled authorization; least-privilege access; explainable insights; human approval for sensitive actions; interoperability and export; and accountability across agents and vendors.
Where we are today
A positioning paper should be honest about what exists. Ediphai's roadmap is in three horizons.
Today
- Live church partners across multiple denominational networks.
- A governed intelligence layer over church people, attendance, giving, groups, and household data, with church-defined terminology and definitions.
- A standards-based agent interface (Model Context Protocol) already in use, allowing AI assistants the church trusts to ask questions of its own data under its own rules.
- An Initiatives console for coordinating ministry action.
- Formation tools, including a gifts-and-design assessment, in the Ediphai app.
- Month-to-month terms.
Next
- The connector program: giving (beginning with MyWell), ChMS (Planning Center and Rock), and import paths for church-built tools, each under the access contract described above.
- Agent governance controls: named owners, scopes, expirations, and audit.
- Orchestration across the connections, care, and discipleship roles with human approval gates.
Horizon
- A published integration standard small enough for a small church to adopt.
- Portable, provenance-carrying ministry records that move with the church across vendors.
- A partner ecosystem in which giving, ChMS, and specialist vendors participate in ministry intelligence without surrendering their own products.
How a pilot works
Ediphai proves the model one ministry question at a time, with one church, its chosen giving platform, and its chosen ChMS. A representative first question: do authorized signals across giving, attendance, and groups improve a leader's ability to recognize and follow up with a person whose engagement has changed?
Success is not the number of alerts generated. It is whether leaders receive timely, accurate context and respond appropriately. Every pilot establishes, before any data moves: church consent; the minimum necessary data; identity-quality thresholds; human review of every sensitive action; and a way to measure both false positives and missed needs.
The first pilots are designed to settle, with evidence, the questions that matter most:
- Which signals are useful for ministry, and which merely create noise?
- What consent and privacy practices will churches adopt, and how do they vary by jurisdiction?
- How does a leader reliably distinguish a change in data from a change in someone's life?
- Which capabilities belong in Ediphai-native tools, and which should remain in independent church-built apps?
- What is the smallest integration standard a small church can actually use?
Because the governing model is church first rather than stack-specific, the proof travels: a second church on a different ChMS should get the same result with different vendors underneath.
The invitation
The church technology market is offering churches a bargain: hand over your whole stack, and we will tell you what it means. Ediphai offers a different one. Keep your stack. Build what your ministry needs. Choose the partners who serve you best, and change them when they stop. Ediphai will make those choices work together, with access, security, governance, integration, and orchestration the church controls, and with intelligence that serves discernment, discipleship, and human relationships rather than replacing them.
The Church owns its mission. Technology should remain its servant.