Category Archives: Technical

Who Becomes Your Next Principal If Agents Do the Junior Work?

November 4 2026 Greg Fina Leave a comment

Over the years I have hired a lot of junior engineers. Some of my favorite moments as a leader were watching them grow: the first time one of them caught a bug I missed, the first promotion, and eventually the goodbye when they moved on to bigger jobs somewhere else. Every one of them climbed the same ladder. The bottom rungs were small features, bug fixes, and test coverage nobody else wanted.

These days I spend most of my time in customer meetings, and I find myself looking around the table and wondering about that ladder. The principal engineers are still there, sharp and opinionated. The junior engineers are there too, but I am less sure how they are getting the reps their predecessors got. Agents now draft most of that bottom rung work, and the data says those rungs are disappearing.

A Census Bureau Center for Economic Studies working paper found that early career employment in the most AI exposed industries fell 12% over the 10 quarters after ChatGPT launched, while less exposed industries stayed stable. The posting data rhymes: the share of tech jobs open to engineers with three years or less of experience fell from 43% in 2018 to 28% in 2024, according to Stanford Digital Economy Lab data summarized by HCAMag. It is tempting to read that as a 2026 hiring story. I read it as a 2031 principal story. The people who should be making staff and principal calls five years from now are the people we are not hiring, or not growing, today.

Be Honest About the Cause

Before we blame the agents, the hype check. Lambert and Schindler (2026) argue that remote work is a real confound. Distributed teams made mentoring harder and quietly made junior hires look riskier, and that shift started before generative AI was writing anybody’s code. HCAMag’s summary of the research puts it bluntly: the real reason junior hiring is collapsing may be your remote work policy.

I think both explanations are partly right, and I do not think it matters much which one wins the academic argument. The outcome for an engineering organization is identical. Fewer early career engineers are getting fewer reps on the kind of work that builds judgment. Whether the rep disappeared because an agent took it or because nobody was in the room to hand it over, the gap in your future leadership bench looks the same.

If you are a leader, that is the useful framing. You cannot fix macroeconomics or settle the remote work debate. You can decide how judgment gets built inside your own team.

What the Grunt Work Secretly Taught

Nobody designed the junior engineer curriculum. It emerged as a side effect of the work that needed doing.

Fixing a bug in a service you did not write taught you to read unfamiliar code, form a hypothesis, and test it against reality. Getting paged at 2 a.m. taught you what actually breaks in production, which is rarely what the architecture diagram suggested. Being wrong in code review, publicly and repeatedly, taught you to anticipate the objection before a senior engineer raised it. Writing the tests nobody wanted taught you where the edge cases live.

I saw this happen over and over with the engineers I hired. Nobody became senior because of one big project. They became senior because of hundreds of small, unglamorous fixes that each taught them something about how the system really behaved.

None of that was the point of the ticket. The ticket was “fix the null pointer in the billing job.” The lesson was how systems fail and how experienced people reason about failure.

When an agent drafts the fix, the ticket still gets closed. The side effect does not happen. We removed the work and, without noticing, removed the training program that was riding along with it. I wrote earlier this year that when building gets cheap, deciding gets expensive. The uncomfortable corollary is that we are making deciding more valuable at the same moment we are dismantling the pipeline that produced people who can decide.

The AI Drag Problem

The obvious response is “give the juniors agents too.” That is not a plan, and the evidence says it can make things worse.

Mark Russinovich and Scott Hanselman have described what they call AI drag, as covered in the InfoQ piece on the pipeline crisis. AI tools speed up senior engineers because seniors can steer the model and verify the output. The same tools can slow down juniors, who cannot yet tell a plausible answer from a correct one. A senior reads a generated diff and spots the race condition. A junior reads it, sees green tests, and ships.

I see a version of this in customer meetings. When a design question comes up, the principal engineer in the room usually asks the question that matters: what happens when this fails, who owns it, what does it cost at ten times the load. The junior engineers often have the generated answer ready faster than anyone, but they are not yet the ones asking that question. That gap is not about talent. It is about reps.

Blazity’s analysis of whether coding agents can replace junior developers lands in a similar place: agents can produce junior level output, but they do not produce junior level growth. Handing juniors an agent and walking away widens the gap between the people who already have judgment and the people who need to build it.

Build Judgment on Purpose

If the side effect is gone, the curriculum has to become explicit. Here are four practices I would put in place, each of which uses agents rather than pretending they do not exist.

