🧵 adk-go + dagger

[arctic arrow]

🧵

cc @gritty cave @cedar bluff

[cedar bluff]

CUE + ADK + Dagger 😉

[arctic arrow]

I'm going to ignore the cue part

[cedar bluff]

lol

So I'm using LoadContainer/DirectoryFromID
https://pkg.go.dev/dagger.io/dagger#Client.LoadDirectoryFromID

to let me walk away from an agent and come back later with an easy to store ID tied to a session

[arctic arrow]

IDs are not guaranteed to be persisted

or reusable across sessions

[cedar bluff]

right, I get that, and the long term soln is to do a real tag/push

but not on every chat turn, those have been fine

[arctic arrow]

Although we've been talking about persistence for a while. We could make sure it supports your use case

[arctic arrow]

But not every dagger object is a container

[cedar bluff]

I'm really only concerned with Directories and Containers

[arctic arrow]

cc @unkempt iris @eternal plover good edge case for object persistence

[arctic arrow]

You are almost certainly concerned with higher-level artifacts on top of that. You just haven't considered the possibility that Dagger could manage them for you

I'm going to guess some CUE-defined abstraction is involved 😛

[cedar bluff]

It's just config at this point, agents, models, instructions bundled up into modules, basically going to look close to the systems that let you config agents with yaml

[arctic arrow]

I think the missing Dagger feature that will help you, is a persistent env.

[cedar bluff]

So I've been storing the DaggerIDs in the state, but that got out of hand. Is there anything of a short consistent size I can use in the meantime?

[arctic arrow]

A single dagger object that you can attach artifacts to (including containers), and you can load across sessions with persistence guarantees

[cedar bluff]

My next step is planned to be

1. save that ID to db or file
2. calc sha, save that to db
3. make association in db, store sha in state

[arctic arrow]

FYI we already have a ton of logic for intelligently exposing dagger objects (including but not limited to containers & dirs) to LLM in a context-efficient way

[cedar bluff]

I should show you the UX/DX I build/aim for in VS Code with Dagger, separate from any agentic stuff

(it of course aligns exteremely well with the pros of dagger4agentic)

Another way to look at what I'm trying to do, and an enterprise feature you should totally take and sell

1. Dagger records human or agentic+human session (via VS Code)
2. This gets persisted and indexed
   What can you do
3. Make it available to the entire org as a resource agents can draw on when collecting context or resources
4. Use it for prompt authoring & evaluation, see if the new prompts can also do the human intervention part
5. Fork any session and try new follow up messages / agents/ prompts
6. Use it for training the next gen of models

One thing that is really missing in the agentic space is experimentation/evaluation frameworks. Dagger seems a fantastic foundation

[arctic arrow]

We do a lot of this already, just limited to CLI interactions

[cedar bluff]

markdown is the new DX lol

[arctic arrow]

Here's a trace of an agentic dev session which @gritty cave used to implement an actual dagger feature, for example https://dagger.cloud/dagger/traces/749f188b993360bf8d341cd4903862e9#ec9e2386fd7b73da

[cedar bluff]

not loading, permission issue?

got some red text eventually

[arctic arrow]

my bad, try again?

[cedar bluff]

it's working, got lost reading system prompts, it's a new hobby of sorts :]

[arctic arrow]

Here's the source code 🙂 https://github.com/dagger/dagger/blob/main/modules/doug/main.go

prompts: https://github.com/dagger/dagger/tree/main/modules/doug/prompts

[cedar bluff]

Is modifying system prompts something you can do mid session in Dagger?

my prompt shenanigans are here, very early into the process of building out a set of agents / teams
https://github.com/hofstadter-io/hof/tree/_next/.veg/embed

This one was supposed to be a joke, but ended up being used for task planning in some emergent behavior, which sent me down a rabbit hole

the cache state is in the system prompt, which means the agent is effecting it's own prompting, and was an intriguing idea that I'm playing around more with

Do what has been asked; nothing more, nothing less.

I need something like this. I started from the supposed claude code system prompt one can find on github, but I'm not a fan of the one-shot personality/behaviors. Still need to clean all that up

Another thing that would be great for ADK+Dagger is better terminal integration

• Dagger has that sweet Terminal() function
• VS Code has a Terminal abstraction
  but I am unaware of a way to connect them

really VS Code + Dagger

[arctic arrow]

Yeah agree - and beyond VS Code, better IDE integration in general

[cedar bluff]

ideally websocket in the middle

[arctic arrow]

We did ship a brand new VS code extension last month

[cedar bluff]

I installed that I think, recently enough I should have the latest. Need to install it on my client setup where it's probably more aligned

These last 2 weeks of hacking a copilot alternative taught me mostly about vscode extension development. Feels like a new branch of the skill tree unlocked and there is so much potential

[jade mulch]

