AWS published a 31-minute talk in June called A leader’s guide to advanced team structures in an agentic world. It is aimed at CIOs, which normally means we skip it. This one is worth the half hour, because underneath the leadership framing it is an argument about how engineering teams should be shaped when agents do the execution — and it lands on a structure close to the one we already run. Here is the argument, the numbers it rests on, and the three places we would push back.

The framework

Four questions, answered in order: economics, talent, structure, governance. The order matters because the answers cascade — a talent decision made before you have answered the economics question is a guess.

Economics. The interesting claim here is what the speaker calls the pricing scissors: training costs rising roughly 2.4x per year while inference costs fall roughly 10x per year, so the gap between building a model and using one widens by 12–24x annually. The practical conclusion is a three-way split for every workflow — use a managed end-to-end solution, compose frontier APIs into your own context, or build and fine-tune your own models. Highest leverage and lowest differentiation at one end, highest control and lowest speed at the other.

The part people get wrong, per the talk, is treating this as an identity rather than a per-workflow decision. Declaring yourself a build shop on day one, before you understand your own workflows, is how a company burns itself training models it did not need.

Talent. The claim is that the valuable engineer is shifting from the person who builds fastest to the person who orchestrates fastest — points an agent at a problem, evaluates the output, steers the next iteration, and knows when to overrule. The talk maps this onto Martin Fowler’s expert generalist archetype from July 2025. That article names six traits — curiosity, collaborativeness, customer focus, a bias toward fundamentals over tool-specific knowledge, a blend of breadth and depth, and sympathy for adjacent domains. Hire for those, the argument goes, not for the framework of the year, which will turn over three times before the person’s first review.

Structure. Four org shapes, and only two of them work:

Shape	What it is	Verdict
Pyramid	Wide junior base, few seniors directing	Where most orgs are today
Diamond	Cut the juniors, thicken the management middle	The overreaction. The trap
Inverted pyramid	3–5 senior full-stack engineers, agents doing execution	Works — but has no learning path
Hourglass	Pods at the top, lean middle, juniors deliberately trained up	The org that houses the pods

The pod and the hourglass are not competing options; they operate at different altitudes. The pod is the delivery unit, the hourglass is the organisation that keeps producing people who can staff one.

Then the operating models, which is where the talk gets its banner line:

Model	Shape	When
A	Engineering builds, IT ops runs it	Dead. Runbooks are deterministic, agents are not
B	Embedded pod — you build it, you run it	Fine up to two or three pods
C	B plus a shared platform for runtime, identity, memory, observability	Past ~10 pods, duplication costs more than the platform

Model A fails for a reason worth naming: the operator debugging an agent at 3am did not write its system prompt and cannot see what it is actually doing. In model B, the person who wrote the prompt is the person on the pager. There is no context gap to close because there was never a handoff.

Governance. The talk points at Singapore’s Model AI Governance Framework for Agentic AI, launched by IMDA in January 2026 — the first state-backed framework written specifically for autonomous agents rather than AI generally. Four dimensions: upfront risk assessment, human accountability chains, technical guardrails across the lifecycle, and end-user transparency. Notably it mandates verifiable agent identity as a prerequisite, not a nice-to-have.

The architectural point underneath is the one to take away: policy is enforced outside the LLM loop. You do not ask an agent nicely not to do something. You stop the request at the gateway before the model ever sees it. Security owns the policy, engineering owns the agent, and the two are separable.

Where we disagree

The verification tax is the whole story, not one of four forces. The talk lists it as force three — code generated 10x faster is roughly 3x harder to validate — alongside the expert multiplier, the shifting bottleneck, and the deskilling trap. We would promote it. Every structural recommendation in the deck is downstream of whether you can cheaply tell good agent output from plausible-looking bad output. Get that wrong and the pod’s velocity is imaginary: you have moved the queue from writing to reviewing and called it a 10x improvement. This is the same argument we made about gating an agentic pipeline — the deterministic check downstream is what makes everything upstream trustworthy.

“If you can’t staff a senior-only pod, you’re not ready to build” is right, and unhelpful. For a small team the honest reading is: you are in compose for almost everything, permanently, and that is fine. The talk’s advice is calibrated for orgs choosing between ten pods and a platform team. At our scale the equivalent decision is which single workflow earns a pod at all, and the answer is usually none of them yet.

The hourglass is easy to endorse and hard to fund. The argument for protecting entry-level hiring is sound — the talk cites AWS CEO Matt Garman, who said in August 2025 that you “absolutely want to keep hiring kids out of college”, and makes the point that a 2034 expertise shortage is four CEO cycles away, so nobody currently in the chair has to own it. But agents eat precisely the junior-shaped work that used to be the training ground. Keeping juniors on the payroll does not by itself recreate the apprenticeship; the tasks they learned on are the tasks the agent now does in nine seconds. If you want the hourglass, you have to manufacture the learning deliberately — reviewing agent output with a senior, owning the gate, being the human in an accountability chain — rather than assuming a headcount line preserves it.

Takeaway

Pick one workflow. Decide whether it is use, compose, or build. If you are running model A and calling it DevOps, that is a transition plan, not a strategy. And before you count any of the speed gains, work out what your deterministic check is — because the only thing separating an agent pod from an expensive review queue is the gate on the other side of it.