Why the ‘Agent as Hire’ Framing Breaks the Moment Real Ministry Work Starts

I watched the agent stall on a Tuesday morning while trying to confirm a last-minute volunteer for the preschool room. It had the job title we gave it, the reporting line, the whole hire packet. But the background-check flag sat in a shared folder the agent wasn’t cleared to touch, and the real person on the other end of the Slack thread needed an answer before the kids arrived.

We’d followed the playbook. Defined the role, set the boundaries, told ourselves the title would keep everything clean. Instead the work just leaked around the edges—permissions, last names that couldn’t be shared, a parent request that only made sense if you knew the family.

That’s the part the agent as hire framing never prepared us for.

Teresa Torres’s continuous discovery practice offers the corrective lens. Torres insists that product teams run weekly interviews and opportunity-solution mapping with the actual users whose constraints the product must respect. Applied to agents, the practice replaces the static job description with repeated, small tests against real ministry workflows. The agent is never “hired” once; its boundaries are rediscovered every time new data or new ministry rules appear.

The “agent as hire” framing that looked clean on the brief

We gave the first agent the title “Volunteer Coordinator Assistant.” The brief listed three clean responsibilities: match volunteers to open slots, send reminders, and log completion. The title fit on a slide and satisfied the leadership review.

Three weeks later the agent began pulling from the children’s ministry database to confirm background-check dates. The original job description contained no clause for that data. The agent surfaced a volunteer whose check had expired but whose name still appeared in the active pool. The mismatch between title and actual work surfaced only when the volunteer showed up at the church with two children and no cleared status.

The title had created the illusion of control. It did not force the team to define what the agent should do when a record sat in two different systems with conflicting dates. Continuous discovery would have required talking to the children’s ministry coordinator before the agent ever touched the database.

How continuous discovery exposes scope creep in the first real handoff

Torres’s method requires weekly interviews with the people who feel the pain of the current process. In our case that meant sitting with the volunteer scheduler and walking through the exact sequence she follows when a new family registers. The interview revealed that she always checks two sources: the main church database and a separate spreadsheet the children’s ministry keeps for allergy and custody notes.

The agent, built against the job title alone, had only been given access to the main database. When we ran the first live handoff, the agent assigned a volunteer to a class without seeing the custody note that barred the volunteer from that specific room. The scheduler caught the error in the same afternoon the agent ran.

The exposure came from the interview, not from the agent’s output. The job title had hidden the second source. Continuous discovery made the second source visible before the agent could act on incomplete information.

The approval gate that replaced the fake job description

After the custody-note incident we stopped writing job titles. Instead we defined an approval gate that must pass before any production run. The gate requires three explicit discovery questions answered in the last seven days: Which data sources will the agent read that were not listed in the prior gate? Which ministry rule changed since the last gate? Which user group will see the agent’s output for the first time?

Only after those three questions receive fresh answers does the agent receive the production token. The gate is logged and dated. If any answer shifts, the token is revoked until the next discovery cycle.

The gate forces the team to treat the agent as a system under test rather than an employee who has already been onboarded. It removes the false comfort of the original title and keeps the scope tied to the current state of ministry data. That is the real alternative to the agent as hire framing: not a better title, but a discovery habit that never stops running.

Your Turn: Apply This Today

• Replace the current agent job title with three explicit discovery questions written on a single card: which two data sources will it read this week, which ministry rule must it respect, and which user will review its output before anyone else sees it.
• Schedule one 30-minute interview this week with the person who actually touches the data the agent will use; ask only how they decide when to override an automated suggestion.
• Build the approval gate as a single checkbox in your deployment checklist that reads “Three discovery questions answered in the last seven days” and require a named person to initial it.
• Run the agent in a shadow environment against last month’s real volunteer schedule for one day and log every record where the agent would have acted on incomplete data.
• Remove the agent from production if any of the three discovery questions cannot be answered with a current date; treat the removal as routine maintenance rather than a failure.
• Document the answers to the three questions in the same ticket system you use for code changes so the next developer sees the ministry constraint before touching the prompt.

The PM Who Just Shipped an Agent and Now Needs an Evaluation Layer shows what happens when teams skip the gate after the first production run. The Evaluation Layer That Broke When We Trusted the Model Alone details the exact data mismatch that forced a second gate into every subsequent release.

I consult with product leaders and ministry technology teams on continuous discovery loops for agents, approval gates that survive real attendee data, and scope control once agents touch volunteer or children’s ministry records. Let’s talk.