1. Verification rotations

Make juniors the owners of verification for agent output. They write the evals, review the agent generated pull requests, and sign off on whether the change is correct. A senior engineer cosigns. The junior is no longer writing the fix, but they are doing the harder cognitive task: deciding whether a fix is actually right and explaining why. That is exactly the skill AI drag says they lack, so train it directly.

A simple rotation looks like this:

verification_rotation:
  owner: junior_engineer
  cosigner: senior_engineer
  duration_weeks: 2
  responsibilities:
    - write_or_extend_evals_for_agent_tasks
    - review_agent_prs_with_written_rationale
    - log_one_caught_defect_per_week
  exit_criteria: cosigner_agrees_on_90_percent_of_calls

2. Incident ownership

Put juniors on call early, in shadow mode, then have them lead the postmortem for an incident they shadowed. Agents can summarize logs, but leading a postmortem forces someone to build a causal story, defend it in front of peers, and propose a change that will survive scrutiny. That is principal work in miniature.

3. Design review apprenticeships

In every design review, assign a junior to write the “alternatives considered” section, especially the rejected options, and defend it live. Explaining why you did not choose an approach is where architectural judgment actually forms. It is also work an agent can draft but cannot own, because the defense happens in the room.

4. Incentives that count judgment

If your promotion packet still rewards PR volume, you are promoting people for the work agents now do. Count architecture decision records, evals that caught real defects, postmortems led, and design alternatives defended. Guillermo Power makes a related argument about what might actually work: the organizations that keep growing talent will be the ones that change what they measure.

None of these practices is expensive. Each one costs senior time, which is the point. Senior time spent growing judgment is the investment; agents are what free it up.

A Test for Principals

Before you set 2027 headcount, try one exercise: list every engineer with less than three years of experience on your team and write down the last time each of them owned a decision that could have gone wrong. If that list is short or empty, the agents aren’t the problem. The problem is that nobody is designing the pipeline.

The agents will keep getting better at junior work. Whether anyone gets better at principal work is still up to us.

Technical,Teams,GenAI,Architecture

The Principal's Filter: Sorting Agent Hype from What Ships

October 7 2026 Greg Fina Leave a comment

Last month a customer walked me through a slide deck with eleven “agents” on it. By the end of the hour we had found one real agent, three workflows, two chatbots, and five ideas that nobody had scoped yet. Nobody in that room was being dishonest. The word “agent” has simply stretched to cover almost anything with a model behind it.

That is the real job of a principal right now. Customers do not need another person cheering for agents. They need someone who can sort what is viable from what is not, then help them build the right thing, which is sometimes an agent and often is not.

Why This Matters Now

The gap between buzz and production is wide. A Gartner 2026 CIO survey found that only 17% of organizations have deployed agents, while more than 60% expect to within two years. The Sinequa State of Enterprise Agentic AI 2026 report is even more sobering: only 24% have deployed a true agent, and only 10% have true agentic capabilities. Gartner also forecasts that more than 40% of agentic AI projects will be canceled by the end of 2027 because of rising cost, unclear value, and weak risk controls.

Notice what is missing from that list: model quality. In my experience, most agent projects do not fail because the model is weak. They fail because of how they are governed and run. The value was never clear, the costs crept up, the risk controls were thin, and nobody was assigned to manage the agent once it went live.

So I use a filter. Five questions, asked early, before anyone writes a line of orchestration code.

Filter 1: Is It Really an Agent?

The industry now has a name for the relabeling problem: agent washing. Chatbots, assistants, and RPA tools are being renamed as agents, and buyers are paying agent prices for them.

My test is simple. A real agent does three things:

Plans. It breaks a goal into steps it was not explicitly given.
Uses tools. It calls APIs, queries data, or takes actions in other systems.
Acts on its own. It decides the next step based on what it just observed, without a human or a fixed script choosing for it.

If the steps are known in advance, you have a workflow. Build it as a workflow. A state machine with a model call in one or two steps is cheaper, easier to test, and easier to explain to an auditor. I tell customers this is not a downgrade. It is the correct design.

Fixed steps, known branches   -> Workflow (Step Functions, plus a model call)
Answer questions, no actions  -> Assistant / RAG
Repetitive UI clicks          -> RPA
Open ended goal, tool choice  -> Agent

Filter 2: What Happens When It Fails?

