10 apps you can ship in 50 lines of YAML

People ask us what Digitorn is for. The honest answer is "applications". Not just chatbots, not just coding agents, not just RAG. The runtime is generic. Anything that can be expressed as a loop of LLM decisions plus tool calls fits the model, and the model is one config file.

To make that concrete, here are ten very different apps, each one a real shape we've built or seen built on the platform. Every entry shows the YAML skeleton. The full source for each lives in the Hub.

The hub at the centre is app.yaml. The orbits are categories of work the runtime handles natively (developer tools, live apps, knowledge work, messaging, background jobs). Pick any one, write fifty lines, deploy.

#A coding agent that behaves like Claude Code

The flagship use case. A coordinator on Sonnet that plans, edits files, runs tests, and dispatches search work to a Haiku-powered explorer. We documented the full architecture in the Claude Code clone post, but the kernel of the YAML is small.

1agents:2  - id: coordinator3    brain: { provider: anthropic, model: claude-sonnet-5 }4    delegate_to: [explorer]5  - id: explorer6    modules: [{filesystem: [read, grep, glob]}, bash]7    brain: { provider: anthropic, model: claude-haiku-4-5 }89security:10  behavior:11    profile: coding   # read_before_edit, plan_before_execute, confirm_destructive...1213tools:14  modules:15    filesystem: {}16    bash: {}

Install: digitorn install builtin://digitorn-code. Cheaper than running Sonnet on every turn (cost analysis).

#A live React sandbox where the agent edits in front of you

The agent writes JSX into the workspace via the filesystem module, and a live preview pane shows the result next to the chat as edits land. The pane itself is UI configuration, not a module - ui.workspace with render_mode: react. This is the exact pattern Digitorn's own Craft agent ships with in production.

1agents:2  - id: builder3    modules: [filesystem]4    brain: { provider: anthropic, model: claude-sonnet-5 }5    system_prompt: "Build the requested UI as a single src/App.tsx."67modules:8  filesystem: {}9  preview: {}            # lets the agent look at its own rendered preview1011ui:12  workspace:13    render_mode: react14    entry_file: src/App.tsx15    default_open: true

Ask for a dashboard in the chat. Watch it appear next to the conversation as the agent writes.

#A research agent that cites its sources

Half the value of a research bot is not making things up. The shape that holds up: one coordinator that plans and writes, one or two researchers that fetch sources, one fact-checker on zero temperature that verifies claims before the writer ships the answer.

1agents:2  - id: coordinator3    brain: { provider: anthropic, model: claude-sonnet-5 }4    delegate_to: [researcher, fact_checker]5  - id: researcher6    modules: [{web: [search, fetch]}, {memory: [remember]}]7    brain: { provider: deepseek, model: deepseek-chat, temperature: 0.2 }8  - id: fact_checker9    modules: [{web: [search]}]10    brain: { provider: deepseek, model: deepseek-chat, temperature: 0 }1112modules:13  web: { config: { search_backend: duckduckgo } }14  memory: { config: { working_memory: true } }15  agent_spawn: {}

Most of the token spend lands on DeepSeek, not Sonnet, with citations the writer can't bypass. The full, compiler-verified version of this pattern is the deep research template.

#A LaTeX writer that compiles in the workspace

ui.workspace.render_mode: latex swaps the React renderer for a PDF preview pane. The agent edits .tex files through filesystem, the runtime invokes the LaTeX toolchain and re-renders the PDF as writes land. Useful for paper drafts, technical docs, and anything that benefits from the typographical horsepower - this is the real shape behind Digitorn's own LaTeX Studio builtin.

1agents:2  - id: writer3    modules: [filesystem]4    brain: { provider: anthropic, model: claude-sonnet-5 }5    system_prompt: "Edit paper.tex. The build runs after every write."67modules:8  filesystem: {}9  preview: {}1011ui:12  workspace:13    render_mode: latex14    entry_file: paper.tex

Pair it with the lsp module for diagnostics on every save and you get inline error feedback the same way you'd get TypeScript errors in a code editor.

#A Discord bot that answers in a channel

The discord channel adapter turns any agent into a bot. It's one entry under channels.config.providers: an adapter type, a credential, and an activation block naming which agent wakes up.

1runtime:2  mode: background3  entry_agent: helper45tools:6  modules:7    web: {}8    channels:9      config:10        providers:11          discord_bot:12            adapter: discord13            credential:14              scope: per_user15              provider: discord16            activation:17              agent: helper1819agents:20  - id: helper21    modules: [{web: [search, fetch]}]22    brain: { provider: anthropic, model: claude-haiku-4-5 }

The bot token is never written into the YAML: credential: {scope: per_user, provider: discord} tells the runtime to resolve it from the vault at activation time. The same shape works for Telegram - swap adapter: discord for adapter: telegram.

#A scheduled report that runs every Monday morning

Background triggers turn the agent into a worker that fires on a schedule, on a webhook, or on an event. The agent runs to completion, posts the result somewhere (Slack, email, S3), and exits. No always-on process. No cron job. The YAML is the schedule.

1runtime:2  mode: background3  entry_agent: reporter45tools:6  modules:7    web: {}8    channels:9      config:10        providers:11          monday-summary:12            adapter: cron13            config:14              schedule: "0 9 * * 1"     # numeric weekday - the runtime rejects "MON"15            activation:16              agent: reporter17              message: "Generate the Monday digest."1819agents:20  - id: reporter21    modules: [{web: [search, fetch]}]22    brain: { provider: anthropic, model: claude-haiku-4-5 }

