The execution system defines how agent workflows are executed, with support for both local synchronous execution and distributed execution through Temporal. This specification defines the requirements and behavior of the execution subsystem.
- Synchronous execution in the current process
- Suitable for development, debugging, and simple workflows
- Executes the entire workflow in a single process
- Managed through
run()
andrun_async()
methods onFlock
- Distributed execution using Temporal workflow engine
- Suitable for production, long-running workflows, and reliability
- Executes workflow steps as separate activities
- Managed through
enable_temporal
flag and specialized methods
Responsibilities:
- Execute agent workflows synchronously
- Manage agent context and state
- Handle agent initialization and termination
- Process routing between agents
- Collect and return final results
Responsibilities:
- Set up Temporal workflow definitions
- Convert agents to Temporal activities
- Manage serialization/deserialization for distributed execution
- Handle workflow state persistence
- Provide reliability features like retries and timeouts
- User calls
flock.run()
with start agent and input - Flock resolves the start agent (by name or reference)
- Flock initializes the context
- Flock calls
run_local_workflow()
to execute the workflow - Local executor calls
agent.run_async()
on the start agent - If agent has a router, determine next agent and continue execution
- Continue until no next agent is specified
- Return final result to the user
- User calls
flock.run()
with start agent and input - Flock checks
enable_temporal
flag and identifies Temporal execution - Flock serializes the necessary components
- Flock calls
run_temporal_workflow()
with serialized components - Temporal workflow executes agent activities asynchronously
- Workflow handles routing between agents
- Workflow returns final result to the user
For Temporal execution, components must be serializable:
- Agents must be convertible to/from dictionaries
- Tools must be properly serialized/deserialized
- Context must maintain state across activities
- All inputs and outputs must be JSON-serializable
Local Execution:
- Errors propagate to calling code
- Agent's
on_error()
method is called - Modules'
on_error()
methods are called
Temporal Execution:
- Activity failures trigger retry mechanisms
- Workflow maintains state for retries
- Errors are logged to Temporal history
- Final failures can trigger compensation workflows
-
Execution Transparency:
- Same API for local and distributed execution
- Minimal code changes to switch execution modes
- Consistent behavior across modes
-
Reliability:
- Temporal execution handles failures gracefully
- Persistence of workflow state
- Retries and timeouts configurable
-
Observability:
- Tracing through all execution steps
- Logging at key points
- Metrics for performance analysis
-
Flexibility:
- Support for synchronous and asynchronous APIs
- Compatible with different execution environments
- Extensible to other execution engines
- Local execution must work without external dependencies
- Temporal execution must handle serialization challenges
- Both modes must support the same core features
- Must handle context propagation appropriately
- Must provide clear error information