The
The runtime serves the solution through its channels, with people when needed, runs its workflows on their own and spreads it across multiple .
The stack
From the solution to the people, each layer with its status label.
The diagram as text
The solutionRuns today
What the business declares, in versioned text documents.
The Runs today
The gate: it checks the whole solution in six stages.
The runtimeRuns today
Multiple pods serve the same solution, one turn at a time per conversation when the queue is turned on.
The channelsRuns today
The agent does not depend on the channel.
The peopleRuns today
When needed, the conversation is handed off to a person.
Availability
Multiple pods serve the same solution, and Postgres keeps what matters.
Several pods serve the same solution: they share the turn and scheduled job queues, handle one turn at a time per conversation, and the web chat response arrives live even when the turn runs on another pod.
Limit The per-conversation queue and the shared turn queue are turned on in the 's configuration.
Postgres is the source of truth: the Redis can be cleared without losing conversations, and without Redis the service can keep going in degraded mode, coordinating pods through Postgres.
Limit If Redis is lost, the deferred jobs held there are lost; the no-Redis mode is turned on by configuration.
The runtime reports its health and : sends traffic only to ready pods and restarts the ones that stop responding, and each solution has a setup checklist that says whether it compiles, has an active channel and has a published version.
Kubernetes
Pods keep no state and report when they are ready.
GrailAOS™ runs on standard Kubernetes, today on , from versioned images: a solution scales by adding runtime replicas, and a new runtime version ships through a , without taking the service down when there is more than one replica.
Limit Tested on k3s; there is no load-based autoscaling, and a request that arrives just as a pod shuts down can fail.
On the infrastructure Omniatix operates, the database has a daily backup and automatic failover, each deployment's network is closed by default, draining a node does not interrupt conversations when there is more than one replica, and a pod shuts down in an orderly way.
Limit Only the runtime has the maintenance safeguard, and without the per-conversation queue a turn in progress can be lost when a pod shuts down.
Delivery
A message does not get lost, and a retry does not duplicate a write.
On WhatsApp, a reply is saved before it is delivered; what fails to go out enters a that retries and, if it still fails, alerts the operator; an incoming message is not acknowledged until it is recorded, and a redelivery is not processed twice.
Limit Only for conversation replies on WhatsApp.
An HTTP integration can send an key so that a retry does not duplicate a write, if the target system honors it.
Limit Off by default, and turned on tool by tool.
Releases
Publishing rebuilds nothing, and rolling back means moving a pointer.
The diagram as text
A new version of a solution is published through the API with its files, without rebuilding the runtime image: first, the compiler checks the whole solution as it would end up and, if it finds errors, the version is not created.
By default, each new version starts in preview: only the owner's test contact sees it, and everyone else is still served by the published version.
A version can go out as a canary: it reaches a percentage of contacts set by the deployment operator, and each contact always lands on the same side.
If the test gate blocks a promotion, the version is not published and the one already live keeps serving.
Limit While the gate decides, and for a few minutes after a block, some turns can receive the new version.
Promoting a version and rolling back to the previous one neither rebuild nor restart anything: they move the pointer to the serving version. Each solution has at most one pending version, which can be canceled in preview or in canary.
Limit Rolling back does not undo the data the new version already wrote.
Without restarting or redeploying, the features the owner turns on and off, the time zone, knowledge, task and campaign settings, channels and each piece of a versioned solution can be changed through the API, on every pod.
Limit Editing a piece this way skips preview and the test gate, and structural changes need a new version.
Workflows
A workflow runs without a conversation, and its run survives a server going down.
Autonomous workflows run as of runtime version 4.404: a workflow with no conversation starts on a schedule, when someone asks to run it now, through the API, or when an agent launches it, and chains agent steps, branches, variables, decisions, and direct tool calls.
Limit A workflow does not start from a channel message: the conversation is handled by an agent, which can launch it.
A workflow iterates over lists of up to five thousand items and runs parallel branches, up to ten at a time, with a rule for when a branch fails: continue with the others, cancel them all, or stop at the first failure.
Limit The parallel branches of a run execute on a single server.
A workflow calls other workflows, waiting for their result or not; if it is canceled, the ones it launched are canceled too, and the compiler rejects cycles.
Limit Up to three levels of workflows within workflows.
A workflow step can wait for a person's approval, and that person can get a : they approve or reject with a comment from the console, and if nobody answers in time the step expires; two resolutions at once do not overwrite each other.
A run lives in Postgres, not in a server's memory: if the server advancing it crashes mid-step or shuts down, another one picks it up; it can wait up to thirty days and stays pinned to the solution version it started with.
When a step fails, the workflow does what the solution declares: retry, retry while telling the model about the error, take another path, use a default value, or skip the step, without repeating what already finished.
Limit A write that was cut off, with no way to know whether it arrived, is not repeated: the step is marked interrupted and the declared error handling follows.
A scheduled task can run a workflow with no conversation involved.
Limit A workflow does not message customers: that is what campaigns are for.
Outbound campaigns, reports, tabular data ingestion, and knowledge base sync also run as scheduled tasks.
Channels and people
One agent for every channel, and a person when needed.
The agent does not depend on the channel: it serves customers on WhatsApp, with templates, buttons and lists; on web chat, with the reply live; through a conversations API, to integrate it into another system; and on physical voice devices.
When a person is needed, the conversation is handed off: the operator gets a push notification and replies from the operations console, from Chatwoot or from the WhatsApp Business app, and the agent takes over again when the person is done.
The agent asks someone on the team without handing over the conversation, keeps serving the customer, and brings the answer back in the same thread, with the facts that person gave and never their text verbatim.
Limit Turned on by configuration; the person replies from the console.
Phone voice calls, through Telnyx.
Limit On a single pod, and without handing off to a person during the call.
Memory
What each customer shares and what they ask to be reminded of.
Long-term memory of what each customer says about themselves, with a cap and a “possibly outdated” flag by age: it expires on its own after a year without interaction and is deleted on request, including when the person asks the agent to forget.
Limit Off by default; turned on in the deployment's configuration.
A person asks an agent to remind them of something, in web chat or on WhatsApp, and the reminder reaches that person, on the same channel and at the requested time: the model cannot choose another person or another channel.
Limit It needs a stable identity for the person: in an anonymous web conversation, the reminder is not scheduled.
Integrations
Where an integration can call is decided by whoever operates the deployment, not by the model.
HTTP integrations cannot call the private network, the machine itself, or the cloud's internal metadata, unless the deployment operator enables it in an allowlist.
An agent uses the tools of an external server, with the runtime as the client: the account connects it once, with a key or with , its tools are pinned in the solution, and the connection goes through the same network guard.
Limit Only tools, not resources or ; if the server changes one, by default the call goes ahead with a warning; the connection belongs to the account.
The runtime ships 102 built-in tools and rejects tool types it cannot run; with its own startup code, a deployment registers its own tools and seeds data, without modifying the runtime.
Limit Several built-in tools depend on configuration or on the deployment's startup code.
It includes platform services: contacts and opportunities, calendar and bookings with their reminders, Google Workspace, reminders a person asks for, and notifications to the account owner.
Limit The deployment's startup code wires in contacts, opportunities and the calendar, and Google Workspace needs its own credentials.
Security
The contact's identity is set by the runtime, not by the model.
Several share the runtime with application-level isolation, a guard against cross-tenant access and end-to-end tests, and the runtime sets the contact's identity on every turn: the model cannot change it.
Limit No row-level security in Postgres and no external audit of the isolation.
Secrets are stored encrypted with AES-256-GCM; tool secrets belong to each tenant and are write-only, and each solution has its own API key, which does not work for any other.
Observability and usage
Every turn leaves its ; alerts arrive when a threshold is crossed, and caps cut off before the next turn.
Each turn leaves a trace in Postgres, with the model, , cost, duration, outcome and each tool it called; each tenant queries its own through the API, along with a snapshot of its activity, and traces expire on their own after thirty days by default.
Each turn's usage is measured at the model's actual cost and can be queried by day, week or month, by solution, agent, conversation or operation type, and each usage entry says where it comes from.
Usage caps, as a billed amount or a number of turns, are checked before each turn and each workflow step, and can block what comes next or pause the solution; when a monthly threshold is crossed, the tenant gets a notification.
Limit The turn in progress always finishes; usage notifications are off by default and, like the billed-amount cap, need billing turned on.
The deployment's operator gets an email when something fails that would otherwise go unnoticed, and at startup the runtime lists what is built but not connected.
Metrics in format, with tenant and environment as required labels, and trace export in format.
Limit OpenTelemetry sends one span per agent turn: workflow runs are not sent.
Models
Each provider, with its status label.
Connecting agents to models from other providers through an OpenAI-compatible : LiteLLM, OpenRouter, or any server that speaks that interface.
Today agents run on Anthropic's Claude, with a failover that can be turned on, through another Anthropic account or through OpenRouter, and an alert to the operator when the provider fails; are computed with OpenAI.
Limit The failover is off by default and is turned on together with the operator alerts.
Questions
Workflows that run on their own, conversational workflows and scheduled tasks, with loops over lists, parallel branches and approvals.
That is the purpose it is designed for, and the engine behind it already runs: workflows that work on their own, with people who approve.
No conversations are lost: Postgres is the source of truth, and a degraded mode, if turned on, coordinates the pods without Redis; deferred jobs are lost.
Yes: on standard Kubernetes, today on k3s, scaling with replicas and updating pod by pod.
Through the API, without rebuilding the image: a preview, an optional canary, and then a promotion or a rollback.
With the trace of every turn, email alerts and usage caps.