feat: Multi agent setups with tasks

[timonv]

Work in progress.

Introduce a 'Task'. A task defines multi agent interactions, allowing swiftide agents to run in a delegating or parallel setup. In the task we can define relationships, hooks, etc.

wip example:

Task::builder()                                                          
    .agents(vec![                                                        
              Agent::builder().name("agent1").build()?,                  
              Agent::builder().name("agent2").build()?                   
            ])                                                           
    .starts_with("agent1")                                               
    .with(Action::for_agent("agent1").delegates_to("agent2").and_back()) 
    .with(Action::for_agent("agent2").can_complete())
    .before_delegate(|task, source_agent, target_agent| ...)
    .on_complete(|task| if some_deterministic_check(completed) {
      Ok(())
    } else {
      task.query_active_agent("Bad agent; try again")
    })
    .build()?               
    .invoke("Do a task thing")                                           
    .await?;                                                             

Still a lot to be done. Initial release will have basic hooks and delegation. The architecture will enable running agents in parallel (agents spawning other agents) as well.

[nikhil-pandey]

A few thoughts:

• Composable workflows: Could a Task itself be treated as an action that an agent can run? That’d enable recursive composition (e.g., agents executing task graphs that themselves contain subtasks).
• Workflow coverage: Curious if you’re aiming to support the common agentic workflows Anthropic outlines here — would be great if we can add examples.
• Durability: Have you thought about resumability/persistence for long-running or restartable tasks? Especially useful for more autonomous or stateful agent flows.
• Dynamic dispatch: Would love to see support for agents or even tasks being exposed as tools to other agents — making it possible to treat an entire workflow as a callable operation in a higher-level orchestration.

Also, do you have a doc or diagram sketching out where this is going long-term? Would love to get a better sense of how you see the agent/task system evolving.

[timonv]

Hey @nikhil-pandey,

Thanks, this is really good feedback, I appreciate it!

A few thoughts:

* **Composable workflows**: Could a `Task` itself be treated as an action that an agent can run? That’d enable recursive composition (e.g., agents executing task graphs that themselves contain subtasks).

Sure, why not, you can go as wild as you want. I'm not building it with that intention, but it should certainly be possible.

* **Workflow coverage**: Curious if you’re aiming to support the common agentic workflows Anthropic outlines [here](https://www.anthropic.com/engineering/building-effective-agents) — would be great if we can add examples.

My vision is a bit of a hybrid. I like the idea of agents acting autonomously, and then using hooks at certain lifecycle events to control the flow. Swiftide agents already have a lot of that, and then the idea is that tasks facilitate more complicated multi agent flows.

* **Durability**: Have you thought about resumability/persistence for long-running or restartable tasks? Especially useful for more autonomous or stateful agent flows.

Yeah. That would be really nice. The default context and message history is fully serializable, so it's actually not that far off. For tasks it's a bit more involved, but I recon that same direction can be used.

* **Dynamic dispatch**: Would love to see support for agents or even tasks being _exposed as tools_ to other agents — making it possible to treat an entire workflow as a callable operation in a higher-level orchestration.

You can create a tool that takes an agent or a task. I'm doing something similar with the delegate tool. In a later release, I'd also want to provide an api so it's easy for agents to spawn other agents (accounting for fork bombs).

Also, do you have a doc or diagram sketching out where this is going long-term? Would love to get a better sense of how you see the agent/task system evolving.

Not quite yet. The idea for this initial release is to facilitate delegation (so agents run in sequence), with hooks on important lifecycle events. Then in a later release add the option for agents to operate in parallel. I think the architecture already facilitates that.

I really appreciate the feedback, keep it coming 🙏

[nikhil-pandey]

👋 Just a quick heads-up — Temporal recently landed durability support for OpenAI's agents SDK in their Python samples. I gave it a spin, and it works really well. After each model completion or tool call, Temporal persistently stores the interaction state — making long-running, resumable agent workflows seamless out of the box.

It would be awesome if we could support a similar experience via the Temporal Rust SDK. Given how nicely Swiftide tasks and agent state are structured, this feels like a natural next step — especially for enabling reliable, stateful orchestration of multi-agent systems.

Just worth noting: the Rust SDK isn’t officially public-facing (yet) — it’s what powers Temporal’s polyglot SDKs internally — but their core execution engine is rock solid and a perfect fit for this kind of use case.

[timonv]

👋 Just a quick heads-up — Temporal recently landed durability support for OpenAI's agents SDK in their Python samples. I gave it a spin, and it works really well. After each model completion or tool call, Temporal persistently stores the interaction state — making long-running, resumable agent workflows seamless out of the box.

It would be awesome if we could support a similar experience via the Temporal Rust SDK. Given how nicely Swiftide tasks and agent state are structured, this feels like a natural next step — especially for enabling reliable, stateful orchestration of multi-agent systems.

Just worth noting: the Rust SDK isn’t officially public-facing (yet) — it’s what powers Temporal’s polyglot SDKs internally — but their core execution engine is rock solid and a perfect fit for this kind of use case.

That's extremely cool, I'd love to add support for this.

This PR is taking a bit longer while I'm fleshing it with a customer. I personally feel it's still a bit barebones, which is the reason why I haven't merged it.

Any idea what's needed to use temporal as a backend?

[timonv]

Closed in favor of the graph like tasks, which are way more flexible