The Four-Week Agent Build That Exposed Why Ministry Teams Keep Shipping the Wrong Thing

I sat there with the volunteer coordinator while the printer jammed for the third time that morning. She didn’t swear, just reached over, tugged the half-printed sheet free, and wrote the activity on the back of her hand with a Sharpie. We had four weeks on the calendar and one working laptop between us. The agent was supposed to spit out usable ideas. Instead it kept asking questions we already knew the answers to.

That small failure kept bothering me long after the test ended. We hadn’t built the wrong tool on purpose. We’d simply started from the assumption that ministry teams needed more information and better structure, when what a working ministry agent build actually needed was something that could survive a broken printer and a folding table.

The printed job description that actually mattered

The sheet on the wall listed five duties and nothing else. The agent had to pull the right lesson from the curriculum folder, check the supply list against what the church already owned, suggest one adjustment for the current group size, and stop. No extra explanations. No new ideas unless the coordinator asked.

That single card kept the scope from drifting. When the model tried to generate a full service order or suggest new songs, the team rejected it on the spot because it violated the printed duties. The rule “do no harm” translated directly into refusing outputs that added work the volunteer would later have to undo.

The card also made evaluation simple. At the end of each day the coordinator marked yes or no next to each duty. After two weeks the team could see exactly which duties the model handled and which ones still needed guardrails. No abstract accuracy score. Just five lines on paper that matched the real job.

What happened when the children’s director sat in the room

She did not join as a reviewer after the fact. She sat at the table while the tests ran and said out loud when an answer would waste her time or create extra steps. One response suggested printing three extra pages. She shook her head and the team added a constraint that every answer had to reference only materials already in the supply closet.

Her presence turned the model from a general tool into a narrow assistant that understood her actual constraints. The rule “do good” stopped being theoretical. It became the moment she said “that works” and the agent moved to the next test case without further changes.

The team also noticed when she stayed quiet. If she had to re-read an answer twice, they treated the silence as a signal that the output had failed the “stay in love” test. It did not serve the person doing the work on Sunday morning.

Why a narrow ministry agent build beats a six-month roadmap

A larger committee would have started with questions about model choice, data privacy standards, and long-term hosting. This team started with the printed card and one user. They shipped a working version in twenty-six days because every decision stayed inside the five duties on the wall.

The narrow scope forced shared understanding. When something broke, all three people could point to the same line on the card and agree on the fix. No one argued about future features because the calendar on the door said the build ended on day twenty-six.

The same pattern shows up in other ministry tools. When scope stays small and the user stays close, the real constraint turns out to be clarity between the people in the room, not the power of the model.

Your Turn: Apply This Today

• Choose one named ministry role, such as the children’s coordinator at your church, and write their exact job on a single printed page before you open any code editor.
• Block one four-week window on the calendar with the end date written in pen and commit to shipping only what fits on that page.
• Run every test with the actual person in the chair and require them to say yes or no to each output against the printed duties that same day.
• Reject any model response that adds work the user would have to fix later, even if the response looks impressive.
• At the end of week two, review only the marks on the printed page and cut any duty the model still fails more than once.
• Document the final working agent by the job card it serves, not by the model or framework it uses, then move the card to the next narrow task.

The same narrow-build pattern appears in both “The PM Who Just Shipped an Agent and Now Needs an Evaluation Layer” and “The Custom Agent We Had to Build After Off-the-Shelf Tools Hit Ministry Data Limits.”

I consult with faith-tech product leaders on running tight four-week agent builds and keeping scope narrow with actual ministry users. Let’s talk.