If we treat agent harnesses and CLI/MCP surfaces as part of the socio-technical organization (more like teammates and tools in a production line than like editors or IDEs), which current assumptions about team topology—ownership boundaries, on-call rotations, escalation paths, and who is allowed to touch what—become obviously wrong, and how might a Team Topologies–style redesign (stream-aligned, platform, enabling, complicated-subsystem teams) look in an agent-first shop?

Answer

Summary: agents plus harnesses behave like semi-specialized internal teams. Ownership, on-call, and "who can touch what" have to move from files and services to flows, interfaces, and automation.

1. Assumptions that break

• A1: "Only humans in team X touch system Y."

  • With CLIs/MCP, agents can modify many repos via scripted paths. Human-only ownership by repo stops being true; ownership must be defined as: who curates interfaces, guardrails, and harness policies.

• A2: "On-call owns pages for code they wrote."

  • Agents emit large volumes of code across domains. On-call shifts toward owning:
    • the harness policies and rollback paths,
    • golden-path tests and monitors,
    • escalation rules when agent-changed areas fail.

• A3: "Escalation = route to the team that knows this microservice best."

  • With cross-system agents, most changes route through shared automation. Escalation more often goes to: platform/agent team for harness issues, or to a stream-aligned team for product intent problems, not to whichever microservice changed.

• A4: "Junior implementers are the primary source of low-risk changes."

  • Agents take that seat. Humans spend more time on:
    • defining tickets and acceptance checks,
    • reviewing flows and interfaces,
    • refactoring for clarity and observability.

• A5: "Who is allowed to touch what" is enforced socially.

  • In practice, agents will touch anything allowed by their tools. So boundaries must be encoded:
    • in harness access (per-path capabilities),
    • in workflow types (bugfix vs cross-boundary vs refactor),
    • in review routing.

2. Agent-first Team Topologies sketch

2.1 Stream-aligned teams

• Own product flows and user outcomes, not full-stack implementation.
• Responsibilities shift to:
  • defining high-quality work items and tests,
  • curating local policies for agent use (allowed patterns, no-go zones),
  • running diff-first review and merge judgment.
• They still write hand-coded changes for risky paths and experiments, but a lot of execution is: "spec → harness → diff → verify."

2.2 Platform / "agent platform" team

• Owns:
  • harnesses, CLIs, MCP surfaces,
  • shared checks (tests subsets, lint, SLO guards),
  • org-wide policies for where agents can act and at what risk tier.
• Provides:
  • templates for agent tasks (bugfix, migration, refactor, spike),
  • standard review metadata (risk level, tests run, touched domains),
  • audit + observability for agent actions (which flows changed, how often, where failures cluster).
• They become the main contact for incidents where automation misbehaves (bad migration, unsafe refactor), while product-specific incidents still route to stream-aligned teams.

2.3 Enabling teams (craft + socio-technical design)

• Focus:
  • helping stream-aligned teams design their agent usage: prompts, policies, change caps,
  • teaching craft for diff review, taste, and safe agent patterns,
  • codifying checklists and "merge-worthy" criteria into harness rules.
• They may:
  • run short engagements with product teams to introduce better harness usage,
  • design training flows where juniors practice reviewing agent diffs,
  • help re-draw ownership boundaries as agents cross systems more often.

2.4 Complicated-subsystem teams

• Own domains where agents are most dangerous without deep knowledge (e.g., billing, infra, auth, performance-critical kernels).
• Their role shifts to:
  • defining very tight surfaces and contracts for agents (limited CLIs, scoped refactors),
  • producing libraries and APIs that are safe for agents to call,
  • maintaining dense tests and monitors around those areas.
• For changes in these zones:
  • harness enforces stricter workflows (smaller diffs, mandatory human pairing, more tests),
  • on-call often lands here if incidents tie to those subsystems.

3. Ownership, on-call, and escalation in this model

3.1 Ownership

• Moves from "who writes code here" to:
  • "who owns the interface and its contracts?"
  • "who owns the harness policy for this area (risk tiers, test suites, change caps)?"
• A change is "owned" by the stream-aligned team whose outcome it affects, even if multiple systems are touched by agents.

3.2 On-call

• Two main rotations:
  • Product on-call: stream-aligned teams watch user-facing SLOs, explain intent, decide whether to roll back, and create follow-up work.
  • Automation/harness on-call (often in platform/agent team): handles failures in pipelines, bad deployment behavior, and systemic agent issues.
• Complicated-subsystem on-call covers domain-specific incidents but often shares runbooks with the platform team (e.g., safe rollback recipes for agent-driven migrations).

3.3 Escalation paths

• Default: alert → product on-call for the affected stream.
• If symptoms look like automation errors (unusual burst of similar failures after many agent changes): escalate to automation/harness on-call.
• If confined to high-risk domains (auth, billing): escalate to complicated-subsystem on-call, with harness logs attached.

4. "Who is allowed to touch what" under agents

• Encode permissions technically:
  • harness capabilities per team and domain (e.g., only billing team can invoke agent tasks on billing schemas),
  • different risk levels: low-risk refactors vs schema changes vs SLO-critical paths.
• Use opinionated stacks and monoliths to keep agent-accessible surfaces small and test-covered.
• Human exception path stays: seniors can bypass harness limits when necessary but must document why and how they verified it.

5. Resulting shifts in value

• More value in:
  • shaping interfaces and tests agents act through,
  • designing socio-technical boundaries and risk tiers,
  • merge judgment and production safety,
  • small-team leverage: a few seniors + agents + strong harness.
• Less value in:
  • raw implementation throughput,
  • siloed ownership by repo or microservice.

This is a directional sketch: patterns exist in some agent-first teams, but details will vary by stack, risk tolerance, and harness maturity.