Azure / Azure/azure-functions-agents-runtime

Proposal: Dynamic workflows for markdown agents

Open
#90 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.