OrchestrAI multi-agent orchestration platform
A production-inspired stateful multi-agent orchestration platform for autonomous customer support, built with LangGraph and TypeScript.
Impact
Key Features
- Multi-agent customer-support orchestration and Graph-based routing and workflow control.
- Handles multi-step customer support conversations
- Identifies and routes requests to specialized support agents
- Verifies customers before sensitive support actions
- Retrieves customer, order, shipment, and transaction information
- Searches support policies and knowledge to ground responses
- Handles order issues, returns, refunds, and related workflows
- Maintains conversation context across multiple steps
- Pauses workflows when user verification or additional input is required
- Resumes interrupted conversations from their previous state
- Executes sensitive actions through controlled backend operations
The Problem
Customer-support requests often look simple but become multi-step very quickly. A question like “My order is late—can I get a refund?” can require customer verification, order and shipment lookup, policy retrieval, eligibility checks, and potentially a sensitive backend action.
I wanted to explore how an AI support system could handle those workflows without relying on one LLM to make every decision.
The Approach
OrchestrAI uses a graph-based orchestration model where specialized agents handle different reasoning tasks while deterministic tools handle operations that need predictable behavior.
The system maintains a structured conversation state so information gathered in one step can be carried into later steps. Retrieval through pgvector provides relevant support knowledge, while PostgreSQL checkpointing is designed to let workflows pause and resume rather than losing their context.
The result is an architecture where the LLM can reason about a customer's request without becoming the source of truth for application state or sensitive actions.
The Challenge
One of the first problems I encountered was state management.
While stepping through the graph, I found that an order lookup could successfully add order information to the conversation state, but a later routing update could replace rather than properly merge the existing state. The individual pieces worked; the problem only became obvious when I inspected the state between graph nodes.
That pushed me toward explicit typed state and custom reducers, making state transitions predictable instead of allowing each node to overwrite information implicitly.
What I Learned
The biggest lesson was that the difficult part of agentic systems isn't simply getting an LLM to produce a good answer. The harder engineering problem is controlling everything around the model: state, routing, tool execution, persistence, and evaluation.
If I started again, I'd define a small set of end-to-end support scenarios before building the broader architecture. That would give each architectural decision a concrete problem to solve and make it much easier to measure whether the system actually works as intended.