Every agent demo works. That is what demos are for. The question is what happens on day thirty when the input looks different. Agents that shine in demos break on new input formats, loop on vague instructions, or quietly make up data. The last one is the dangerous one, because a confident wrong answer does not trigger an alarm.

I ask the team to describe three failure paths out loud:

Catching it. How do you know the agent failed? Schema validation on outputs, checks against a system of record, and confidence thresholds that route to a human.
Containing it. What is the blast radius? Scoped credentials, read only access by default, step and spend limits per task, and an approval gate before any irreversible action.
Recovering from it. Can you replay the trace, see which tool call went wrong, and roll back what the agent did?

If the answer to any of these is “the model is pretty good, so it should be fine,” the project is not ready.

Filter 3: Can You Measure and Test It?

You cannot improve what you cannot measure, and you cannot ship what you cannot test. Before production, I want to see an evaluation suite built on the customer’s real edge cases, not the vendor’s happy path examples.

A useful starting point is fifty to two hundred real tasks pulled from tickets, logs, or past work, each with a known good outcome. Run the agent against them on every prompt change, model change, and tool change. Something as plain as this works:

results = []
for case in eval_cases:
    outcome = agent.run(case["input"], max_steps=15)
    results.append({
        "id": case["id"],
        "passed": grade(outcome, case["expected"]),
        "steps": outcome.step_count,
        "cost_usd": outcome.cost_usd,
    })

pass_rate = sum(r["passed"] for r in results) / len(results)
print(f"pass rate: {pass_rate:.1%}")

Then carry the same idea into production. Sample live traces, grade them, and track pass rate, step count, and escalation rate over time. Offline evaluation tells you whether to ship. Production monitoring tells you when to stop.

Filter 4: What Does Each Completed Task Cost?

Token pricing is the wrong unit. Customers get excited about a fraction of a cent per call, then discover that one finished task took nine calls, two retries, a reasoning loop, and fifteen minutes of a person checking the result.

The number I ask for is cost per completed task:

cost per completed task =
  (model calls + tool calls + retries + loops
   + infrastructure + human review time)
  / tasks completed correctly

The denominator matters as much as the numerator. If the agent completes 70% of tasks correctly, the other 30% still cost money and still need a person to finish them. Compare the result to what the work costs today. If the agent is not clearly cheaper, faster, or better at the same quality bar, the value case is not there yet. This is exactly the “rising cost, unclear value” pattern behind those cancellation forecasts.

Filter 5: Who Manages It Once It Is Live?

This is the question that kills the most projects, and the one teams skip most often. An agent is not a feature you ship and forget. It behaves more like a new team member who needs a manager.

Someone has to:

Define the work. What tasks are in scope, and which are not.
Set the quality bar. What counts as done, and what error rate is acceptable.
Step in when things go wrong. Review escalations, pause the agent, and fix the prompt, tools, or data.
Own the evaluation suite. Add new edge cases as production reveals them.

I ask for a name, not a team. If no single person owns that job, with time actually allocated to it, the project is not viable, regardless of how good the demo looked.

Practical Takeaways

Classify before you build. Label every proposed “agent” as a workflow, assistant, RPA, or agent. Most will not be agents.
Write the failure paths first. Catch, contain, and recover, documented before the first sprint.
Build the evaluation suite from real data. Use the customer’s edge cases and rerun it on every change.
Price the finished task, not the token. Include retries, loops, and human review.
Name the owner. No operational owner, no production launch.

Saying “Not Yet” Is the Job

Principals earn trust by being the person in the room willing to say “not yet,” or “a simpler build will work better.” Customers remember who saved them from an expensive cancellation far longer than who sold them the shiniest demo.

And when the filter says an agent really is the answer, the right primitives exist. As I wrote in Agents Aren’t Web Requests, agents need runtimes built for long running, stateful, isolated work. Get the governance right first, and the infrastructure part becomes the easy part.

What questions are in your filter? I would like to hear what you ask customers before you let an agent near production.

Technical,Teams

When Building Gets Cheap, Deciding Gets Expensive - The New Engineering Bottleneck

October 1 2026 Greg Fina Leave a comment

When I led development teams, I always believed that the ability to build was our edge. Give the team room and flexibility and we could make almost anything ourselves. But building was never the real question. Every serious feature came down to build versus buy, and the deciding factor for me was always the same: was this core business logic that actually differentiated us? If it was, we built it and owned it. If it was not, buying was almost always the smarter call. What has changed is not that logic. It is that the cost of building has fallen so far that the temptation to build everything is stronger than ever, even when it is not the right decision.