a channel would be nice for this. i was thinking about some way to visualise or easily interact with say a monorepo e.g daggerverse git repos, for far, since each dagger module might be a separate setup/sdk/language - .code-workspace (https://code.visualstudio.com/docs/editing/workspaces/workspaces#_multiroot-workspaces) is really nice, since it can treat each subfolder as a root folder workspace and some extensions actually support this, some dont.

update: i think this is already supported, just another way, nevermind 🙂

[cedar bluff]

I've been using the workspace feature and file to load up several dagger directories at once, now also using it with monorepos.

after I learned that the start debug button depends on what file you have focused, and that it will use the workspace that file was opened from

Can Dagger Agents with Tools be turned into Dagger Tools that other Dagger Agents can use? (agent-as-a-tool, separate from subagent concept)

[arctic arrow]

Yes

One major benefit of wrapping both agents and tools in functions, is that functions can call functions 🙂 So agents can call tools, tools can call agents, all the way down. This is a superior model to special-casing subagents IMO

[cedar bluff]

In ADK, the distinction is about which agent has direct contact with the user.

• agent->subagent is about that primary interaction (send to peer/underling, escalate to parent/user)
• functionTool/agentTool is the same turtles all the way down

how do chat events percolate up through the dagger functions so I can render UI feedback?

how does something like tool confirmation work?

[arctic arrow]

Tools are all sandboxed so confirmation is less important

All events flow through the dagger otel stream

that's why it's all visible in the same trace

Sorry not sure what you mean by "percolate up". For user interaction, or for monitoring?

[cedar bluff]

for user interaction / feedback

1. confirm this tool call (maybe it is an expensive BigQuery call)
2. this tool will take a long time, I will keep you posted on progress

another question, can tools be added to an Agent mid conversation? One thing that seems apparent is that filling your context with a ton of tools / mcp defs is bad. Instead provide one or two tools that can return a small relevant set if the main agent decides tools are needed

[arctic arrow]

Relevant to all 3 questions: generally Dagger focuses on providing rock-solid primitives - lego bricks - that you can build higher-level systems on top of. Over time we add fancier bricks, but slowly and deliberately, like actual lego.

So for example:

1. No confirmation primitive yet. When we add it, it probably won't be LLM-specific (but will work with LLMs)
2. At the moment Dagger is fully synchronous. If you want asynchronous execution you either a) wrap your dagger session in an async execution layer, or b) write a dagger function that hands off to an async execution backend
3. not sure

[cedar bluff]

I'm pretty much handling 2a with ADK, storing that DaggerID in the state at each turn in the session (with history) that ADK manages.

which is where the persistence on Dagger's end comes in

Is there a Dagger Docs page that can tell me the best way to give Dagger a registry on localhost?

Can I turn off GC and do manual pruning/cleanup?

[arctic arrow]

I recommend asking this standalone in #1030538312508776540 for maximum exposure

[cedar bluff]

I have some follow ons for that one, will start that up

[cedar bluff]

oh, another thing for Dagger <-> VS Code would be file create/modify times

[cedar bluff]

Another use case for Dagger Agentic (that I think the described everything is a function is well suited for)

1. agent needs to run tests
2. this requires a database running alongside
3. ADK has long running tasks, but I think there is a gap here, at least far more coordination required than....
4. Dagger Services are just another function that fit this turtles model?

[arctic arrow]

Yes e2e tests are THE use case we are zeroing in on for Dagger 💯

cc @nimble pendant @queen shard @upbeat jungle 😁

we're adding auto-scale out so that even huge test suites can run fast & reliably enough to keep up with an agent army

for example 👆

[upbeat jungle]

awesome! Can’t wait to check it out.

[cedar bluff]

Can Dagger stream back partial responses to a client, in example, as an LLM generates a long report?

Also, is a lot of this stuff alpha and why the docs are minimal on the agentic stuff?

[arctic arrow]

Yes responses are streamed as part of the otel stream. The dagger CLI renders those directly in the TUI. You can write a custom otel-compliant client that does the same

@cedar bluff it might be worth trying out an interactive LLM session in dagger call, just to get a sense of how it all fits together for dagger users

[arctic arrow]

Docs can always be improved, but there is non-trivial amounts of docs for the agentic stuff already:

• https://docs.dagger.io/features/llm
• https://docs.dagger.io/getting-started/quickstarts/agent
• https://docs.dagger.io/getting-started/quickstarts/agent-in-project
• https://docs.dagger.io/getting-started/types/llm
• https://docs.dagger.io/cookbook/agents

[cedar bluff]

It's hooking to OTEL to get responses that I don't want to do, that makes my system more complicated. I see OTEL as something for in-house operations, where consistency / latency have flexibility

[arctic arrow]

• You get the otel stream as it's produced, for more rapid feedback to the user
• The final response you can query in the API (LLM.history or LLM.lastReply I believe)

So streaming is an optional convenience layer - as it should be

[cedar bluff]

