Skip to content

Research / Engineering Capacity OS / Working Paper

Engineering Capacity as an Operating System

A working model for deciding how human judgment, AI agents, engineering knowledge, telemetry, and governance should operate together across the AI SDLC.

Author: Lonnie McRorey, Founder and CEO, TeamStation AI, Boston, Massachusetts. ORCID: 0009-0001-5351-190X. Status: working research model for review and testing, not a universal topology, delivery guarantee, or final peer-reviewed finding.

Abstract

The AI SDLC changes engineering capacity because work now moves through humans, AI agents, repositories, tools, policies, and review gates. The paper proposes that CTOs and CIOs treat those parts as one operating system, not as separate hiring, tooling, and automation decisions.

The model places humans where intent, architecture, judgment, approval, exceptions, and accountability are required. It places agents inside bounded tasks with known permissions, context, evaluation, and escalation. The paper does not prescribe one universal team shape.

What the Paper Contributes

  • Leadership problem: More people or more AI agents do not create usable capacity when ownership, knowledge, review, and delivery controls remain weak.
  • Topology model: Capacity comes from the arrangement of human judgment, bounded agent capability, durable knowledge, execution rules, telemetry, and governance.
  • Evidence rule: Every recommendation must separate what is observed, modeled, directional, unknown, opinion, hypothesis, future work, internal research, or externally validated.
  • Control boundary: A leader should know which source supports a recommendation, what remains unknown, and where human approval is still required.

How the Research Is Controlled

These supporting diagrams show how sources enter the paper and how evidence quality limits a recommendation. They document the research controls behind the argument.

Pipeline diagram showing topic input, MCP retrieval, corpus retrieval, clustering, validation, drafting, review, typography, export, publication decision, and self-learning feedback.
Figure 1. TeamStation Research OS Pipeline

Purpose: Show how source retrieval, evidence review, drafting, and release controls support the working paper.

Use: Use it to inspect where evidence enters the paper and where human review can stop unsupported claims.

Output: A traceable paper with reviewable sources, figures, references, and validation records.

PNG | PDF | Mermaid

Control plane diagram linking source providers, evidence engine, paragraph ledger, validation gates, decision output, and learning update.
Figure 2. Engineering Capacity OS Evidence Control Plane

Purpose: Show the control boundary that keeps weak evidence from becoming a confident engineering recommendation.

Use: Use it to inspect source quality, confidence, traceability, governance, and human approval before action.

Output: A bounded recommendation with evidence class, confidence limit, source trace, and next safe action.

PNG | PDF | Mermaid

Read, Cite, and Review

Start with the browser or PDF version. The remaining formats support accessibility, citation review, research deposits, and reproducibility.

Research Sources and Supporting Doctrine

These public sources connect the working paper to TeamStation research on distributed engineering, cognitive fidelity, team topology, agentic workflows, and delivery governance.

TeamStation AI Entity Links

The working paper is connected to the Engineering Capacity OS hub, the diagnostic question engine, the TeamStation AI parent entity, Distributed Engineering Operating System, Axiom Cortex, Nebula, Engineering Telemetry, AI Delivery Governance, and Agentic Development Workflow.