Last month I watched a mid level engineer stand up a working service in about forty minutes. Authentication, a REST layer, input validation, a test suite, and a passable README. Two years ago that was a sprint. What struck me was not the speed. It was the silence in the room afterward, because the hard conversation had not even started. Should this service exist? Should it own that data? Was REST the right call, or did we just build the thing the assistant was fastest at generating?

That gap between “we can build it” and “we should build it, this way, now” is where engineering work is quietly relocating. For most of our careers, implementation was the expensive part. That assumption no longer holds, and a lot of team design is built on top of it.

The old bottleneck is collapsing

The cost of turning an idea into running code has been falling for a long time. High level languages, package managers, cloud primitives, and copy paste from the wider internet all chipped away at it. AI coding assistants and agentic workflows have turned that slow decline into a cliff. A prototype that used to take a week takes an afternoon. A one off migration script that used to take a day takes ten minutes.

When you cut the price of something dramatically, you get more of it. Teams are now generating more candidate implementations, more branches, more prototypes, and more “what if we just tried it this way” experiments than ever before. That is genuinely good. Cheap building means cheap exploration.

But cost does not disappear. It moves. And it has moved to the one part of the pipeline that no assistant has automated away: deciding.

When building gets cheap, deciding gets expensive

Consider what actually happens now when a team picks up a feature. The assistant can produce three plausible designs before lunch. Now someone has to choose. Which data model do we commit to? Do we accept the coupling this introduces? Is this a change we can walk back next quarter, or are we about to bake it into a public API that a dozen downstream teams will build on?

Those questions were always there. What changed is their share of the total effort. When building was 80 percent of the work, deciding was a rounding error you could absorb in a hallway conversation. When building drops to 20 percent, deciding becomes the main event, and most teams have no process for it beyond that same hallway conversation, now hopelessly overloaded.

This is the shift in one sentence: the scarce resource is no longer the ability to produce a working artifact. It is the judgment to know which artifact is worth keeping and what it commits you to.

Why decisions are now the constraint

Three forces make decisions the binding constraint rather than just a cost that grew.

More options per unit time. Every generated alternative is a decision you now owe. Ten prototypes is not ten times the progress. It is ten times the deciding, and deciding does not parallelize the way generation does. A single senior engineer or architect becomes the queue that every branch waits in.

Decision debt compounds quietly. We talk endlessly about technical debt. Decision debt is worse because it is invisible until it detonates. It is the accumulation of choices made implicitly, by default, or by whoever’s code got merged first. When building was slow, the pace of code creation throttled how fast you could accrue this debt. Remove the throttle and you can bury a team in unexamined commitments in a single quarter.

Alignment becomes the real work in progress. Watch where things actually stall today. Rarely at the keyboard. Usually in the review queue, the design doc waiting for comments, the Slack thread where three staff engineers disagree about an approach and nobody owns the tiebreak. That is decision latency, and it is now the dominant term in your cycle time.

What good looks like

The teams pulling ahead are the ones treating decision making as a first class engineering discipline, not an afterthought. A few patterns are doing real work.

Classify the door before you walk through it. The most useful frame I know separates reversible decisions from irreversible ones. Cheap to reverse? Do not convene a committee. Let an engineer pick, ship, and learn. Expensive or impossible to reverse, like a public API contract, a data retention model, or a security boundary? That earns real deliberation. The failure mode I see most is teams applying heavyweight process to reversible choices and no process at all to the irreversible ones. When building is cheap, most decisions become more reversible, which means you should be pushing far more of them down and out.

Write the decision down, lightly. A short architecture decision record captures the context, the options, the choice, and the tradeoff accepted. Two paragraphs beats a forty page design doc nobody reads. The point is not ceremony. It is that six months from now, when someone asks “why is it like this,” the answer exists and does not require archaeology. In a world where the code was half generated, the reasoning behind it is the artifact worth preserving.

# ADR 042: Event sourcing for the ledger service

Status: Accepted
Context: We need an auditable history of balance changes.
Decision: Append only event log as the source of truth.
Tradeoff accepted: Higher read complexity now, in exchange for
  a complete audit trail we cannot reconstruct later.
Reversibility: One way door. Revisit only with a migration plan.

