Workflow.run() function runs the workflow and generates a response, either as a WorkflowRunOutput object or a stream of WorkflowRunOutputEvent objects.
Many of our examples use workflow.print_response() which is a helper utility to print the response in the terminal. This uses workflow.run() under the hood.
Running your Workflow
Callworkflow.run() and capture the result in response:
The
Workflow.run() function returns a WorkflowRunOutput object when not
streaming. Here is detailed documentation for
WorkflowRunOutput.Async Execution
TheWorkflow.arun() function is the async version of Workflow.run().
Here is an example of how to use it:
Streaming Responses
To enable streaming, setstream=True when calling run(). This will return an iterator of WorkflowRunOutputEvent objects instead of a single response.
Streaming all events
By default, when you stream a response, only theWorkflowStartedEvent and WorkflowCompletedEvent events will be streamed (together with all the Agent and Team events).
You can also stream all events by setting stream_events=True.
This will provide real-time updates about the workflow’s internal processes:
Streaming Executor Events
The events from Agents and Teams used inside your workflow are automatically yielded during the streaming of a Workflow. You can choose not to stream these executor events by settingstream_executor_events=False.
The following Workflow events will be streamed in all cases:
WorkflowStartedWorkflowCompletedStepStartedStepCompleted
Async Streaming
TheWorkflow.arun(stream=True) returns an async iterator of WorkflowRunOutputEvent objects instead of a single response.
So for example, if you want to stream the response, you can do the following:
Event Types
The following events are yielded by theWorkflow.run() and Workflow.arun() functions depending on the workflow’s configuration:
Core Events
Step Events
Step Output Events (For custom functions)
Parallel Execution Events
Condition Execution Events
Loop Execution Events
Router Execution Events
Steps Execution Events
See detailed documentation in the WorkflowRunOutputEvent documentation.
Storing Events
Workflows can automatically store all execution events for analysis, debugging, and audit purposes. Filter specific event types to reduce noise and storage overhead while maintaining essential execution records. Access stored events viaworkflow.get_last_run_output().events and in the runs column of your workflow’s session database (SQLite, PostgreSQL, etc.).
store_events=True: Automatically stores all workflow events in the databaseevents_to_skip=[]: Filter out specific event types to reduce storage and noise
- Debugging: Store all events to analyze workflow execution flow
- Audit Trails: Keep records of all workflow activities for compliance
- Performance Analysis: Analyze timing and execution patterns
- Error Investigation: Review event sequences leading to failures
- Noise Reduction: Skip verbose events like
step_startedto focus on results
Agno Telemetry
Agno logs which model a workflow used so we can prioritize updates to the most popular providers. You can disable this by settingAGNO_TELEMETRY=false in your environment or by setting telemetry=False on the workflow.