If I have 10 clients using webapps against an agent server, would I have to parse apart OTEL to figure out which event needs to go to which client? What consumes OTEL in my webapp/server/agent stack?

[arctic arrow]

It would be cool to add more convenience APIs for clients on top of otel. That's something we don't have at the moment (whether for LLM streaming, or other parts of the otel stream)

[arctic arrow]

All good questions, which I don't have answers to / cc @gritty cave

You're definitely in unchartered territory in terms of use case 🙂 Not necessarily a bad thing

@cedar bluff actually for the "which events to which client" part, that's a simple answer: each client gets a stream of its own telemetry. So you could open N distinct dagger clients for your N agent sessions, and you'll get N cleanly separated otel streams

(the otel stream is streamed to the client, not a single global stream for the whole engine)

For example the dagger TUI is 100% rendering that client otel stream

[cedar bluff]

My approach so far had been to use the Dagger Client like I would a Postgres Client, one per instance

[arctic arrow]

Seems reasonable - and compatible with my suggestion right?

(depending on what you mean by "instance")

[cedar bluff]

my agent server instance could serve 100s of users each with many ongoing sessions. I thought you were suggesting 1 dagger client per session so the events for that agentic call can be fed back to the correct session. Right now each user has a single websocket to the server, over which everything flows, concurrent agentic sessions share this connection

[arctic arrow]

I think the number of dagger client connections is an inconsequential implementation detail, I doubt it will affect your architecture & performance either way. If it makes otel collection easier (to be confirmed), it would be pretty easy to all dagger.Connect() once per session

[cedar bluff]

Candidly, the startup time for connection is one of the primary reasons BuildKit is not an option for the core of my agentic flow. I have use-cases where I don't need file sys / containers and I need ultra low latency. The ~.5s-1s connect time when aiming for <200ms latency is a non-starter.

I am looking into proposing an EnvironmentService for ADK and building a prototype with Dagger, which is where I think things will fit best together

[arctic arrow]

@cedar bluff you could run the websocket server as a dagger service. Then it can open dagger sessions for free, via nesting. No remote connection necessary

[cedar bluff]

at that point I have to run everything inside BuildKit, I'm not trying to run my API servers or production workloads in BuildKit, that is a complication and very unnatural way to run things. I have k8s for those kinds of things

[arctic arrow]

it's dagger not buildkit. But yeah fair. I think in the long run this approach will prove superior, but I get that today it can seem weird

[cedar bluff]

Even the Dagger vs Dockerfile is weird, I'm told nearly monthly by the CTO of my main client that the devs ask "why aren't we just using a Dockerfile", at which point I have to remind them the pains we addressed with Dagger

To me, Dagger is inexorable linked to BuildKit. If I make an API call from a Dagger function, that would be happening from within a container running in BuildKit/Dagger, within some container runtime/engine, versus just being an API call from Go like all my other services. Is that a correct understanding?

[arctic arrow]

Dagger started as a layer on top of buildkit, but we're pretty far along in a gradual process of breaking it up into smaller and smaller pieces, and absorbing it into Dagger's native codebase.

We're doing this in order to unlock important features like distributed cache storage for example, which is very hard to implement while wrapping a buildkit black box

[cedar bluff]

Dagger supporting A2A on the roadmap? https://a2a-protocol.org/

[cedar bluff]

and if it is distributed, how can I pass containers or Env around the a2a agent dag...

[arctic arrow]

We're implementing distributed dagger in a way that handles those details for you. You just point the client at one engine and then the whole cluster coordinates behind the scenes.

[arctic arrow]

but, re-reading your message that's probably not what you meant by "distributed"

[cedar bluff]

A2A is the protocol for integration across companies / stacks. If Dagger Agents could be served up via A2A, then it becomes far easier to try integrating it into existing agentic "teams". The vibe I keep getting is that in order to use Dagger Agents, it really wants to be the MC in the spotlight, but I already have an MC. Like, how can I introduce Dagger Agents with a POC into an existing system, and then politic and demonstrate why using Dagger brings value to our agentic setup. (stepping back to talk less about myself, more as how the process of pitching this to a client, or as a dev to my employer and coworkers.

It would also make the job of exposing a Dagger Agent to users, as a (b2b) company, easier in that the A2A should just be done for me, something as simple as Service()?

[nimble pendant]

Makes sense! I haven't kept up with A2A since the original announcement - whats the integration look like between A2A + MCP? I ask because today you could run a dagger agent as an mcp server (dagger mcp <module>) for another agent. If there's not any crossover there, I guess that would be the same place A2A could be implemented on the Dagger side, for dagger a2a <module>

[cedar bluff]

MCP is Agent -> Tool, A2A is Agent <-> Agent

[jade mulch]

A2A is interesting, the protocol is vague in some areas and their own google example docs mix and match who controls or owns the session id

needs to support SSE with events / long running tasks, file parts (url or byte data), text parts

and, if an agent needs to talk to another agent, how many agents are then having to track their own context id