The Agent We Built Because Nothing Off the Shelf Would Touch Our Data

The files sat open on my laptop again at 11:17 at night. One tab held the Sermons4Kids export with its clean columns, the other the volunteer sheet someone had typed by hand, and nothing matched. I kept telling myself the next tool would just read both and figure it out.

We waited anyway. Three platforms took our money and our time while we held off on the small fixes we actually knew how to make. The curriculum stayed frozen, the same spreadsheet kept circulating, and the gap between what we needed and what anyone would sell us only grew wider.

Eventually the waiting started to feel like the real decision we were making.

The rule that forced us to stop shopping for agents

Do no harm meant we could not send raw volunteer feedback or children’s ministry notes to any external service that retained training data. Most vendors were clear about this once we asked directly. Their default position was that our content would improve their model. That single clause ended the evaluation process for every off-the-shelf option we had shortlisted.

Do good meant the agent had to reduce actual time spent by the 7-minute volunteer, not generate impressive demo outputs. Our internal logs already showed where volunteers abandoned the workflow. We did not need another dashboard. We needed a narrow script that flagged incomplete lessons before they reached the printer queue.

Stay in love with God kept the scope narrow enough that one person could maintain it. We stopped adding features once the agent performed one reliable task on our own data. Everything else waited until that task ran without intervention for a full quarter.

Where proprietary data actually lives in small teams

The useful records were never in the main database. They sat in the shared drive folder labeled “old volunteer notes,” the email threads between regional coordinators, and the margin comments on the print PDFs that came back from churches. These fragments contained the real signals about which lessons worked and which ones created extra work.

We mapped every place a decision was recorded outside the official system. The map was shorter than expected—fourteen locations total. Most were simple text files or forwarded messages. None of them matched the clean tables the commercial agents required.

Once we accepted that our data lived in those places, the build decision became mechanical. We wrote a small script that pulled from those fourteen sources, normalized the dates, and wrote a single daily summary into the existing volunteer dashboard. No new interface. No new login.

How one narrow internal agent changed our release rhythm

The first agent we kept simply checked whether every lesson in the upcoming release had a completed volunteer test record. It ran every morning and posted a one-line status in the team channel. If a lesson was missing its record, the line included the name of the last person who touched the file.

That single check removed the weekly release meeting that had been scheduled for thirty minutes every Monday. The meeting still happened, but it now started with the agent output already on screen and ended in twelve minutes instead of running long. The saved time went into testing one additional lesson per cycle.

After eight weeks the team began adding one more rule at a time. Each addition stayed inside the same narrow lane: read only from the places we already controlled, write only to the places the volunteer already looked. The pattern kept the agent maintainable by the same two people who handled content updates.

Your Turn: Apply This Today

• Pick the single workflow your current tools ignore—volunteer lesson testing, print file handoff, or regional coordinator check-ins—and list every place the decision record currently lives.
• Write a five-line script that reads only from those locations, checks one condition, and writes the result to an existing channel or dashboard you already use.
• Run that script daily for two weeks and log the exact minutes it saves or the exact error it catches before anyone else notices.
• Refuse to add a second condition until the first one has run without manual fixes for a full release cycle.
• Document the fourteen or fewer data locations in a single shared note so the next person can maintain the script without asking you.
• Compare the time spent maintaining the script against the time previously spent in the meeting or process it replaced; stop if the ratio exceeds one to five.

The pattern in “The Data Moat That Actually Matters for Small Ministry Teams” and “The Question I Kept Answering About Internal Ministry Data” shows why the smallest internal agents outlast the broadest vendor promises. I consult with ministry product leaders and faith-tech teams on building narrow agents over their own data and protecting release rhythm when external tools fall short. Let’s talk.