HS

Himanshu Sharma

Lead Platform Engineer

← All blogs

AI • Architecture • Agentic systems

Reference Architecture for AI Agentic Platforms

Agents are not chatbots with extra prompts. In production they are long-running systems: they plan, call tools, write state, and must survive retries, policy, and partial failure. This is the platform shape I use when an iPaaS has to host agent workloads alongside classic integrations.

Five layers, not one mega-prompt

Collapse these layers into a single service and you will debug “the LLM was weird” instead of a failed tool, a stale graph edge, or a stuck workflow.

Experience · product UIs · Teams bot · APIs session, identity, channel Agent runtime · planner / critic / specialist agents LLM gateway · prompt packs · guardrails Durable orchestration · Netflix Conductor sagas · retries · human-in-the-loop · timeouts Tool / iPaaS adapters CRM · messaging · billing · search Knowledge graph + memory entities · edges · episodic store Platform services · IAM · audit · evals · cost meters · observability every tool call is authenticated, traced, and budgeted
Request / plan descent Layer activation
Agents sit above a durable orchestrator; tools and graphs sit below it.
Never let the model own side effects. The model proposes; Conductor (or equivalent) commits. That split is what makes rollbacks and audits possible.

Why orchestration belongs in the platform

LLM loops are great for local reasoning and terrible as a transaction log. Tokens get lost, processes restart, and a half-applied CRM update is still a half-applied CRM update. Durable workflows give you:

  • Explicit steps with retries and compensation (same saga model as iPaaS).
  • Human approval as a first-class wait state, not a Slack hack.
  • Fan-out to specialist agents without nested prompt spaghetti.
  • A searchable execution history for evals and incidents.
ConcernIn the model loopIn Conductor / iPaaS
Retry a failed ticket createHope the next completion agreesIdempotent task + backoff
Pause for a managerCustom pollerWAIT / human task
Audit who changed whatPrompt logWorkflow + CDC trail
Cost / latency SLOGuessPer-step meters

Memory is a graph, not a blob

Working on knowledge graphs at Freshworks taught a simple rule: agents retrieve better when entities and relationships are modeled, not when every past chat is stuffed into context.

Account Ticket Agent run Policy owns started constrained by
Retrieve subgraphs (account → open tickets → last agent actions → policy) instead of raw logs.

Store episodic memory as edges (AgentRun —used_tool→ Adapter) rather than bloated prompt context. Retrieval becomes a bounded graph walk with ACL filters at each hop.

Deployment topology for agent workloads

Agent GPU pools and Java tool workers rarely share the same scaling profile. Split Kubernetes node pools by task domain.

LLM / planner pool GPU · burst scale Conductor control HA · multi-AZ Tool worker pool Java / Node · spot mix
Scale planner and tool tiers independently; Conductor stays the stable spine.

Safety and cost as platform features

Policy

Tool allow-lists per agent role and tenant.

Budgets

Token and $ caps abort the workflow, not the JVM.

Evals

Replay golden traces on every prompt pack change.

Human

High-risk tools always hit an approval task.

This is the same operational culture as messaging SLOs: if you cannot graph it, you cannot ship it. Agent platforms inherit PagerDuty, canaries, and domain isolation from the iPaaS—not a parallel stack.