Blog

She opened the laptop at the kitchen table after midnight. The schedule the agent had built for Sunday looked clean enough, except the two names were in the wrong places. She knew the story behind the swap. The system did not.

The fields were locked. No drag, no comment, no override. She stared at the blinking cursor, then shut the lid. Someone else would have to fix it in the morning.

The coordinator in this case held the final constraint. She alone knew which names could not appear together. The agent had optimized for coverage and availability, but those metrics never reached the hidden variable of family conflict. The lattice broke where the human authority began.

Products that treat the model as the complete system repeat this break. They optimize inside the training distribution and declare victory when the output looks reasonable on screen. The real work of coordination sits outside that frame, held by the person who signs the schedule and answers for it when something goes wrong.

The first section of any useful lattice must therefore include the person who owns the final yes. Without that node, the model cannot see the actual decision surface it claims to improve.

Munger’s approach forces product teams to keep adding frames until the real constraint appears. In practice this means asking what the coordinator must protect that no training data captures. It also means building the interface so she can act on that protection without leaving the tool.

One team I watched ran the agent output through a second review layer that required the coordinator to confirm or override any assignment. The override rate sat at 18 percent on the first week. Every override logged a constraint the model had missed. Over four weeks the team added three new signals to the prompt and the override rate dropped to 7 percent. The lattice had simply been extended one node further.

The same teams often ask the wrong questions when they run discovery. They ask the coordinator what she likes about the current schedule or how the agent could generate better first drafts. Those questions assume the model already holds the relevant variables. They rarely surface the constraints that live only in the coordinator’s head.

Better questions name the hidden keyholder directly. Ask what rule she applies in the final five minutes before she signs a schedule that no one else sees. Ask which names she has already mentally moved even though the agent has not. Ask what she would tell a new volunteer that the system would never know to record.

These questions turn the coordinator into the additional mental model rather than a reviewer of model output. They expose the permission gate that actually governs the work.

When the product surface exposes those gates, the coordinator can act inside the tool instead of outside it. The next loop then forms around her actual authority rather than around the agent’s next suggestion. The model receives the new constraint as input instead of requiring a separate correction step after the fact.

This changes the retention metric from schedule views to schedule sign-offs that required no external fixes. It also changes the discovery process from periodic user interviews to continuous logging of the constraints the agent still cannot see.

The coordinator who closed the laptop at 9:47 p.m. was not resisting the agent. She simply could not complete her real job inside the product that claimed to help her.

The lattice that stops at the model boundary

The model boundary creates a clean edge that feels complete inside the training data. Outside that edge sit the family conflicts, last-minute illnesses, and unspoken trust relationships that determine whether a schedule actually works. Munger’s lattice requires the product to treat those external facts as first-class nodes rather than exceptions.

Teams that stop at the model boundary measure success by how often the agent produces a usable first draft. They miss the second and third loops where the coordinator must still exercise her real authority. The lattice stays incomplete, so the product keeps optimizing the wrong surface.

Extending the lattice means logging every override as a new signal instead of a user error. It means treating the coordinator’s final yes as the training target rather than an afterthought. The model improves only when the product makes those signals visible and actionable inside the same interface.

Question types that reveal the hidden keyholder

Most discovery sessions ask coordinators to evaluate the agent’s output quality. That framing keeps the model at the center. The better framing asks what constraint the coordinator protects that the model has no way to observe. The difference moves the conversation from preference to authority.

One effective question is to request the last three schedule changes she made after the agent finished its work. Each change points to a variable the model missed. Another is to ask which names she would never assign together even if availability and skills matched perfectly. The answer usually reveals a relationship or history the product has no field for.

These questions treat the coordinator as the additional mental model Munger described. They do not assume the model already contains everything worth knowing. They simply make the missing node visible so the product can decide whether to capture it or route around it.

Designing the next loop around the person who still owns the final yes

The final yes remains with the coordinator because she carries the accountability when the schedule fails. Products that hide the edit surface force her to perform that yes outside the tool. The next loop then starts from a place of correction rather than from the constraint itself.

Interfaces that expose the decision points let her record the constraint at the moment she applies it. The model receives the signal immediately and the schedule improves on the next run. Retention improves because the coordinator finishes her actual job inside the product instead of working around it.

