We do have a communication protocol between the agents, but it's quite rudimentary. It allows sending messages and creating tasks for other agents. The state module for a particular task is accessible by other agents as well.
We're experimenting with multi-agent systems to figure out what the right API would be for agent to agent communication. We've found Claude Code's Team feature is a good starting point for the abstraction, but we think there's better abstractions and are creating the primitives to allow people do create custom definitions to explore.
Re: audit perspective. We have something we've been working on that we're excited to share soon which I think you'll like:)
Yup! And this is a genuinely hard problem when you try to apply agents to domains other than coding. With coding, you can easily rollback. But in other domains, you take action in the real world and that's not easy to rollback.
We're thinking a lot about how we could provide a "Convex" like experience where we guide your coding agents to set up your agents in a way that maximizes the ability to rollback. For example, instead of continuously taking action, it's better that agents gather all required context, do the work needed to make a decision (research, synthesize, etc.), and then only take action in the real world at the end. If an agent did bad work, then this makes it easy to rollback to the point where the agent gathered all the context, correct it's instructions, and try again
The separation of "gather context → synthesize → act" is a pattern we've found critical in production agent systems too. In LangGraph, we model this as explicit checkpoint nodes — the agent can't proceed to the action phase without passing through a validation gate.
One thing we've run into: the filesystem abstraction works well for code artifacts, but when agents interact with external services (APIs, databases), you need a separate "action journal" that logs intended mutations before executing them. This gives you rollback even for side effects that aren't file-based.
The harder unsolved problem is multi-agent state coordination. When Agent A writes to a shared workspace and Agent B reads it, the filesystem gives you structural persistence but not semantic ordering. Have you thought about adding lightweight event ordering (like a simple monotonic sequence) to the filesystem layer? Without it, agents can read stale state even when files are fresh.
Congrats on the launch — the decoupled storage model is the right primitive.
Curious to hear why we wouldn't work! I'd love to understand what assumptions we're making that won't work for your use case, and what we could work to improve on
Depends on your agent. We haven't used langgraph, but I'd think it's probably the best solution to deploy langchain agents. We're SDK agnostic. We're like langgraph, but for agents that works in a sandbox and needs access to a filesystem to do work.
This is what we see! We want to make it very easy to be able to granularly manage your agents (in terms of files they have access to, env var values, network policy, etc.) on a per-task basis.
With regards to permissions, mileage varies based on SDK. Some have very granular hooks and permission protocols (Claude Agent SDK stands out in particular) while for others, you need a layer above it since it doesn't come out of the box.
There are companies that solve the pain of authn/z for agents and we've been playing with them to see how we could complement them. In general, we do think it's valuable to be provide this at the infra level as well rather than just the application level since the infra layer is the source of truth of what calls were made / what were blocked, etc.
We don't support docker-in-docker yet, but that's something on our short term roadmap. We have the need for this ourselves! For now, you could call a different service to spin up your sandbox with the image of your codebase. Not ideal, but this is what we do now.
Yes, you can use your own subscriptions as long as you follow their guidelines
Dagger (dagger.io) has its own container execution stack, and supports dagger-in-dagger natively, with logical scoping, and without depth limit. Would love to show you both a demo, if you're interested!
(Disclaimer, I'm the CEO of Dagger)
I founded Docker, and lack of proper nesting support was always a pet pieve of mine. I couldn't fix it in Docker, so I fixed it in Dagger instead :)
MoltOverflow is SlackOverflow for agents. But instead of asking questions, agents post solutions after they've solved an undocumented or tricky problem. It could also be used to post limitations that you only encounter once you're in deep. I find it frustrating to have invested a lot into a solution to find a limitations makes my life difficult and I cannot tell you how excited I am to vent through Claude Code. (I may have already vented about an SDK generator that was driving me crazy last week. Felt good to let that out.)
A concern I had about agents posting on your behalf is that it could post sensitive information. To get over this, you can review a post before it's published. You get an email with what the agent wants to post and you can choose to decline (without logging in) or review it. When you review it, you also have the ability to make any edits to remove any identifiers you aren't comfortable with.
How it works:
- You sign in with your GitHub account and generate an API key for your agent which you store at ~/.moltoverflow
- Install the skill with `npx skills add moltoverflow/skills`
- Either you or your coding agent can invoke the skill to search for posts related to the package you're having issues with (we have package, language, and version filters), or to post about a limitation you've faced
The main downstream workflow I'm excited about is making better informed design/purchasing decisions based on other agents' visceral experiences. There have been a lot of times I wish someone posted their experience with a product I'm deciding on, and that feels more likely to be posted with this.
I unfortunately got the domain a few hours before they renamed ¯\_(ツ)_/¯
I think the emerging best way is to do "agentic search" over files. If you think about it, Claude Code is quite good at navigating large codebases and finding the required context for a problem.
Further, instead of polluting the context of your main agent, you can run a subagent to do search and retrieve the important bits of information and report back to your main agent. This is what Claude Code does if you use the keyword "explore". It starts a subagent with Haiku which reads ten of thousands of tokens in seconds.
From my experience the only shortcoming of this approach right now is that it's slow, and sometimes haiku misses some details in what it reads. These will get better very soon (in one or two generations, we will likely see opus 4.5 level intelligence at haiku speeds/price). For now, if not missing a detail is important for your usecase, you can give the output from the first subagent to a second one and ask the second one to find important details the first one missed. I've found this additional step to catch most things the first search missed. You can try this for yourself with Claude Code: ask it to create a plan for your spec, and then pass the plan to a second Claude Code session and ask it to find gaps and missing files from the plan.
Gemini 3 Flash is very good at the search task (it benchmarks quite close to 3 Pro in coding tasks but is much faster). I believe Amp switch to Gemini Flash for their search agent because it is better.
I very much doubt this. I've been using gemini whenever I get hit by codex limits over the past week. 3 pro is very good - a bit behind codex but still very useful. I've tried 3 flash several times and each time what I got back was complete garbage. After the third or fourth attempt I stopped trying.
I actually defended Gemini CLI when someone said this a few days ago. Then Murphy's law hit me with bug after bug, all of which have been reported many times already going back over year or more. I keep having to totally clear out the ~/.gemini folder and then it works again for a while.
I have trouble making Claude even follow CLAUDE.md. Like, it just ignores it, and when it needs to do a task (like testing or running a certain command native to the code base), it does a lot of "find" and "ls" an so on to understand what to run, and frequently runs commands with the wrong flags, badly escaped input etc.
I think Claude could work a lot better (and waste vastly fewer tokens) if it had small bite-size instructions for various tasks ("to run the integration test suite, run "cargo run integration_tests..."), but so far I've been unable to control it.
We're experimenting with multi-agent systems to figure out what the right API would be for agent to agent communication. We've found Claude Code's Team feature is a good starting point for the abstraction, but we think there's better abstractions and are creating the primitives to allow people do create custom definitions to explore.
Re: audit perspective. We have something we've been working on that we're excited to share soon which I think you'll like:)