Let's build a small workflow that reads two regional request counts and combines them into one report. Along the way, we'll see how APFlow separates workflow structure from execution order and registers Python functions as capabilities that can be exposed to agents. The example uses local sample dat
a and SQLite. You can run it without a model provider or an API key. APFlow is an open-source Python orchestration engine. It embeds the apcore module standard, giving registered capabilities descriptions and schemas that adapters can expose through MCP, A2A, REST, and CLI.
Use Python 3.11 or newer. Clone the repository and install APFlow in a virtual environment: git clone https://github.com/aiperceivable/apflow.git Define the two relationships Structure tree: Execution dependencies: The two regional tasks have no dependency on one another, so the engine can schedule them concurrently. Register functions and run the graph import asyncio from pydantic import BaseModel, Field from apflow.adapters.function_executor import function_executor class MetricInput(BaseModel): class MetricOutput(BaseModel): class SummaryInput(BaseModel): class SummaryOutput(BaseModel): @function_executor( @function_executor( async def main() -> None: if name == "main": python workflow_demo.py Report completed: {'total_requests': 30} Follow the dependency data The function returns {"total_requests": 30} as business data. The function decorator handles the executor result envelope, and the task repository stores the business payload in task.result. This distinction becomes useful when an executor also reports usage or a structured execution error. Those values have their own execution metadata rather than becoming fields that every downstream business function must unpack. Inspect the capability contract definition = app.registry.get_definition("apflow.sample_metric") You can explore APFlow's built-in HTTP interface independently: apflow serve --all curl http://localhost:8000/modules Move from a local example to an operated workflow REST and unified servers run a dispatcher. Standalone MCP, A2A, and CLI submission need one connected to the same database.
For recovery, run.retry creates a new Run; submit its new root explicitly. Confirmed completed results can be reused while the original history remains available. For a personal project, replace the sample metrics with one useful integration and keep the graph small. For a team, use a representative reporting or document-processing workflow to evaluate identity, failure recovery, and consumption reporting. Shared token scopes require participating executors to declare and enforce consumption bounds. APFlow remains classified as Alpha. Start with a workflow whose outcomes you can verify, then add remote side effects and provider integrations deliberately. The APFlow repository has the source and examples.
See the current durable submission guide for the next step. If you try this example, open an issue with the integration you want to build, and star the repository to follow its development.
Key Takeaways #
- •You can run it without a model provider or an API key.
- •This story was reported by Dev.to , covering developments in thedev space.
- •AI advancements continue to reshape industries — read the full article on Dev.to for complete coverage.
📖 Continue reading the full article: