The building blocks of AI workflows.
Task
in Marvin is a structured way to define these instructions and guide the AI’s behavior. Each task represents a “checkpoint” that requires the AI to meet an observable, verifiable goal. In this way, tasks serve as a bridge between the structured world of traditional software and the more fluid, adaptive world of AI.
This task-centric approach allows you to leverage the full power of AI while maintaining precise oversight. Each task becomes a checkpoint where you can validate outputs, ensuring that the AI’s work aligns with your application’s requirements and constraints.
marvin.run
function to create and run a task in a single step. This is a common operation and accepts all the same arguments as creating a Task
directly.Task
classTask
class:
agents
parameter specifies which AI agents are assigned to complete the task. If not provided, Marvin will use the default agent. You can provide either a single agent or a team of agents that will work together as a unit.
str
, int
, bool
, list
, dict
, etc.None
: sometimes a task requires agents to take actions but not return any specific valueTuple[int, str]
, List[str]
, Dict[str, int]
, etc.Annotated[str, "a 5 digit zip code"]
["book", "movie", "album"]
would require the agent to choose one of the three values.str
.
Pydantic model example:
result_validator
parameter. This function will be called with the raw result and should return the validated result or raise an exception if the result is not valid.
plan=True
, the agent is given the ability to break down complex tasks into smaller, more manageable subtasks. This is particularly useful for handling large or complex objectives that benefit from being tackled incrementally.
The agent can create subtasks at any point during task execution, and these subtasks become part of the task hierarchy. Each subtask is treated as a dependency of the parent task, ensuring that all subtasks are completed before the parent task is considered finished.
allow_fail
: Whether the task is allowed to be marked as failed (default: False)allow_skip
: Whether the task is allowed to be skipped (default: False)cli
: Whether to enable CLI interaction tools for the agent (default: False)plan
: Whether to enable task planning capabilities, allowing the agent to create subtasks to help complete the parent task (default: False)Task
are set during task execution, and can be examined as part of your workflow’s logic.
PENDING
status, progress to a RUNNING
status when the agent begins to work on it, and finally moves to one of a few completed statuses when the task is finished.
Agents use tools to mark tasks as SUCCESSFUL
or FAILED
. Successful tasks will also have a result
property, which contains the task’s final output. This is a value that satisfies the task’s instructions and result type configuration. Failed tasks will have an error message as their result.
Method | Description |
---|---|
is_pending() | Returns True if the task is pending. |
is_running() | Returns True if the task is running. |
is_successful() | Returns True if the task is successful. |
is_failed() | Returns True if the task is failed. |
is_skipped() | Returns True if the task is skipped. |
is_complete() | Returns True if the task is complete (either successful, failed, or skipped) |
is_incomplete() | Returns True if the task is incomplete (either pending or running) |
is_ready() | Returns True if the task is ready to be worked on (i.e. all dependencies are complete but the task is incomplete) |
result
property will contain the task’s final output. This is a value that satisfies the task’s instructions and result type configuration.
If a task fails, its result
property will contain an error message describing the failure.