Hi, everyone, good afternoon!

[hidden python]

hey 👋

That all sounds great!

For 1:

Since agents in dagger are executed as dagger functions, you can actually have a multi agent system just by giving an agent's environment an object that contains more agents. And then it can execute them as needed. You can also run dagger-in-dagger if needed, but I suspect the environment approach is what you'll want!

[simple monolith]

+1 to kyle, you likely don't actually need it for multiagent orchestration, but the dagger-in-dagger exec flag is ExperimentalPrivilegedNesting. we use it quite a lot for testing dagger itself, but generally applications outside of that are pretty questionable

2. would manual tool call approval work for you here? tryna understand the full use case and when you wanna be a human in the loop

@ionic forge and I experimented with some interactive flows last month. this was merged, this was abandoned

(neither of those flows really fit what you're asking for. there is, however, a security feature for prompting around remote module LLM usage that gives us the groundwork to do tool call approval pretty easily)

[glacial herald]

Thanks, @hidden python , @simple monolith . So, I have one more question:

• I'm thinking in creating a container, call it "Task". I want to use it as SharedMemory/SharedContext for the Agents. And I want to pass it all around for the agents/dagger modules
  So, my modules needs to accept a container as a parameter, right?

2. would manual tool call approval work for you here? tryna understand the full use case and when you wanna be a human in the loop

There are lots of things that I wanna do with the callback: checking number of tokens input/output , context window size, if the LLM derailed from the task or entered in a loop etc.
It can be human feedback, or analysis made by other agent.

Since I'm used with Ruby on Rails, I like the idea of having callbacks (before, around, after) and also "tapping" into a method call to intercept the flow. I think it is very useful.

Thanks, I will look the links.

One more request, that I forgot:

I gave a quick look in the source-code, on how the tool calling is implemented. As a feature request, it would be nice to have dedicated drivers for each LLM Provider.
For instance, last month OpenAI launched the responses API and until the end of the year, the old completions API will be deprecated. Also, if we had some LiteLLM support,
we could use LLMs not compatible with OpenAI. I guess Model Context Protocol integration is coming soon, right?

Anyways, thanks a lot for the help. I hope that soon, I can give something back to the community, instead of just asking. 🙏

[simple monolith]

So, my modules needs to accept a container as a parameter, right?
maybe container, maybe directory, maybe cachevolume, depends on exactly what you're passing around... with stuff like the ffmpeg example you shared before, i'd prolly reach for directory or cachevolume so that your single-purpose agents don't need to share dependencies when they're sharing data? fwiw we've had a good amount of internal discussion about a shared state primitive for LLMs. The "Env" API may be just the beginning of that.

checking number of tokens input/output , context window size, if the LLM derailed from the task or entered in a loop etc.
It can be human feedback, or analysis made by other agent.
tight this is helpful 🙂

I gave a quick look in the source-code, on how the tool calling is implemented. it would be nice to have dedicated drivers for each LLM Provider.

i'm confused about this one... we do have different drivers per LLM provider? currently google, anthropic, and openAI but we're open to contributions for others.

I guess Model Context Protocol integration is coming soon, right?
yes, but we're likely to release MCP server support before we release MCP client support -- eg use your dagger modules as an MCP server vs have your dagger agents call MCP servers.

[glacial herald]

i'm confused about this one... we do have different drivers per LLM provider? currently google, anthropic, and openAI but we're open to contributions for others.

Nice, I was able to find in the code. Maybe it got updated recently or I misunderstood, first time. I thought all tool calls are being made through tags <tool>, but it looks like it is optimized for each vendor.

It looks like LiteLLM is already OpenAI compatible (at least the main endpoints). So I will have to test it. Thanks!

[simple monolith]

yep yep, if the litellm openai API emulation is anything like ollama's it should just work. you do make a good point that the completions deprecation might create a bit of a weird situation when it's removed from the actual openAI api given that virtually all the "run your own models" things are emulating the older API schema

[hidden python]

One thing you may run into with litellm is that currently we have some automatic internal routing to different provider clients based on the model name. So if you have claude-* configured with litellm, Dagger will try to use the Anthropic client instead of your configured OpenAI compatible client. I've created an issue to track that https://github.com/dagger/dagger/issues/10301

[glacial herald]

Thanks!

[glacial herald]

maybe container, maybe directory, maybe cachevolume, depends on exactly what you're passing around...

One of my ideas is to pass a container "Task", and this container can bind to a port, so it can expose via HTTP/GraphQL etc. the state of the task.

So I can track the task progress via a Web Interface.

As an analogy, instead of passing a primitive value as a parameter, sometimes it is worthy to have a wrapper object. For now, it is just and idea that I'm thinking about.

[simple monolith]

yeah then Container might make sense, or even Service + some representation of filesystem

[glacial herald]

Is it possible for you guys to create a default LLM tool that allow the LLM Core Type to access the metadata (tokens count etc.) ? So it could feed my Task container with the messages array, last reply, history etc. Some kind of "introspection". Makes sense?

[simple monolith]

already exists! History, HistoryJSON, and LastReply are all methods on an LLM object that can be called as tools. the history methods have token counts as you'd expect, too

[glacial herald]

Awesome. So I will start some experiments. Thanks a lot