Daggr is a Python library designed for building and managing robust AI workflows by chaining Gradio applications, Hugging Face Inference Provider models, and custom Python functions. It provides a code-first approach to defining workflows, which are then automatically visualized as a directed acyclic graph (DAG) canvas, enabling inspection of intermediate outputs, re-execution of individual steps, and state preservation for complex or long-running processes. A key feature is its provenance tracking, which allows users to browse through past results, automatically restoring the exact inputs that produced each output, and visually indicating stale parts of the workflow.

The core methodology revolves around connecting computational units called nodes within a Graph. Each node represents an atomic operation with defined input and output ports. Data flows between nodes by connecting an output port of an upstream node to an input port of a downstream node.

Daggr supports three primary node types:

1. GradioNode: This node interacts with a Gradio Space API endpoint. It is initialized with space_or_url (Hugging Face Space ID or URL) and api_name. Input parameters are defined in an inputs dictionary, where keys match the API's expected parameter names. Input values can be:
   • A gr.Component (e.g., gr.Textbox) to create a UI input.
   • A reference to an output port of another node (e.g., other_node.output_name) for data flow.
   • A fixed value (e.g., 1024).
   • A callable (e.g., random.random) to be executed on each run.

Outputs are defined in an outputs dictionary, where keys are arbitrary names mapping sequentially to the API's return values. An optional postprocess lambda can transform the raw API output before mapping to outputs. GradioNodes run concurrently by default as they involve external API calls.

2. FnNode: This node encapsulates a custom Python function. It is initialized with the fn (the Python function itself). Input parameters are specified in an inputs dictionary, where keys must match the function's parameter names. If an input is not specified, the function's default value is used. Outputs are mapped from the function's return value(s) to the outputs dictionary in order. For multiple return values, the function should return a tuple. By default, FnNodes execute sequentially per user session to prevent resource contention, especially for functions accessing shared resources or consuming significant CPU/memory. However, concurrency can be enabled via $concurrent=True$, and concurrency_group and max_concurrent parameters allow for sharing resource limits across multiple FnNodes.

3. InferenceNode: This node utilizes Hugging Face Inference Providers to interact with models hosted on the Hugging Face Hub without local download. It is initialized with model (the model ID). Inputs and outputs are defined similarly to GradioNode, with input requirements depending on the model's task type. Like GradioNode, InferenceNodes run concurrently by default.

Key features and functionalities include:

• Input/Output Handling: Clearly defined methods for connecting and displaying data using Gradio components, fixed values, callables, or inter-node port references. Output ports can also be None to hide output while still allowing downstream connections.
• Scatter/Gather (Experimental): Facilitates parallel processing of list-like outputs. node.output_port.each[key] scatters a list of dictionaries to individual processing calls, while node.output_port.all() gathers all results from a scattered operation into a list.
• Choice Nodes (Experimental): Allows defining multiple alternative implementations for a step using the | operator between node definitions. Users can select the desired variant in the UI. All variants must expose the same output ports, ensuring seamless integration with downstream nodes.
• Persistence and Sheets: Daggr automatically saves the workflow's state (input values, node results, canvas layout) into a SQLite database. Sheets provide separate workspaces within a single app, each with its own state, enabling management of multiple "projects" for the same workflow. The persist_key parameter controls persistence behavior.
• Result History and Provenance Tracking: Every node execution saves a snapshot of its inputs and outputs. Users can navigate through cached results ($<$, $>$), and Daggr automatically restores the exact input values that produced a selected output. This "cascading restoration" also applies to downstream nodes.
• Visual Staleness Indicators: Edges on the canvas are colored orange if fresh (downstream node ran with current upstream value) or gray if stale (upstream value changed or downstream hasn't run). This visual feedback highlights parts of the workflow requiring re-execution.
• Hugging Face Authentication: Daggr automatically uses a local Hugging Face token for GradioNode and InferenceNode calls, enabling ZeroGPU quota tracking, private Space access, and gated model usage without manual configuration.
• LLM-Friendly Design: Daggr provides detailed, actionable error messages with suggestions (e.g., "Did you mean 'prompt'?") to assist AI coding assistants in generating and debugging workflows. The node.test() method allows programmatic inspection of a node's output format, aiding LLMs in understanding data structures for transformations.

Deployment and execution options include running locally via daggr app.py (with hot reloading) or python app.py. GradioNodes can be configured with $run_locally=True$ to automatically clone, set up a virtual environment, and launch a Gradio Space locally, falling back to remote API if local execution fails. Daggr workflows also expose a REST API (/api/schema, /api/call) for programmatic integration and automation, with input keys following a {node_name}__{port_name} format. Deployment to Hugging Face Spaces is supported via the daggr deploy command, which handles dependency management, Space creation, and configuration.