Skip to Content
We are live but in Staging 🎉
Use CasesAgentic automation

Agentic automation

The outcome

A team automates multi-step business processes — triage, enrichment, routing, research, orchestration — with workflows that call tools and make LLM decisions in the same flow. Each run is a durable, resumable cloud job: it persists its state after every step, so it can pause for human input, retry on failure, and resume exactly where it left off instead of starting over.

Why it matters: most automation today is a pile of brittle scripts and manual hand-offs that break the moment an API hiccups, a process needs an approval, or a step has to wait hours for an answer. A durable workflow turns those long-running, multi-step processes into something reliable — it survives errors, waits without burning resources, and picks back up on its own. You build it by describing the process to Claude and letting it drive the dodil CLI.

How it maps to Dodil

You write the process once as a typed workflow, and the platform runs it as a managed cloud job — no orchestrator to operate, no state store to wire up, no model keys to manage.

  • Author the workflow in Scriptum  — a typed, purpose-built DSL that compiles to a durable cloud thread. Deterministic steps (do this, then that, in parallel, with retries) and agent/LLM steps (think → call a tool → observe → repeat, or branch on an LLM judgment) live in one language, type-checked before anything runs.
  • Inference runs on Ignite Models  — every LLM decision, embedding, and classification dispatches to the managed model service. No separate inference account or keys.
  • Data is read and written in K3 — native tools reach SQL , object storage , vector , and graph  engines, so enrichment and routing land their results where the rest of your data lives.
  • Custom tools run on Ignite Compute  — your own functions deploy as serverless tools the workflow (and its agents) can call by name.

Why it’s faster and cheaper here

Without Dodil, an agentic process is an integration project. You stand up an orchestration framework (LangChain / Temporal / Airflow), wire it to an LLM API, host your tools on separate compute, add a state/queue store to track progress, provision the compute to run it all, and thread auth through every one of those services. Then you build the hard parts yourself — durability, retry, and the resume-after-failure / wait-for-human logic — and operate the whole stack forever.

On Dodil, that collapses into the platform. The engine gives you typed steps, tool-calling, LLM decisions, and durable, resumable threads out of the box — the durability, retry, and resume logic is the runtime, not code you write. Inference, data, and custom tools are first-class on the same platform, addressed from the same workflow and reached through one typed CLI an agent can drive. One token authenticates all of it.

The result is faster to ship — you describe the process in one typed language instead of assembling and integrating a half-dozen systems, and the compiler catches mistakes before a run starts — and cheaper to run — one platform and one bill instead of an orchestrator plus an inference vendor plus tool hosting plus a state store, with no integration glue to maintain and no durability layer to build.

Build it

  • Scriptum  — author a workflow that calls a tool, branches on an LLM decision, and runs as a durable cloud thread, from the CLI and programmatically.
  • Ignite Models  · Ignite Compute  · K3 engines  — the inference, custom tools, and data the workflow addresses.
  • For a full step-by-step walkthrough, see the blog .

See also

  • Use Cases — why Dodil ships production software faster
  • CLI · MCP — the typed surface you (and Claude) drive to build this
  • Scriptum  — the typed workflow and agent engine