The Complete Build: Phases, Trade-offs, Anti-Patterns
A reference architecture is a map, not an itinerary. No team builds every layer of this book at once, and trying to is itself a failure mode. This closing chapter sequences the build across all eight parts so each phase delivers working value and earns the right to the next, gives a build-versus-buy heuristic for every layer, and collects the anti-patterns that recur across failed platforms.
30.1 A phased build sequence
The ordering principle is to establish the non-negotiable substrate first — the things that are painful to retrofit — then add capability, then harden, then scale, then reach for frontier features. Durability, identity, and observability are foundational; so, less obviously, are three concerns from Part VII that must be decided early even though they only pay off later: a tenant dimension on every request (Ch. 26), data lineage captured at the moment of derivation (Ch. 27), and a reliability target with disaster recovery for the system of record (Ch. 29). Bolting any of these on late means rewriting everything above them.
30.2 Build versus buy
The heuristic: buy or adopt the undifferentiated plumbing; build only what is specific to your domain and your moat. Your agents' logic, tools, prompts, evals, and domain knowledge are yours to build — they are the product. The substrate beneath them is largely a solved problem you should not reinvent.
| Layer | Default | Rationale |
|---|---|---|
| Durable execution (Ch. 4) | Adopt | Hard to get right; mature engines exist (Temporal/Hatchet) |
| Model gateway (Ch. 6) | Adopt | Plumbing with sharp edges; LiteLLM/TensorZero/Portkey |
| Sandbox fleet (Ch. 9, 24) | Buy | Security-critical; managed microVM sandboxes do it best |
| Vector / memory (Ch. 10–11) | Adopt | pgvector if Postgres-centric; managed if scale demands |
| MCP control plane (Ch. 22) | Adopt | Adopt the broker & registry; own the policy it enforces |
| Interaction layer (Ch. 13) | Mixed | Adopt AG-UI & a reference client (CopilotKit); build the interface itself |
| Networking / mesh (Ch. 23) | Adopt | mTLS, retries, zero-trust are platform primitives (Istio/Cilium) |
| Metering & billing (Ch. 25) | Adopt | Lago/OpenMeter/Metronome; never hand-roll financial events |
| Observability (Ch. 18) | Adopt | Standardize on OTel; Langfuse/Phoenix on top |
| Multi-tenancy (Ch. 26) | Mixed | Adopt the primitives (RLS, KMS); build the isolation model |
| Model customization (Ch. 28) | Mixed | Adopt tuning/distillation tooling; build the data & eval set |
| Data architecture & lineage (Ch. 27) | Build | Lineage, retention & residency are specific to you |
| Reliability, SLOs & DR (Ch. 29) | Build | SLOs, capacity model & runbooks are yours; adopt the monitoring |
| Agent logic, tools, prompts, evals | Build | This is your product and your moat — own it |
| Domain integrations & data | Build | Specific to you; the source of differentiation |
30.3 Anti-patterns to avoid
Autonomy is a cost, not a virtue. If a deterministic workflow or a single model call solves the problem, use that — it is cheaper, faster, and predictable. Reserve full agency for tasks that genuinely require open-ended, model-directed control flow (Ch. 1).
Shipping capability and features before durability, identity, a named threat model, observability, and evaluation exist guarantees a painful rewrite. These are the substrate; lay them in Phase 0, not after the incident that proves you needed them.
Multi-tenant isolation (Ch. 26), data lineage and residency (Ch. 27), and an SLO with disaster recovery (Ch. 29) are decide-early concerns. Retrofitting a tenant dimension across every store, reconstructing provenance that was never recorded, or adding DR after the data already lives in a single region each force a rebuild of everything above them. Carry the tenant from the first request, record lineage at the moment of derivation, and write the SLO before the first customer — not after the audit, the deletion request, or the outage.
"We'll prompt it not to" is not a control. Safety (Ch. 16), budgets (Ch. 20), and authorization (Ch. 15) must be enforced structurally, outside the model. The model proposes; the deterministic platform disposes.
Coupling your core logic tightly to one rapidly-changing framework, or splitting into many agents before a single good one has been tried, both add cost and fragility for no proven gain. Keep the architecture modular and the agent count minimal until evidence justifies more.
An agentic platform is the discipline of wrapping a powerful but non-deterministic, fallible, and expensive reasoner in deterministic systems that make it reliable (durable execution), safe (a named threat model, identity, secrets, guardrails, governance), economical (gateway, caching, FinOps, metering), improvable (observability and evaluation), legible to the people who direct and oversee it (the human-interaction layer), and — once it serves more than one customer — multi-tenant, well-governed, and operable to a stated service level (tenancy, data lifecycle, model lifecycle, reliability). Build the substrate first, grant autonomy deliberately, contain its consequences structurally, govern the data and the models as managed assets, measure everything, and commit only to what you can keep. That is the whole book.