Summary: Microservices were never a technological answer — they were an answer to the human cognitive limit. In 2026 the team includes someone who reads a hundred files in five seconds but has a different bottleneck: the context window. The modular monolith — one deployment artifact, domain boundaries enforced by the compiler — becomes the optimal environment for an AI agent, because the agent gets a coherent map of the whole domain in one repository instead of hallucinating about what neighboring services do.

The core insight

When a team grows to ~200 engineers, no single brain covers the whole business domain, so you divide it into bounded contexts and physically isolate them into processes. That worked for Amazon and Netflix because they had the organizational scale that demanded it. The industry then copied the architecture without copying the conditions: companies with 80 engineers adopted a pattern designed for 2,000, ignoring Conway's Law. The same failure appeared every time — synchronous coupling, exploding costs, an unmaintainable dependency graph.

The architecture pendulum (2015–2026)

  • 2023 — Prime Video: Marcin Kolny's team hit a hard scaling limit at 5% of expected load on Step Functions + Lambda; consolidating into a single EC2 process cut infrastructure costs by more than 90%. Werner Vogels responded with "Monoliths Are Not Dinosaurs" — revisiting architecture is an obligation, not a religion.
  • 2025 — CNCF: 42% of organizations are actively consolidating microservices back into larger units.

The pendulum isn't swinging toward the monolith — it's swinging toward calibration, the maturity of a profession that spent a decade copying hyperscalers without understanding their conditions.

Distributed monolith — the worst of both worlds

Most "microservices" projects in mid-sized companies are distributed monoliths: the operational complexity of a distributed system plus the cognitive complexity of tangled code, with the benefits of neither. The three diagnostic criteria are brutal:

  1. Services must be deployed in lockstep.
  2. A typical domain change touches 3+ repositories.
  3. You have a full-time release coordinator (Sam Newman's tell).

The mechanism is mechanical: a method call within a process takes nanoseconds; the same call over the network costs milliseconds plus serialization, gateway validation, retries, and circuit breakers — a million-fold difference. Industry estimates put microservice infrastructure at 3.75–6× the cost of a monolith serving the same functionality, with lower end-to-end test reliability. (A well-known customer-data platform returned to a monolith in 2018 after three full-time positions were consumed maintaining 140 microservices; the Istio team consolidated four control-plane components into one istiod binary.)

Modular monolith — DDD without processes

The modular monolith is DDD without the network: bounded contexts implemented as compiler-enforced packages, a single deployment artifact, ACID transactions within the business domain. The bounded context becomes a package, not a process — each module owns its database schema, its public API, and zero cross-module imports from internal/.

The critical difference from a classic monolith is build-time enforcement — architectural rules checked in CI, where a violation fails the build. That resistance to erosion is what the previous generation's big balls of mud never achieved. Reference tools per ecosystem:

  • Spring Modulith (Java) — verifies modules talk only through exposed APIs, blocks internal imports.
  • Packwerk (Ruby, Shopify) — static analysis of constant references with a "ratchet" for incremental legacy migration.
  • import-linter / Tach (Python) — parse the AST, enforce independence contracts.
  • Go internal/ — boundaries enforced by the compiler, zero config.

In a single database with schema isolation you retain strong consistency without the Saga overhead — no distributed transactions, no compensating rollbacks. And extraction to microservices stays on the table: when a module genuinely needs independent scaling (typically ML inference on a GPU), the boundary already exists in code, so extraction is mechanical. Shopify's platform handled 30+ TB/minute at Black Friday 2021 on a modular monolith with Packwerk enforcing boundaries across 2.8M lines of Ruby.

Context economics — what AI agents change

An AI agent's bottleneck isn't cognition, it's the context window. Classic metrics — Conway's Law, Two-Pizza Team, coupling vs cohesion — answered the human limit; the agent has a different limit, so context engineering (giving the model exactly the information it needs) matters more than classic coupling. Andrej Karpathy, within Software 3.0 (the LLM as interpreter, the context window as program), compares the agent to a colleague with anterograde amnesia: it remembers only what's currently in context. Analyses of agentic token consumption show a ~166:1 read-to-generate ratio — architecture determines the economics of every code change the agent will ever make.

Three context effects make the monorepo the rational default:

  • Context Rot — the model "gets dumber" as you add more (Drew Breunig's four patterns: Poisoning, Distraction, Confusion, Clash). A bigger window doesn't eliminate these.
  • Lost in the Middle — empirical research (Liu et al., 2023) shows accuracy drops markedly for content in the middle of a long context, a U-shaped curve.
  • Navigation Paradox — a Feb 2026 study found a dependency graph gives the agent a 23.2-point advantage on tasks with hidden architectural dependencies, even at the largest windows. A larger window doesn't remove the need for structural navigation; it shifts the failure mode.

A modular monolith's monorepo is a single coherent semantic map for the agent. Microservices fragment it — every repo is a separate window, the agent hallucinates API calls and treats neighbors as black boxes — the "distributed monolith with AI agents," the worst variant of the era.

When microservices still win — the decision matrix

Microservices are an advanced tool for companies meeting four verifiable conditions simultaneously. Miss even one and distribution produces a distributed monolith with hallucinating agents:

  1. A mature IDP — an Internal Developer Platform with a service catalog and MCP (Model Context Protocol, "USB-C for AI"). Without it, the agent doesn't know what it's talking to.
  2. Genuinely independent domains — 60%+ of features don't need data from 3+ services. If every feature touches five repos, the boundaries are illusory.
  3. Asymmetric scaling requirements — a specific module needs a GPU, specialized infrastructure, or blast-radius isolation.
  4. Dedicated platform engineering — a minimum of 2–4 full-time platform engineers.

Three out of four isn't 75% success — it's a guaranteed distributed monolith.

The 2026 strategy

Start with a modular monolith. Extract selectively using the Strangler Fig pattern only when a specific module empirically proves it satisfies conditions two and three. Introduce SDD (Spec-Driven Development) — Markdown spec as source of truth, code as secondary artifact — as a discipline process. The dominant architectural metric has shifted from human coupling to AI context management.