← manishpande.in Contents
Reference architecture · 2026 The Agentic Platform by Manish Pande
© 2026 Manish Pande Mumbai, India Set in Space Grotesk · Source Serif 4 · JetBrains Mono
First-Principles Engineering · No.01 Reference Architecture

The Agentic
Platform

A first-principles system design for running autonomous AI agents reliably, safely, and economically at scale.

Edition 1.0 · 2026 Scope 30 chapters Stack Durable · MCP · A2A · AG-UI · OTel Level Practitioner
Start reading Preface · The demo is not the system Almost anyone can wire an LLM to a few tools in an afternoon and watch it accomplish something that looks like magic. Turning that loop into infrastructure that thousands of agents can run on — concurrently, durably, observably, under budget, and without leaking your data or your customers' — is a different discipline entirely. That gap is the subject of this book. Begin →

About this book

This is a working reference architecture, not a product manual. It derives the structure of an agentic AI platform from the underlying constraints — non-determinism, latency, cost, failure, and trust — rather than from any single vendor's framework. Where specific tools are named (Temporal, Hatchet, LiteLLM, TensorZero, MCP, A2A, SPIFFE, OpenTelemetry, Langfuse, OPA, and others), they are chosen as representative of a category and a design pattern. The category and the pattern are the durable knowledge; the specific tool you adopt will depend on your constraints and on how the ecosystem evolves after this edition.

The agentic tooling landscape moves quickly. Treat version-specific details as illustrative and verify current capabilities against primary documentation before you commit. The architectural reasoning — why a layer exists and what it must guarantee — is designed to outlast any individual component.

Reading conventions — Diagrams use a consistent schematic language defined in the legend that follows the preface. Throughout, teal callouts mark first principles, indigo callouts mark key design decisions, amber marks operational hazards, and rust marks anti-patterns.

Contents

  1. Before a single component is chosen, we establish what an agent is, what it must have to function, and what changes when one agent becomes a platform serving many. These three chapters are the foundation every later decision rests on.

    1. 1 The Anatomy of an Agent
    2. 2 From Demo to Platform: The Seven Hard Problems
    3. 3 The Reference Architecture
  2. The substrate the agent runs on and the model it thinks with. Durable execution makes long runs survivable; the control loop turns model output into action; the gateway tames the model's cost and latency; context engineering decides what the model gets to see.

    1. 4 Durable Execution: The Runtime Substrate
    2. 5 The Agent Control Loop & State Machine
    3. 6 The Model Gateway
    4. 7 Reasoning & Context Engineering
  3. A reasoner that cannot act is a chatbot, and one that cannot remember is amnesiac. These four chapters give the agent hands and a past: tools and the protocol that standardizes them, a sandbox to run untrusted code safely, a layered memory, and the retrieval systems that ground reasoning in real knowledge.

    1. 8 Tools & the Model Context Protocol
    2. 9 Sandboxed Execution
    3. 10 Memory Systems
    4. 11 Retrieval, RAG & GraphRAG
  4. An agent that can reason, act, and remember is powerful — and, unleashed, dangerous. These four chapters cover the two themes that separate a demo from a system you can put in front of real users and real money: how multiple agents coordinate without multiplying chaos, and how the platform proves who is acting, constrains what they may do, and stays inside the law.

    1. 12 Multi-Agent Systems & A2A
    2. 13 The Human-Interaction Layer (AG-UI)
    3. 14 The Agentic Threat Model
    4. 15 Identity, Authorization & Agentic Payments
    5. 16 Guardrails, Safety & the Lethal Trifecta
    6. 17 Policy, Governance & Compliance
  5. A system you cannot see, cannot measure, and cannot afford will not survive contact with production. These four chapters cover the operational disciplines that turn a working architecture into a running business: observing what agents do, evaluating whether they do it well, controlling what they cost, and scaling them reliably under real load.

    1. 18 Observability & the OTel GenAI Stack
    2. 19 Evaluation
    3. 20 Cost, Metering & FinOps
    4. 21 Scaling, Reliability & Deployment
  6. The core chapters named the categories. Four of them carry more operational weight than a single section can hold — the layer that brokers every tool call, the network substrate that carries every request, the fleet that isolates every line of model-written code, and the pipeline that turns usage into revenue. This part descends from the architecture diagram to the wiring underneath it.

    1. 22 The MCP Control Plane: Gateway, Registry & OAuth 2.1
    2. 23 The Deployment Substrate: Service Mesh, eBPF & Zero-Trust Networking
    3. 24 Sandboxing at Scale: VMMs, Snapshots & the Local-Dev Problem
    4. 25 The Metering & Billing Surface: From Usage Event to Invoice
  7. The preceding parts build a platform that one organization can run. Serving many customers from it, governing the data and the models it depends on, and keeping it within a promise written down as a number are different disciplines — the ones that separate a system that works from a service you can sell. These four chapters cover the concerns that only appear once the platform has tenants, a data estate, a fleet of model versions, and an SLA.

    1. 26 Multi-Tenancy
    2. 27 Data Architecture & Lifecycle
    3. 28 Model Lifecycle & Customization
    4. 29 Reliability, SLOs & Disaster Recovery
  8. Part VIII

    Synthesis

    The components are all on the table. What remains is to assemble them in the right order, decide what to build versus buy, and name the mistakes that sink platforms so you can avoid them. This final chapter is the architect's playbook — how to go from nothing to a production agentic platform without building everything at once or painting yourself into a corner.

    1. 30 The Complete Build: Phases, Trade-offs, Anti-Patterns

Diagram legend

Every schematic in this book uses the same vocabulary. Lines encode the kind of flow; box fills encode the kind of component.

Components stateless service core / control stateful store external / model Flows data / request control / decision async event mono labels = protocols, identifiers, and quantitative annotations
Legend. Solid arrows carry data and requests; dashed indigo arrows carry control-plane decisions; dotted teal lines carry asynchronous events. Box fill denotes component class.