Assign the owner, not the committee. Every consequential decision needs a name attached, someone accountable for making the call and living with it. Consensus feels safe and is usually just diffused ownership. Fast teams name a decider, gather input on a clock, and move.

Attack decision latency directly. Measure how long a design sits in review. Put a timebox on it. Make “we decided” a visible event, not something that emerges by attrition when the loudest person tires out.

Implications for technical leaders and topologies

If deciding is the new bottleneck, the job of a technical leader changes. The highest leverage senior person on a team used to be the one who wrote the trickiest code. Increasingly it is the one who makes the tricky calls fast and well, and who builds the machinery for the rest of the team to do the same.

That means leaders shift from code reviewers to decision enablers. Reviewing every line does not scale when the line count explodes. What scales is establishing the guardrails, the defaults, and the patterns that let engineers decide safely on their own. Think guardrails over gatekeeping. A paved road that makes the safe choice the easy choice removes a thousand small decisions from the queue before they ever form.

It also means we invest deliberately in judgment and taste, the things assistants do not have. Knowing that the elegant abstraction is premature. Sensing that a dependency will hurt in a year. Feeling when a design is too clever. That intuition is now the differentiated skill, and it is developed by giving engineers real decisions to own early, then reviewing the outcomes together.

The edge is decision velocity and decision quality

The comfortable metric for a decade was output. Story points, PRs merged, features shipped. When output was expensive, output was a fine proxy for progress. It is not anymore. A team that generates twice the code but takes three weeks to decide what is worth keeping is slower than a team that generates half as much and decides in a day.

The competitive edge is moving to decision velocity multiplied by decision quality. Deciding fast, deciding well, and knowing which decisions deserve which level of care. Building is nearly free now. What you choose to build, and who gets to choose, is the whole game.

Further reading worth your time: the reversible and irreversible decisions framing, Michael Nygard’s original ADR write up, and the Team Topologies material on cognitive load and team design.

Technical,Teams

Do Agents Eat Pizza? Rethinking Amazon's Two Pizza Team When Half the Team Is Autonomous

September 23 2026 Greg Fina Leave a comment

Here is a question worth sitting with before your next org review: if you gave every engineer on a team a coding agent that never sleeps and writes most of the first draft, would you make the team smaller, or would you keep it the same size and hand it a bigger charter? Most leaders answer “smaller” on reflex. That reflex is expensive, and it misreads what the two pizza team was ever for.

The two pizza team is Amazon’s most exported piece of org design, and it is about to be its most misunderstood. As agents absorb a growing share of the keyboard work, the temptation is to shrink the roster to match. But the rule was never counting mouths at the table. It was counting something harder to see.

The rule was always a proxy

The origin story is well worn. At a 2002 retreat, when managers asked for more communication, Jeff Bezos reportedly shot back that “communication is terrible” and restructured the company around small autonomous teams — small enough to feed with two pizzas. The number, five to eight people, was never the point. It was a proxy for two things that actually mattered.

The first is communication overhead. Coordination cost grows faster than linearly with headcount; every person you add multiplies the channels that must stay in sync. Capping team size caps that overhead. The second is single threaded ownership: a team small enough to hold one coherent mission in its collective head, accountable end to end for a product it can build, ship, and operate without passing work across departmental fences.

Underneath both proxies sits the real binding constraint: cognitive load. A team can only hold so much of a domain in its head before delivery slows, quality drops, and people burn out. The two pizza rule was a crude but durable way to keep one team’s cognitive budget from overflowing. Read it that way and the agent question sharpens immediately. Agents don’t change whether the rule applies. They change what the rule is measuring.

What agents actually change

At the Pragmatic Summit, Martin Fowler framed the fork precisely: “Are we seeing two pizza teams becoming one pizza teams because agents don’t eat pizza, or do we see two pizza teams staying and becoming much more effective and capable? My bet is on more effective two pizza teams.” (Hands-On Architects)

It sounds like a headcount question. It is really a question about where the load goes. Here is the mechanism that resolves it: an agent relocates cheap cognitive load and returns expensive load. The boilerplate, the glue code, the first draft implementation, the codebase spelunking — all the work that was tedious but not hard — moves to the agent. What flows back to the humans is the work that was never cheap: verification, integration, and judgment. Someone still has to decide what to build, review what came back, and own the call when the agent cannot make it.

