Architecture
How Runory Turns External Agents into Reliable Business Operators
A practical architecture for connecting ChatGPT, Claude, Codex, and enterprise Agents to governed FSM execution.
External-Agent-first
Runory does not attempt to replace general-purpose Agents. It gives them a stable business environment. Users can work through the Agent they prefer while Runory preserves the same data, permissions, commands, workflows, and audit model.
A structured access plane
MCP, Skills, and SDK interfaces expose discoverable capabilities rather than raw database access. Each capability has a defined purpose, input contract, permission requirement, risk level, and expected outcome.
Command-owned business change
Every governed write enters through a named command. The command contract declares the intended state transition, validations, atomic effects, events, idempotency policy, and postconditions. Workflows orchestrate commands but do not bypass domain rules.
Configuration and managed extensions
Standard adaptation should use metadata: fields, views, workflows, rules, roles, dashboards, and templates. When configuration is insufficient, a managed workspace extension adds bounded customer logic without modifying official modules.
One authoritative operating model
Human users, mobile teams, voice intake, automation, and external Agents all operate on the same business state. This prevents the Agent layer from becoming a second, inconsistent system of record.
The resulting flow
Business intent flows to an external Agent, then through MCP, Skills, or SDK, into Runory commands and workflows. Runory performs authorization, validation, execution, audit, events, and recovery before the new state appears in operational UI.
Continue reading
Prove it in a real workflow
Start with one priority business workflow.
Validate the Agent, business data, permissions, workflow, and execution loop in 1–2 weeks.