Ship agents as APIs, widgets and jobs
In short
Apps are deployed workflows: each one gets a hostname, versioned releases and a full run history. Call an App over HTTP with sync, streaming or async requests, embed it as a chat widget, or fire it on a cron schedule or an event from a connected app. Every deployment is recorded, so rolling back to an earlier workflow version is a redeploy, not a rebuild.
What Apps and deployments does
- Three ways to call it
- Get a single response, stream tokens over server-sent events, or fire an async run that posts its result to your callback URL.
- A chat widget in minutes
- Embed a ready-made chat widget or share a hosted chat link for a public App, no custom frontend required.
- Scheduled and triggered runs
- Run an App on a cron schedule or a one-off time, or fire it from an event in a connected app such as a new Slack message.
- Versions and rollback
- Every deployment pins a workflow version, a runtime and a config; rolling back is redeploying an earlier version to the same hostname.
- One account per end user
- Flag a node as a requirement instead of a shared connection, and each end user of your App authorizes their own account before it runs for them.
- A monitoring tab that reconciles
- Cost, tokens, requests and latency, charted by hour, day, week or month, next to the traces that explain any spike.
Ship it three ways
Call an App's hostname directly over HTTP for a synchronous response, or set stream to true for server-sent events that deliver output as the workflow produces it. For long runs you would rather not hold a connection open for, set execution_mode to async and pass one or more callback URLs; the App answers immediately with a request id and posts the result to each one when the run finishes. The same hostname also embeds as a chat widget or a hosted chat page once the endpoint is public, so a workflow becomes a product surface without a custom frontend.
- Endpoint Authorization decides whether a Bearer Access Key is required on every request
- A user_id and session_id pair groups runs into a remembered, multi-turn conversation
- The Integration tab generates the exact Python and TypeScript snippets for your App
- The Runs API creates synchronous, streaming or background runs, uploads files, and lists or cancels runs
- Version
- support-triage v7
- Runtime
- Serverless
- Authorization
- Enabled
- Deployed by
- Maya, today
Versions, rollback and monitoring
Each deployment freezes a workflow version, a runtime and a deployment config, and the App's hostname never changes underneath it, so callers never notice a redeploy. The History tab lists every deployment with who started it, its status and its runtime; rolling back is picking an earlier version from Existing deployment and deploying it again. The Monitoring tab charts cost, tokens, requests and latency over a date range you pick, and every run's full execution trace is one click away when a number looks wrong.
- Variables, triggers and access settings are not versioned; they keep their current values through a rollback
- Serverless is the default; server-based Apps add replica autoscaling with a target CPU percentage
- Download a run's trace as JSON, or export every trace in a date range at once
Cost
$412.80
Tokens
18.4M
Requests
96,210
Latency
1.4 s
One credential per end user
Not every credential should be shared. Flag a node's Connection, or an Action tool's linked account, as a requirement instead of a concrete value, and the platform resolves it per end user at run time instead of at build time. Before running the App for a user, check whether their requirements are satisfied; if not, mint a short-lived connect token and send them to a hosted setup page, or drive the same connect API from your own product.
- A connection requirement takes credentials directly; an app-event requirement sends the user through OAuth consent
- Connections created this way are end-user scoped and never appear in the project's shared Connections list
- A single workflow can mix a shared connection for its LLM with a per-user requirement for one action
Where teams use it
- Sovereign AIRun the whole agent platform, the models and every trace inside your own cloud account or data center, operated by your team.
- Customer serviceAnswer inbound calls and chats, look up and act on the account, and hand complex cases to a person, with every conversation traced.
- Back-office and finance operationsReconcile accounts, clear payment exceptions, prepare dispute cases and draft reports across the systems you already run, with approval before anything commits.
Works with
- Agent BuilderDesign an agent on a visual canvas or in the open-source Python SDK. Both compile to the same engine, so what you build ships either way.
- ObservabilityEvery run is traced and replayable, node by node, with the cost, latency and tokens each step used.
- EvalsScore an agent on a dataset before you ship, then keep scoring a sample of its live traffic after you deploy.
Questions and answers
What is the difference between an App and a workflow?
A workflow is the graph you design in the editor. An App is a deployed, hosted instance of one saved workflow version, with its own hostname, run history, monitoring and traces.
Can I roll back a bad deployment?
Yes. The History tab lists every past deployment of an App; redeploying an earlier workflow version to the same App is the rollback, and the hostname, Access Keys and triggers stay exactly as they were.
How do I embed an agent in my product?
Call the App's hostname directly from your backend with an Access Key, or, for a public App, embed the ready-made chat widget or share the hosted chat link. Both talk to the same endpoint your own integration would use.
How does a deployed App handle each end user's own accounts?
Flag a node as a requirement instead of a shared connection, and each end user authorizes their own account once through a hosted setup page or your own UI before the App runs for them.
What shows up on the Monitoring tab?
Cost, token usage, request counts and latency for the App, charted over a date range you pick and bucketed by hour, day, week or month, with every run's full trace one click away.
See an agent on your own workflow.
Bring a process and its documents. Our engineers will show you how Dynamiq runs it, in your environment or ours.