Dynamiq
Use Cases

Use Cases

End-to-end journeys showing how enterprise teams assemble Dynamiq features into production agents — architecture, permissions, deployment, and evaluation.

The pages in this section are journeys, not feature references. Each one follows a single realistic scenario — a support triage agent, a transaction review agent, a patient document intake pipeline, an internal knowledge assistant — from the first architectural decision to the dashboards you watch after launch. They are written for the people who evaluate and design these systems: solution architects deciding whether the platform fits, and the builders who then have to ship it.

How to read these pages

Every journey follows the same arc:

  1. Scenario & outcomes — who the agent serves and what "working" means.
  2. Architecture — the shape of the workflow in prose and a table of the components it uses, before any clicks.
  3. Build walkthrough — a concise sequence of steps, each linking to the feature page with the full instructions. The journeys deliberately do not duplicate step-by-step content; the feature docs stay the single source of truth.
  4. Permissions & compliance spotlight — how to scope access, gate risky actions, and produce an audit trail for this specific scenario.
  5. Deploy & integrate — turning the workflow into an App and wiring it into the surrounding systems.
  6. Evaluate & monitor — the dataset, metrics, and dashboards that keep quality measurable after launch.

All names, datasets, and identifiers in these pages are illustrative examples — substitute your own.

Enterprise readiness in Dynamiq

The same small set of platform controls recurs in every journey, so it is worth naming them up front. Access is governed by organization roles and project membership — Owners and Admins manage the org, Private projects restrict who can even open a resource — and production integrations authenticate with Access Keys that can be scoped to a single project, given an expiry, and revoked instantly. Inside workflows, guardrail and validator nodes screen what reaches the model and verify what leaves it, while human-in-the-loop mechanisms pause runs for a person's sign-off. Every run is recorded as a trace — the full execution tree, inspectable node by node and downloadable as JSON — and evaluations turn those traces into versioned datasets and scored regression runs. How the platform stores credentials and enforces authorization is documented in Security.

On this page