Orchestrating LLMs for Ministry and Mission

We started with a moderate server setup—featuring an AMD Ryzen 7 7700X, 64GB DDR5 RAM, and a powerful RTX 3090 with 24GB of VRAM—ready for serious LLM work. The goal: move beyond simple single-LLM chat applications and into the realm of complex, collaborative, and stateful AI workflows. The answer was Multi-Agent Orchestration.

This is primarily for churches/ministries that prefer:

• Cost-conscious design: One-time hardware investment vs. ongoing API costs
• VRAM optimization: With limited GPU memory, hot-swapping models is smart
• Concurrent processing: Running 2-3 specialized models simultaneously maximizes throughput
• Local deployment: Perfect for privacy-sensitive pastoral data
• Specialization strategy: Using smaller, focused models rather than one large model

The assumption is that many ministry tasks happen at the same time, such as creating bulletins, writing counseling notes, and preparing sermons. Privacy is very important, so counseling data can't be sent to external APIs. Budget limitations are also a concern: hardware costs around $2,000, and API expenses can exceed $200 each month. Most churches can't afford to fund volunteer-driven ministries that need systems to be available all the time.

The Architecture: Why LangGraph & LangSmith?

While initial thought leaned toward basic LangChain, our advanced use case demanded a more sophisticated, graph-based approach to handle state, conditional logic, and true agent collaboration.

• Core Orchestration: We adopted a custom, Async/LangGraph-inspired framework as the brain of the operation. This allows agents to dynamically route tasks, debate solutions, and adapt workflows based on real-time reasoning.
• Production Monitoring: LangSmith was integrated to provide essential tracing, monitoring, and debugging for production-readiness, turning complex agent interactions into traceable, measurable workflows.
• Infrastructure: Our system is containerized with Docker, using PostgreSQL for state persistence (agent memory and workflow checkpoints) and Redis for inter-agent communication and high-speed caching.

---

The Power of Specialization: Our Ollama Model Pool

The key to our system's intelligence is specialization. We leverage the power of Ollama to host multiple, lightweight, and high-quality models, each assigned a specific role. This strategy maximizes the RTX 3090's 24GB VRAM.

Agent Type	Ollama Model	Role & VRAM Strategy
ReasoningAgent	qwq (e.g., Qwen-72B)	The "Powerhouse." Always loaded (approx. 19GB), handling complex logic and high-level strategy.
CodeAgent	codellama	Handles coding, debugging, and syntax tasks. Hot-swapped (approx. 3.8GB) when reasoning determines a coding task is needed.
GeneralAgent	mistral	The "Coordinator." Handles chat, initial intent classification, and general tasks. Always loaded/Hot-swapped (approx. 4.4GB).
VisionAgent	llama3.2-vision	On-demand agent for multimodal tasks (image analysis).

This intelligent model allocation ensures we are running 2-3 models concurrently, achieving maximum throughput and minimizing idle GPU time.

---

The Game Changer: Adding Semantic Intelligence

The final, critical enhancement was the introduction of the EmbeddingAgent, which utilized the nomic-embed-text model.

• Before: Agent memory was searched via simple keywords.
• Now: The EmbeddingAgent provides a foundational layer of semantic intelligence. This allows agents to:
• Perform Semantic Search on their memories in PostgreSQL.
• Retrieve Context by meaning, not just by keyword, leading to dramatically better-informed responses.
• Enable RAG (Retrieval-Augmented Generation) for all specialist agents.

This lightweight (274MB) model stays permanently loaded, transforming our memory system into a sophisticated, context-aware knowledge graph for the entire agent collective.

---

The Hybrid Architecture: Agents and Automation Together

A crucial distinction in our architecture is the relationship with n8n, our existing workflow automation tool. We aren't replacing n8n, we're enabling more complex instructions to maximize n8n's capabilities.  At least that's the theory.

System	Role	Example
n8n	Business Process Automation	Webhook triggers, sending emails, updating CRM, data sync.
Agent System	AI-Native Orchestration	Complex reasoning, multi-turn conversations, dynamic problem-solving.

Some Integration Examples

Biblical Question Answering (Augmented LLM with RAG)

Problem: Congregation members have theological questions outside office hours 

Simple Solution:

• LLM with retrieval access to: the church's statement of faith, recommended commentaries, pastoral teaching archives
• Provides scripturally-grounded answers consistent with church doctrine
• Flags complex theological questions for pastor follow-up

Why this works: Single LLM call with retrieval. No multi-step workflow needed for most queries.

Small Group Discussion Guide Generator

Let's consider a district with four churches and one pastor who wants to implement small groups in his church. The problem is that several small group leaders need discussion guides each week. To address this, a multi-agent solution could be developed. The process begins with an input: this week's sermon manuscript. A CoordinatorAgent identifies the needs of the small group leaders. Then, a WritingAgent generates initial discussion questions. These questions are evaluated by a TheologyAgent to ensure they are doctrinally sound, accessible to new believers, and have clear practical application. Based on feedback, the WritingAgent revises the questions, repeating this cycle two to three times to refine the guides. The final output consists of ten personalized guides with varied difficulty levels, processed concurrently in about five minutes. Optimization is crucial because the first drafts tend to be too academic; iterative revision makes the guides more accessible. Concurrent processing allows all the guides to be prepared simultaneously, streamlining the workflow and enabling the study guides to reach the group faster. Something that would normally take weeks — maybe a few days for the best pastors — could be done in as little as five minutes, without sharing data with Anthropic, Google, or OpenAI.

Conclusion

We've successfully transitioned from a concept to an operational multi-agent platform, although "success" requires acknowledging trade-offs. Our system maximizes hardware ROI and provides capabilities—such as stateful reasoning, semantic memory, and concurrent processing—that would be cost-prohibitive with commercial APIs for our use case.

However, we've sacrificed the raw intelligence of frontier models like Claude Sonnet 4.5 for the benefits of local deployment: absolute privacy, predictable costs, and true 24/7 availability. Our specialized model approach (reasoning, coding, general, embedding) compensates for individual model limitations through intelligent orchestration—routing complex theological questions to our 72B reasoning model while handling routine communications with lighter 7B models.

The architecture shines for batch operations and privacy-critical workflows. For organizations where data sovereignty and concurrent task processing matter more than cutting-edge model performance, this local multi-agent approach transforms budget constraints into architectural advantages.

Is it more complex than necessary? Perhaps. But complexity here buys us capabilities we literally couldn't afford otherwise.