Blog

The pattern shows up across AI product teams often enough to be a rule of thumb: the bigger the product team gets, the harder it becomes to say who actually owns a given model’s behavior once it starts making decisions in production. Larger teams launch more pilots. They also let more of those pilots quietly change shape or get replaced within six months, because no single person feels required to own the fix or the rollback.

The surface reading suggests bigger teams handle complexity better. The actual pattern runs the opposite direction: added headcount spreads the cost of a bad agent outcome across so many people that no one feels required to own the fix or the rollback.

This is the foundational misread that causes product teams to treat team size as a proxy for readiness. Solomon’s judgment between the two mothers exposes it cleanly. One woman was willing to divide the child to settle the claim; the other refused because the living outcome mattered more than preserving her portion of the arrangement. The test was not how many people stood around the throne. It was who would accept a smaller claim to keep the real thing intact.

Why adding more PMs masks the places where ownership is missing

When a team grows past five or six product managers, the first thing that disappears is a single point of accountability for any one model behavior. Someone owns the prompt layer, another owns the retrieval pipeline, a third owns the evaluation dashboard. Each can point to their slice when the agent produces a wrong recommendation or drifts on a key metric.

The result is a steady increase in meetings that review outputs without changing the underlying decision logic. In one children’s ministry curriculum platform I watched, the team added four product managers after an initial AI summarization feature went live. Within eight weeks the feature was generating summaries that flattened the theological tone volunteers relied on. No single person had the authority to pause the model while the retrieval set was rebuilt, so the feature stayed on for another two months while the group negotiated scope.

Solomon’s test still applies. The teams willing to shrink their own headcount or cut a feature entirely are the ones that keep the outcome alive. Everyone else negotiates around the damage.

The inference cost that forces real tradeoffs no headcount chart can hide

Inference spend does not scale with team size. It scales with the number of decisions the model is allowed to make without human review. A team of twelve can approve ten times the volume of experiments, but each additional experiment still consumes tokens at the same rate once it reaches users.

I have seen mid-size product groups run out of budget on low-stakes queries because no one held the mandate to turn the temperature down or restrict the context window. The headcount chart looked healthy. The actual constraint was a monthly inference bill that no single owner could defend or reduce. The smaller teams I have worked with hit the same cost wall earlier and therefore made the tradeoff sooner, usually by narrowing the agent’s scope rather than adding another reviewer.

The mother who would not let the child be divided understood that half a living outcome is not an outcome worth preserving. Larger teams rarely face that same clarity because the cost is distributed across multiple budgets and multiple roadmaps.

How minimal teams learn faster because every person feels the full weight of a bad agent decision

A three-person product team shipping an agent that recommends volunteer curriculum cannot hide from the result. When the model suggests the wrong passage or the wrong age range, the same three people see the support tickets, the churn data, and the angry emails the next morning. There is no layer of analysts or coordinators between the decision and its consequence.

That direct exposure accelerates two kinds of learning. First, the team stops shipping marginal improvements that add inference cost without measurable outcome lift. Second, they develop sharper instincts for when to keep the model out of the loop entirely. Larger teams can staff an entire workstream around monitoring drift without ever feeling the same pressure to change the model or remove it.

The pattern shows up consistently: teams under five product managers who ship live agents tend to revise their decision boundaries within a week or two of a measurable regression, while larger teams often take much longer and usually add another reviewer instead of tightening the original logic.

Your Turn: Apply This Today

• List every model decision that reached production in the last 30 days and name the single person who can pause it without a meeting.
• Calculate the inference cost per active user for each agent you shipped this quarter and mark which ones exceed the original estimate by more than 30 percent.
• Identify the last three agent regressions that produced user-visible errors and note how many product managers were involved in the fix versus how many were involved in the original launch.
• Remove one recurring review meeting that exists only because multiple people own adjacent parts of the same model behavior.
• Run a one-week test where the smallest possible team (three or fewer) owns the next agent change from prompt to production without additional reviewers.
• Write down the specific outcome metric that would cause you to turn the model off entirely rather than add another person to monitor it.

