Modular Monoliths for Agent Workflows: Where Local Calls Help

Conceptual architecture; arrows show relationships, not measured latency, energy or safety guarantees.

Count the actual critical path

Suppose a workflow makes 20 sequential internal requests and each adds 10 milliseconds of transport overhead. That is 200 milliseconds before model calls, database queries and execution. This is an illustrative calculation, not a benchmark or proof that every service hop takes 10 milliseconds.

Profile traces at realistic load. Parallel independent reads, reuse connections and reduce redundant calls before assuming a different deployment topology is required. Adding per-hop p99 values does not produce a rigorous end-to-end p99 measurement.

A module is a boundary inside a deployment

A modular monolith keeps domain interfaces explicit while running the code in one deployment unit. Local calls can avoid network serialization and simplify tracing. Fowler’s Monolith First discussion explains why teams may benefit from finding workable boundaries before distributing a system; it also acknowledges the tradeoffs of that approach. ^[1]

Shopify’s engineering account describes modularizing a large application to improve developer productivity. It is evidence of boundary work, not a measured sub-millisecond AI-agent runtime or a universal traffic limit. ^[2]

Keep transactions short and deterministic

Inventory reservation, a ledger update and an audit record may share a transaction when they use the same database and transaction context. That can make a particular business operation atomic.

Do not keep a database transaction open while an LLM deliberates over many tool turns. Long-lived transactions hold resources and can increase contention. Instead, expose a narrow operation that validates its inputs and permissions, performs a short transaction and returns an authoritative result.

A rollback does not unsend an email or reverse an external payment. Use an outbox, operation identifiers and status reconciliation for effects that cross the transaction boundary.

Recovery should not depend on a model guessing

If a response is lost after a write, the next attempt needs to distinguish an uncommitted operation from one that completed. A stable operation identity and an authoritative status lookup help in both monoliths and services.

Avoid claiming that one timeout must crash an agent, or that a single process guarantees zero data corruption. Both architectures need deadlines, validation and recovery behavior.

Choose service boundaries for independent scaling, trust, ownership or operational needs. Choose local modules where those benefits do not justify another network boundary. The useful goal is understandable failure behavior and measured performance, not winning an architecture label.