We use this internally for a "what shipped last week" digest. The agent reads our changelog, summarises, and posts it onward. The cron schedule lives next to the agent that uses it, which is the right place for it - and the compiler refuses to install a schedule it can't actually parse, so a typo here fails loudly instead of silently never firing.

#A pull-request triager that catches itself drifting

Webhooks are a cron's cousin. The runtime exposes an HTTP endpoint, a service like GitHub fires it on each new PR, and the agent runs against the diff. Add a behaviour rule to stop runaway loops and you have a triager that can't accidentally cost you a fortune on an unusual PR.

1runtime:2  mode: background3  entry_agent: triager4  hooks:5    - id: cap-tool-calls6      "on": tool_start7      condition:8        type: expression9        expr: "session.tool_calls.total >= 12"10      action:11        type: gate12        reason: "Tool call ceiling reached."1314tools:15  modules:16    web: {}17    channels:18      config:19        providers:20          github_pr:21            adapter: webhook22            config:23              inbound_path: /hooks/github-pr24            activation:25              agent: triager26              message: "{{event.payload.pull_request.title}}"2728agents:29  - id: triager30    modules: [{web: [search, fetch]}]31    brain: { provider: anthropic, model: claude-haiku-4-5 }32    system_prompt: "Read the PR diff. Tag risk areas. Be terse."3334security:35  behavior:36    profile: coding

Twelve tool calls per PR is the ceiling. Past that, the hook's gate action stops the agent and you decide whether to extend.

#A documentation generator that updates with the code

Point it at a directory, give it the filesystem module, and let it read the source plus existing docs. It writes real Markdown files, and a live preview pane next to the chat shows the page as it's written. security.behavior.profile: coding's read_before_edit rule means you can trust that it read a module before describing it.

1agents:2  - id: doc-writer3    modules: [filesystem]4    brain: { provider: anthropic, model: claude-sonnet-5 }5    system_prompt: |6      Read the source under src/. Update docs/ to match.7      One file at a time. Read before you write.89modules:10  filesystem: {}1112security:13  behavior:14    profile: coding1516ui:17  workspace:18    render_mode: markdown19    entry_file: docs/index.md

It's a more forgiving cousin of the coding agent. Same primitives, narrower scope. The full, compiler-verified version is the doc writer template.

#A slide builder that ships an interactive deck

render_mode: slides swaps the preview pane for a fullscreen deck view - one of eight render modes ui.workspace supports (react, html, markdown, slides, code, latex, builder, auto). Same pattern as the React sandbox, different output target.

1agents:2  - id: presenter3    modules: [filesystem]4    brain: { provider: anthropic, model: claude-sonnet-5 }5    system_prompt: |6      Build a deck for the requested topic. One idea per slide.7      Markdown only. No fluff.89modules:10  filesystem: {}1112ui:13  workspace:14    render_mode: slides15    entry_file: deck.md

Useful for kickoff decks, recap meetings, pitch drafts. It's surprising how much faster it is to refine a deck by chatting at it than by clicking through Keynote.

#A knowledge agent that answers from your own documents

Point this one at a folder of docs instead of a live web search, and it answers the way a support engineer who actually read them would - citing the source instead of guessing. It's built entirely on the rag module's real tools: ingest, query, and the rest.

1agents:2  - id: helper3    modules: [{rag: [query]}]4    brain: { provider: anthropic, model: claude-haiku-4-5 }5    system_prompt: |6      Answer using the rag.query tool against the app's knowledge base.7      Always cite the source. If nothing relevant comes back, say so8      plainly instead of guessing.910modules:11  rag: {}

rag: {} with defaults is enough to get started - embedding model, chunking and citations all have sane production defaults. Add sources: [...] later to point it at a real folder, or grant ingest_directory so the agent can load documents itself. The full, compiler-verified version is the knowledge base agent template.

#What ties them together

Ten apps. Different tools, different interfaces, different cadences. The shape is the same in every one: declare what the agent has access to, declare its brain, declare how it's triggered, write a system prompt. Everything else (orchestration, abort handling, hot reload, marketplace packaging, credentials, audit) is the runtime's job.

That's the bet behind the platform. Most of what people end up writing in a Python framework is plumbing the framework should have handled. Push the plumbing into the runtime, leave the user with a config file, and the time-to-app collapses.

If one of these shapes lines up with something you're building, the fastest way to start is the templates page: ten patterns, each one verified to compile against the current schema, each one copy-and-adapt ready.

1curl -sSL https://digitorn.ai/install | sh23# save a template's YAML as app.yaml in a new folder, then:4digitorn install ./your-folder5digitorn chat <app-id>

The runtime and the Digitorn Desktop client are open source on GitHub. If you build something interesting, push it to the Hub. That's how the catalogue grows.

#Further reading

If you want to dig into specific patterns:

• The cost trick that makes multi-agent setups affordable: How we cut our coding agent's bill by 60%
• Why the platform is YAML-first in the first place: Why we chose YAML over Python
• The full architecture of the coding agent: How to build a Claude Code clone in YAML
• Foundations if you're new: What is an AI agent