The same ownership gap shows up in The Agent That Kept Running the Schedule While No One Was Watching, where distributed responsibility let a bad outcome run unchecked.

I consult with product leaders on AI shipping decisions, team ownership structures, and inference tradeoffs that surface only after models reach production. Let’s talk.

The cursor on the screen paused mid-sentence as the founder typed out yet another requirement for the senior product role. Across the open office, the three engineers who had already started building the internal workflow tool sat at their desks, trading pull requests in the quiet that followed the afternoon standup. One of them pushed a commit that solved the exact coordination problem the job post still described as a future deliverable.

That afternoon the founder sent the draft to three recruiters. None of the engineers in the room knew a posting existed.

The pattern repeats across faith-tech teams that treat hiring as a search for an external solution rather than a scan of existing capability. The six weeks spent refining language could have been spent mapping who already carried the right combination of constraints, incentives, and mental models for the work. Posting first assumes the right person arrives from outside; mapping first reveals whether the right person is already inside and simply lacks the invitation to own the problem.

Charlie Munger’s latticework of mental models supplies the lens. Munger argued that real judgment comes from holding multiple models at once, opportunity cost, inversion, circle of competence, and second-order effects, rather than relying on any single framework. Applied to talent, the latticework turns a job description into a filter that often excludes the people whose existing models already match the constraints of mission-driven work.

The map that made the posting unnecessary

In one case the internal tools team had already shipped a lightweight volunteer scheduling system that reduced administrative load by half. The system addressed the exact friction the senior PM role was meant to solve. The engineers had built it on nights and weekends because they saw the gap every Sunday. When leadership finally posted the role, two of those engineers applied internally and were told they lacked “enterprise-scale experience.”

The latticework reveals the mistake. Inversion asks what would have to be true for the current team to already hold the solution. Opportunity cost asks what six weeks of posting and interviewing actually consumed. Circle of competence asks whether the posted requirements matched the narrow domain the engineers already navigated daily. The answers pointed to an existing operator rather than an external hire.

How Munger’s models reveal hidden operators

Munger’s second-order effects model surfaces people who anticipate downstream consequences others miss. In one children’s ministry platform project, one engineer consistently flagged that new features would increase volunteer prep time on Saturday nights. That single observation shaped the entire release cadence more than any product requirement document. The engineer never held a PM title, yet the model lived in his work.

The latticework also surfaces people who apply inversion naturally. Another engineer started every planning conversation by asking what would break if the feature shipped tomorrow. That habit exposed edge cases in global rollout that later became the difference between a tool used in three countries and one used in forty. These operators already carried the mental models the role was meant to import.

Turning the same practice toward regulated industries

The same mapping approach travels to regulated spaces where compliance and mission constraints intersect. One health-tech team mapping internal talent found a data analyst who had already built audit trails that satisfied both HIPAA and the ministry’s reporting needs. The analyst had done the work quietly because the existing vendor tools created reporting gaps every quarter. Posting a compliance PM role would have repeated the six-week cycle while the solution already sat inside the team.

Regulated environments reward people whose models already account for constraint density. Munger’s circle of competence model makes this visible: the analyst’s competence was not in writing job descriptions but in operating inside overlapping rule sets. Mapping surfaces that competence before a posting buries it under generic requirements.

Your Turn: Apply This Today

• List every current project that lacks an owner and note which three people have touched the work in the last month even without a title.
• For each person, write the two mental models they already demonstrate in their existing output rather than the skills they list on a resume.
• Run a ten-minute conversation with those people asking what constraint they would remove first if they owned the problem tomorrow.
• Compare that answer against the last job description you posted and strike every requirement that does not match an observed model.
• Invite the strongest internal match to scope the role for thirty days before any external search begins.
• Document the second-order effects they already track and use that list as the actual success criteria for the work.

The same latticework that exposed the engineers also explains why internal mapping consistently outperforms external posting in mission-driven settings. Related posts cover how inversion changes product roadmaps and why mental models matter more than titles when teams scale.

I consult with faith-tech product leaders on talent mapping, mission-constrained hiring, and applying mental models to team structure. Let’s talk.