The design choice is simple: every override or manual swap must be one click from the agent’s output. Anything more than that keeps the lattice broken at the model boundary. The coordinator who owns the final yes must be able to act on it without leaving the surface the product provides.

Your Turn: Apply This Today

• Schedule a 30-minute session this week with the actual coordinator who signs the volunteer schedule. Do not show her any agent output first.
• Ask her to list the last three manual changes she made after any automated draft and record the exact reason for each change.
• Ask her to name the one rule she applies that no current field in the system can capture, then write that rule down verbatim.
• Log the three constraints that appeared during the session and map each one to a specific place in the current agent flow where it remains invisible.
• Build a one-screen override panel that lets her record the constraint at the moment she applies it, then feed that signal back into the next model run.
• Measure the number of schedules that require zero external corrections after the panel is live and compare it to the prior four weeks.

The Permission Gate That Kept the Agent From Running the Schedule and The Context Window That Only Closed When a Real Coordinator Sat Down both trace the same pattern of authority that lives outside the model.

I consult with product leaders building agentic scheduling and coordination tools on exposing decision points, logging real constraints, and running discovery with the people who still hold the final yes. Let’s talk.

You’re looking at a finished lesson at 11:42 p.m. The model wrote the whole thing—story, questions, craft, even the verse the kids are supposed to memorize. It took less than a minute. The only person whose name actually goes on it is two states away until Friday, and she still has to read every line before anything leaves the building.

The question isn’t whether the output is good enough. It’s what happens when the person who carries the weight isn’t in the room when the thing gets made.

Solomon’s old test still works. The one who refused to let speed settle the matter was the one who actually had something to lose.

This is the foundational misread that causes product teams to treat approval as a routing problem instead of a knowledge problem. When the model runs ahead of the person who carries the cost, the output simply waits in a queue that no one has capacity to review. The 7-minute volunteer then inherits the risk.

At one children’s curriculum ministry the real retention metric was never download volume. It was whether the volunteer finished the lesson and used it without having to improvise under time pressure. The same constraint applies to any agent that generates curriculum or service copy. Fluency at generation does not reduce the need for the one human who can say, without looking at a screen, whether the content will land in the actual room.

Systems thinking applied to one physical signature

Systems thinkers map every handoff. The signature is the last handoff, and it is still physical. It happens on a printed sheet, a PDF markup, or a verbal confirmation after the staff member has read the full set of changes against the names and stories they know. Every upstream agent that assumes this step can be parallelized or batched will eventually produce work that sits idle until that one person is available.

The constraint is not reluctance. It is capacity. One person cannot absorb the volume the model can produce while also carrying the pastoral load that justifies their authority in the first place. The system must therefore reduce the surface area of what reaches the signature, not increase the speed at which drafts arrive.

This matches the logic in Solomon’s judgment. The decision was never about who could claim the child fastest. It was about who would still be responsible after the claim was settled. In product terms, the signature is the point at which responsibility is accepted. Design everything else to make that acceptance possible in the time the signer actually has.

When the dashboard score and the room decision diverge

Dashboards track completion rates, generation time, and version counts. None of them capture whether the final version was usable in the room where the volunteer stood. A lesson can score 94 on every automated check and still require the staff member to rewrite the closing prayer because the model used language the church’s particular tradition avoids. The dashboard will never register that mismatch.

The person who signs off holds the memory of previous rooms and previous failures. That memory is not stored in the model weights and cannot be queried through a prompt. When the dashboard and the signer disagree, the correct signal is the signer’s refusal, not the dashboard’s score. Treating the refusal as noise is how teams erode the very authority they claim to respect.

The pattern repeats across ministry tools. The coordinator who has led the same group for three years will reject a perfectly formatted schedule because she knows two families will be traveling. The model cannot hold that fact. The dashboard cannot weigh it. Only the signature step can.

Your Turn: Apply This Today

