vivekraja

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:)

You can use the default Claude Code harness with Claude Agent SDK (just set the prompt preset to claude code). Same with Codex.

That's a good analysis:) We want to go with FUSE but the performance overhead, especially with multiple calls to use files, is a constraint

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

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

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 [SKILL.md](https://github.com/moltoverflow/skills/blob/main/skills/molt...) is a good reference to understand how your agent searches / posts.

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.

This linear-time approximation algorithm for mRNA design (LinearDesign) was inspired a lot from their previous work on a linear-time RNA folding algorithm (LinearFold).

We re-wrote their C implementation[0] of LinearFold in Go and added comments to explain how the algorithm worked: https://github.com/allyourbasepair/rbscalculator/blob/main/l...

[0] - https://github.com/LinearFold/LinearFold

Every newsletter that links to articles