The children’s ministry coordinator stood at her kitchen island, phone propped against a mixing bowl, three voice agents already open in separate tabs. One agent suggested reassigning the early service volunteers based on last month’s no-shows. Another pulled from a different calendar and offered nursery coverage that overlapped with the worship rehearsal. Her four-year-old kept reaching for the device while the third agent read back conflicting confirmation times.

She answered each one in turn, trying to keep the threads straight without writing anything down. The kitchen timer went off for the casserole. She silenced it with her elbow and kept typing.

This scene shows what happens when parallel tools arrive before anyone has settled the actual order of importance. Ministry leaders already juggle multiple calendars, last-minute absences, and family interruptions. Adding more agents does not reduce that load. It simply splits the same decisions across more channels that never talk to each other.

Seneca wrote his letters to Lucilius with one clear rule: correspondence should clarify a single line of thought, not multiply open questions. He answered one matter at a time and expected the recipient to do the same. When agents run side by side without that discipline, they recreate the exact problem Seneca tried to avoid—scattered attention that never lands on what matters most.

What the phone scene revealed about how ministry leaders already manage overload

The coordinator already tracked volunteer commitments in her head, on a paper list taped to the fridge, and in a shared spreadsheet someone updated twice a week. None of those systems spoke to each other, yet she had built workarounds over years of Sunday mornings. The agents did not replace those workarounds. They added three new ones that still required her to decide which answer counted.

Most ministry leaders operate the same way. They absorb interruptions, reconcile conflicting data, and protect the one or two outcomes that cannot slip. When a new tool appears without first asking which outcome owns priority, it simply increases the number of places the leader must reconcile the same facts.

The real cost shows up in completion rate. Volunteers who receive three different messages about the same shift stop responding. The leader then spends the next evening manually fixing the confusion the agents created. The metric that matters—whether the volunteer actually shows up—drops even as activity in the agents rises.

The guardrail that turns parallel agents from noise into clarity

Seneca’s practice gives the guardrail: designate one owner and one outcome before any agent starts work. The coordinator needed to decide first which service or role mattered most that weekend. Only after that decision could an agent act without creating new conflicts.

In practice this means the product sets a single visible owner for the workflow. That owner states the priority in plain language before the agent runs. The agent then operates inside that boundary and surfaces only the exceptions that fall outside it. Everything else stays closed until the owner reviews the result at a fixed time.

Without the boundary the agents keep generating suggestions. With it they finish one narrow task and stop. The coordinator can then move to the next priority instead of spending the evening untangling three separate threads.

Why product teams shipping voice agents keep rediscovering the same coordination failure

Teams building these agents often measure success by how many tasks the agent can start. They track number of sessions, number of suggestions offered, or number of tabs left open. None of those numbers reveal whether the underlying outcome was achieved or whether the leader had to spend extra time cleaning up the mess.

The pattern repeats because the teams treat coordination as a technical problem of connecting data sources. It is actually a priority problem. Until the product forces a single owner and a single outcome to be named first, additional agents only multiply the places where decisions remain unresolved.

Seneca would have recognized the failure immediately. More letters do not produce clearer judgment if each letter raises new questions without settling the previous ones. The same holds for agents. The volume of activity is not the measure. The clarity of the final assignment is.

Your Turn: Apply This Today

• Pick one narrow workflow that currently runs across multiple agents or tabs and name the single outcome that matters most this week.
• Assign one explicit owner who will receive every agent output and decide what counts before any other step begins.
• Set a hard stop time of fifteen minutes for the agent run and require the owner to close the workflow at that time regardless of remaining suggestions.
• Remove the other agents or tabs from view during that fifteen-minute window so the owner works inside the declared priority only.
• Record whether the volunteer or task actually completed after the single-owner run and compare it to the previous week’s results.
• Repeat the same constrained workflow next week with the same owner and stop time before adding any new agent capability.

The same single-owner discipline is the fix in The Agent That Kept Running the Schedule While No One Was Watching, where a missing checkpoint let a scheduling agent act on stale context.

I consult with product leaders building agent tools for ministry contexts on single-owner workflow design, priority guardrails, and completion-rate measurement. Let’s talk.