Kent Beck, on the same stage, put the brake on the naive reading with four words: “AI is an amplifier.” An amplifier does not subtract band members; it changes what each one carries. He described pairing with an agent and, counterintuitively, praising its slowness — the three minute gaps where the humans talk about naming, about conditionals, about what they should be doing next. “The genie generates; the humans verify and steer.” That gap is not idle time. It is the irreducible work.

This is why “green tests, therefore correct” is not verification when the same agent wrote the tests. The expensive load doesn’t disappear because output got cheaper. It concentrates. Same forty hours, every line item moved: less hand writing code, far more reviewing, integrating, and keeping the specs and context current enough that next week’s drafts stay trustworthy.

Amazon is living this in real time

The most striking evidence comes from Amazon itself, which is running the experiment on its own traditions. When AWS carved out an agentic AI division, VP Swami Sivasubramanian deliberately reorganized it back to two pizza teams — the principle much of the 1.5 million person company had outgrown. His reasoning: projects that once required 30 to 40 people can now be done by teams of six to eight. (GeekWire)

The receipts are concrete. Amazon Quick — the desktop app that connects email, calendar, Slack, and documents into one AI workspace — was built by about six engineers and shipped in three months. The team wrote the classic PRFAQ after the product was already in beta, because building the demo had become faster than writing the six page narrative. Internally, a rebuild of the Bedrock inference engine was done by six engineers in 76 days, a project originally scoped at 30 developers over 12 to 18 months.

Notice what did not happen. The team did not shrink. Six to eight people is squarely a two pizza team. What changed is the charter: the same size team now owns a mission that used to need five times the roster. Sivasubramanian frames it exactly this way — the same number of people pursuing a bigger charter. And the roles inverted along the way: product managers write code, engineers make product calls. His own hard won lesson underlines where the weight moved. Rebuilding an old replication engine with an agent, he spent four frustrating nights babysitting output until he realized he had never given the agent the tools to test itself. Once he wrote the right spec and testing environment, it finished in two hours. “The bottleneck is not about the time it takes to build something. The bottleneck is about crafting the right specification and the tests.”

That is the whole argument in one executive’s mouth. The scarce resource is human judgment applied to specs, tests, and verification — not hands on keyboards.

The one pizza counterargument, and why it’s the exception

An honest post has to steelman the other fork. Mimacom argues for the one pizza team: two to three product builders orchestrating an agent layer, owning a full value stream, yielding roughly a 60% reduction in team size per product. Every goes further with the “two slice team” — one person per product. Dan Shipper runs four products with four people; Monologue, at 143,000 lines, is written almost entirely by one engineer with agents. These are real products, not weekend demos.

The counterargument is correct about something important: for greenfield products with a homogeneous stack and a clear owner, execution capacity really has stopped being the constraint, and a single builder can now own what used to take a squad. But look closely at how those organizations sustain it. Every doesn’t actually run solo teams — it surrounds them with internal agencies, floating designers, and freelance senior engineers who “dip in and out” on the hairy problems agents fumble. The load didn’t vanish. It got pushed to a shared layer around the solo builder. And the deep specialist work — the tacit, hard to verify knowledge — remains stubbornly human. The one person team is what the two pizza team looks like when you only count the person at the counter and ignore the kitchen behind them.

How to redefine the rule

Stop sizing teams by headcount. Size them by two things: bounded cognitive load and human verification capacity.

Treat agents as first class team members that expand throughput but concentrate the human work into judgment, spec writing, and review. The team number may well hold — five to eight is still a reasonable ceiling for coherent ownership — but its composition inverts: fewer hands writing code, far more expensive judgment per human.

Here is a reframe you can apply at your next org review, in four questions:

Whose cognitive load does this team reduce, and what load flows back? Run every team through it. If nothing flows back, you have miscounted.
Can this team pay for its returned load? A team can only get leaner if it can afford the verification, integration, and judgment the agents hand back. If it cannot, you get the same humans and less agent trust.
Is the charter growing to match the throughput? Falling execution cost should buy a bigger mission, not just a smaller roster.
Where does tacit specialist knowledge live? That work is the least changed by agents. Draw your boundaries to protect it, not dissolve it.

The two pizza team survives the agent era. It just stops being a rule about pizza. Do agents eat pizza? No — and that’s exactly why the number of pizzas was never the thing to measure. The right unit was always the load the team can carry and verify. Size for that, and the table sets itself.