• Pick the single approval step that still sits outside every agent loop in your current workflow and write the exact handoff rule that tells the agent what information must reach the signer and in what format.
• Block two 30-minute slots on the signer’s calendar this week labeled only “review window” and instruct the agent to hold all output until those slots rather than pushing drafts as they finish.
• List the three facts the signer must know that the model cannot access (recent pastoral conversations, family situations, last-minute room changes) and create a one-paragraph template the volunteer or coordinator fills before the output reaches the signer.
• Remove any automated “ready for signature” notification that does not include the name of the person who will actually be in the room and one constraint that person has already named this month.
• Run the next generated artifact through the 7-minute test: open it on a phone, give yourself seven minutes, and note every line that would require the signer to stop and ask a question. Rewrite the handoff rule to surface those lines first.
• Document the last three times the signer changed an agent-generated draft and turn each change into a standing check the agent must run before it reaches the signature step again.

The Permission Gate That Kept the Agent From Running the Schedule and Why Ministry Coordinators Still Ask Me About the Routing Step both trace the same pattern: authority remains with the person who will still be present when the work is used.

I consult with product leaders building faith-tech tools and ministry leaders running volunteer workflows on approval gates, signature timing, and dashboard versus room decision alignment. Let’s talk.

I hit the wall on a Tuesday afternoon when the new volunteer coordinator tried to update a single field in our shared dashboard. The 12-factor checklist said everything should be environment variables and stateless processes. Her machine said she lacked the right role.

We had followed every rule. Twelve clean factors, deployed the same way for three years. Then one person who prints the schedule by hand stepped into the flow, and the whole setup stopped matching reality.

That gap isn’t a config problem. It’s the moment the framework runs out of road.

Where the factors stop at the coordinator’s desk

At one children’s curriculum ministry we once tried to route volunteer sign-ups through an agent built on the usual twelve-factor assumptions. The agent could read the database, write to the queue, and emit clean logs. It could not see that the coordinator kept the final printed sheet in a folder she carried in her purse until the night before the event.

The agent kept writing updates that the coordinator never saw because the update path ended at her email inbox. She checked the folder first. The factor that said “treat logs as event streams” did not account for the fact that the decisive log lived on paper.

Teams keep running into the same wall. They optimize the parts the agent can reach and leave the final decision point outside the model. The agent looks reliable until the first week the coordinator is out sick and no one else knows the folder exists.

Discovery loops that never reach the keyholder

Teresa Torres insists on talking to the people who will actually use or block the output. In most agent projects the loop stops at the ministry director who requested the tool. It never reaches the volunteer who must initial the printed list before it becomes real.

That gap shows up in the data. Completion rates drop the moment the agent output must cross from digital to the person holding the pen. The agent keeps generating correct JSON while the actual schedule remains unchanged for days.

Repeating the interview with the keyholder changes the shape of the work. The question shifts from “How do we make the agent faster?” to “What single artifact must the agent produce that the keyholder will accept without re-entering the data?” The answer is almost never another API call.

Rebuilding the harness around actual permission boundaries

The fix is not to add more factors. It is to map the exact sequence of approvals that already exists in the room and attach the agent only to the steps it can legally touch. At one church the agent now writes a draft to a shared folder, then waits for the coordinator to move the file into the approved subfolder. Only after that move does the agent send the confirmation text.

The same pattern appears when agents try to update sermon resource pages. The system can suggest a new children’s curriculum block, but the final publish button stays behind the editor who still reviews every image for age-appropriate content. The agent records the suggestion and the editor’s decision in the same log, so the next discovery cycle has real data instead of guessed intent.

Teams that rebuild this way stop measuring agent success by lines of code or number of API calls. They track how many handoffs complete without the coordinator having to re-type anything. That single metric forces the design to respect the permission gate instead of routing around it.

Your Turn: Apply This Today

• Pick one agent workflow you shipped in the last quarter and list every human who must approve before the output becomes visible to volunteers.
• Shadow the final approver for one full cycle this week and note exactly which artifact they check first when they sit down.
• Change the agent’s output destination so it writes only to the folder or inbox that person already opens without being asked.
• Remove the agent’s ability to push any change past that single gate until the approver has moved or signed the file.
• Log the time between agent suggestion and approver action for the next ten instances and compare it to the time the agent spent generating the suggestion.
• Bring that timing data to the next planning meeting and adjust the next agent task to reduce the gap by half.

The Permission Gate That Kept the Agent From Running the Schedule and Why Ministry Coordinators Still Ask Me About the Routing Step both trace the same pattern of agents that stopped at the first real handoff.

I consult with faith-tech product leaders on mapping agent workflows to permission boundaries and running continuous discovery inside existing ministry approval chains. Let’s talk.