The Monolithic Problem

The Single Process Illusion

When you package `agent_a.py`, `agent_b.py`, and `orchestrator.py` into a single Dockerfile, you aren't just deploying code; you are creating a **Shared Fate Domain**.

In this model, the boundaries between agents are purely logical (functions or classes). In production, these boundaries dissolve under pressure.

1. Blast Radius: 100% Shared Failure

In a Linux container, all processes share the same userspace and memory pool. If your Fraud Detection agent triggers a memory leak while processing a massive dataset, the Linux kernel doesn't just kill that agent.

The **OOM (Out-of-Memory) Killer** terminates the entire pod.

# The Monolithic Death Spiral
def fraud_agent():
    # A bug causing 100MB/min leak
    data.append(process_heavy_ml_inference()) 

# This healthy agent dies too
def refund_agent():
    # Perfectly fine code, but killed by OOM killer 
    # because it shared a pod with the fraud_agent.
    process_customer_refund()

2. Resource Coupling: The Cost of Waste

Agents have wildly different resource profiles. A Researcher might need 4 CPUs and a GPU, while a Router needs 0.1 CPU.

In a monolith, you must provision the pod for the **sum of all worst cases**. If you have 5 agents, you are likely over-provisioning by 400%.

3. Deployment Risk: Fixed One, Broke All

Fixing a typo in your Refund Agent shouldn't require restarting your Fraud Detection models.

In a monolith, every deployment is a "Full System Restart." This introduces 12 minutes of fragility per deploy. If you deploy 20 times a week, that is **4 hours of high-risk exposure every single week.**