Recently hired by an award winning SaaS. Documenting the agent runtime businesses actually need

I was recently tasked on rebuilding the agent runtime behind a popular SaaS. Ended up documenting the architecture because the term “AI agent” has become almost meaningless. A lot of products are still basically a prompt connected to a few tools. That can work until the agent starts doing real work, changing customer data, and representing a business. Wrote a new agentic runtime. The approach is to keep the model responsible for reasoning and tool selection, while the application remains responsible for execution, loopback turns, and control. A turn works roughly like this: An inbound message or scheduled event creates a normalized turn request. The runtime loads the latest conversation, contact data, qualification progress, appointment state, business context, engine instructions, and only the tools currently available to that agent. The model then proposes tool calls. It does not execute them directly. Each tool call goes through typed validation, workspace isolation, permission checks, idempotency, timeouts, and execution-time eligibility before anything is allowed to change. When a tool updates something, only the affected state is refreshed. The model then sees the confirmed result and the updated tool list before deciding what to do next. Once the tool loop is finished, a separate composer writes the customer-facing response using confirmed evidence. SUPER important. We separated the personality-emotion layer from the orchestrator to ensure responses are exactly on brand else it would dissolve. A final policy layer checks the response before it's sent. We also added workflows. The workflow handles deterministic logic: triggers, conditions, waits, actions, approvals, handoffs, and exits. Things that dont need LLM (unless as a feature). So the system is not one massive prompt pretending to manage the entire business process. Lots of AI products doing this (some of the biggest names in SaaS btw). I wrote a short architecture reference explaining the contracts, loop, tool execution, state refresh, composition, policy boundaries, and workflow integration. Keep in mind, this isn't brand-new research. Most of the individual patterns exist across modern agent frameworks. The goal was to combine them into a practical reference for conversational agents that are expected to perform real business operations safely and communicate with customers in return. I’m sharing it because I’d like feedback from other engineers building similar systems? Especially around tool execution, state management, recoverable failures, and where the boundary between an agent and a workflow should sit. I’ll add the document link in the comments. Happy to answer any questions!