Skip to main content

AutomationConfig

Each brand’s workflow binding holds a JSON AutomationConfig that drives all behavior. This is what makes one workflow serve every brand. A binding for one brand, with every section above populated:

Skip rules

Skip rules cause an early exit with no response generated. They are evaluated in order and the first matching rule wins.
Business-hours evaluation is DST-aware via chrono-tz, so a brand’s hours behave correctly across clock changes rather than drifting by an hour twice a year.

Escalation rules

Pattern-based detection of sensitive topics in ticket text.
tag_and_continue still lets the agent answer — it only marks the ticket. If a pattern describes something the agent genuinely shouldn’t handle alone, use tag_and_review or tag_and_skip.
The regex cache is bounded at 512 entries with a 10KB pattern limit, so a pathological config can’t exhaust memory.

Environment

Temporal and API

Control plane

AppConfig::validate() runs at startup in both the API and worker, so an invalid configuration fails fast rather than surfacing as a runtime error later.

Dashboard

In local development the dashboard proxies to the production engine API unless ENGINE_API_PROXY_TARGET is set. Set it before running the dashboard locally.
A minimal working environment for a local worker and API:

Logging

Structured JSON logging via tracing and tracing-subscriber, configured by RUST_LOG.
AppConfig::validate() runs at startup in the API and the worker, so a malformed value stops the process rather than surfacing later as a failed workflow. If the worker exits immediately after a config change, read the first line of its log — the reason is there, not in Temporal.

Next steps

ResponseAutomationV2

The workflow every value above steers.

Control plane

Authoring and syncing these configs across brands.

Operations

Running the engine, and what to check when a config change lands badly.

Policy engine

Where escalation rules meet the verified-decision gate.
Last modified on August 29, 2026