Azure / Azure/azure-functions-agents-runtime
Proposal: Dynamic workflows for markdown agents
- Dominant language
- Python
- Stars
- 9
- Forks
- 7
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 20
Description
Original proposal migrated from https://github.com/anthonychu/azure-functions-agents/issues/2, written by @cgillum.
## TL;DR
Dynamic Workflows let a markdown agent author and start a distributed, observable, and cancellable workflow of tools, durable timers, and specialized Sub Agents without writing orchestration code. The runtime validates the model-authored plan and executes it with Durable Functions, keeping intermediate work outside the initiating agent turn and allowing execution to continue after the caller disconnects.
This is the programmatic tool-calling pattern made durable: fewer model round trips, bounded parallelism, recovery after worker restarts, outside-the-loop control, and multi-agent coordination.
## Delivered experimental v1
- **Foundation:** `workflows.enabled`, `tool` and `wait` DAG nodes, fan-out/fan-in, templating, hard safety caps, workflow management tools, cooperative cancel, status/list endpoints, and Storage/DTS support — #77.
- **Markdown triggers:** workflow-enabled agents can start workflows asynchronously from supported Markdown-declared triggers — #112.
- **Workflow Sub Agents:** independent deny-by-default `workflows.subagents` grants, stateless leaf `sub_agent` Activities, parallel map/reduce, fixed `{agent, text}` results, parent-owned status/lineage, and a queue-to-Blob DTS sample — #117 and #119.
- **Design source of truth:** [FRD 0004](https://github.com/Azure/azure-functions-agents-runtime/blob/main/docs/frds/0004-dynamic-workflows.md).
The current node types are:
```text
tool -> one explicitly registered @workflow_tool Activity
wait -> one Durable timer
sub_agent -> one fresh, stateless leaf Agent Activity
```
Sub Agent nodes are direct Activities, not sub-orchestrations. They are not independently queryable in v1; the parent workflow owns status, lineage, cancellation, and failure.
## Current authoring model
```yaml
---
name: Incident Coordinator
workflows:
enabled: true
exclude: [destructive_action]
subagents:
- agent: log_analyst
when: Investigate logs for one service
---
```
A workflow plan is an LLM-authored, Pydantic-validated JSON DAG. Plans are deterministic and bounded. Workflow tools opt in explicitly with `@workflow_tool`; Workflow Sub Agents must be statically granted and are validated again before a plan starts.
## Roadmap
The detailed planning roadmap is tracked by [Azure/azure-functions-bucees-planning#1123](https://github.com/Azure/azure-functions-bucees-planning/issues/1123).
### Current two-month plan
1. **Per-agent architecture and implementation** — remove the `main.agent.md` ownership restriction while keeping the Durable engine app-wide and tool/Sub Agent policy isolated per owner ([#109](https://github.com/Azure/azure-functions-agents-runtime/issues/109), [PR #111](https://github.com/Azure/azure-functions-agents-runtime/pull/111)).
2. **Dynamic control flow** — bounded conditions, iteration, dynamic fan-out/fan-in, and aggregation.
3. **Production observability and scalable owner queries** — replay-safe workflow/node telemetry, Durable/MAF correlation, operator KQL, and removal of task-hub-wide in-memory status scans ([#80](https://github.com/Azure/azure-functions-agents-runtime/issues/80), [#92](https://github.com/Azure/azure-functions-agents-runtime/issues/92)).
### Production and GA hardening
4. **Reliable execution policies** — idempotency contract, async workflow handlers, task retry/timeout/backoff, continue-on-error, partial failure, and stronger cancellation ([#139](https://github.com/Azure/azure-functions-agents-runtime/issues/139)).
5. **Scale and governance** — Blob offload for large results, configurable limits, positive capability allowlists, quota, and cost protection.
### Beyond the current two-month plan
6. **Human-in-the-loop** — durable approval gates, authenticated intervention, resume/reject/timeout, and audit history.
7. **Stateful hierarchical Sub Agents** — bounded child workflows with independent status/lineage, depth budgets, cancellation propagation, and typed results.
8. **Interoperability and reusable authoring** — MCP Tasks alignment and versioned reusable workflow definitions. A general-purpose DSL and visual designer remain future candidates, not current commitments.
## Product principles
- **Durable and deterministic:** orchestrator logic remains replay-safe; I/O stays in Activities.
- **Least privilege:** tool and Sub Agent access is explicit, immutable per owner, and enforced before execution.
- **Bounded:** node count, fan-out, waits, active workflows, outputs, and nesting have runtime ceilings.
- **At-least-once aware:** Activities can be redelivered; retries and side effects require idempotency.
- **Observable without leaking identity:** operators correlate by workflow/node identifiers without exposing raw session IDs.
- **No new operator UI:** use Durable Functions, DTS, Application Insights, and stable management contracts.
## Non-goals for the current implementation
- Shared conversation history between parent and specialist agents.
- Unbounded recursive Sub Agents or cross-app invocation.
- A general expression language, visual designer, or unrestricted human-authored workflow DSL.
- Exactly-once model/tool execution.
## Feedback wanted
Feedback is especially useful on dynamic-control-flow constraints, owner isolation across chat/MCP/triggers, idempotency and retry semantics, human approval contracts, and MCP Tasks interoperability.
Contributor guide
Research direction
Start with docs/frds/0004-dynamic-workflows.md, then review the current ownership entry point in main.agent.md and the linked roadmap issues. This proposal has no single implementation target, named tests, or completion criteria; a contributor would need a scoped follow-up with explicit acceptance criteria before beginning.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, markdown, python
- Domain
- backend, cloud, distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100