I’m excited to share Deputies, an open source control plane for background coding agents! The goal is simple: move agentic software development off individual laptops and into a central hub where teams can see what agents are doing, review their outputs, and keep a traceable history of the work.... Inspired by systems like Inspect/Open-Inspect, Minions, and Open SWE, I built Deputies on top of fks's Flue Framework. It’s designed to run in your own infrastructure and trust boundaries, with Slack/GitHub integrations and Daytona + Docker sandbox support.show more

Check it out at: - -

damn dropping the banger project on Friday eve, nice

haha, I wanted to get it out earlier this week... but other things got in the way!

man, this is great! i was just spending the week building a lot of these primitives myself and being annoyed with tmux & ghostty with my dedicated hetzner server but i'm gonna give this a try! so cool, thanks sid 🙏

You could install this with the docker compose setup on your hetzner server (and use the docker sandbox provider) if you didn’t want to spin up new infra!

started doing exactly that but in the end decided to use a custom image with everything i need with daytona, so so good man!!

Any snags getting Deputies set up or feedback for me?

saw that automations are in the backlog! one small but noce to prioritize next maybe? did that quite well. also, was hitting limit with daytona on the free plan quickly with the disk so some recommendations in a starter kit would be nice

Great feedback, thank you! 🙏

4mo into running similar internal (paperclip, fleet of 25 agents). biggest unlock: making the ticket the source of truth, not agent self-report. caught one builder claiming pass with 3 retries in log last week. excited for OSS version landing.

This is amazing! Great video and overview btw. The onboarding page you had also seems like a great way to make sure everything is setup correctly. Curious - what's on your roadmap? Given this has lots of features already!

A few things! - recurring tasks/sessions that run on a schedule - user/team RBAC (right now every session is visible to everyeone - session tagging/filtering - tracing - evals - more deployment target guides!

Also have you thought about the concept of environments? So an env could rely on daytona snapshots, it's a pre baked image, with one or more repos, custom deps, a set of env's and always kept in sync with a branch (e..g. main). So pushes to main, builds the latest snapshot.

Yes! Right now the sandbox image is global for the whole system, but making the image be configurable per repo/environment is something I'm thinking about. Right now most config is via environment variable, so I need to figure out where/how I want to handle in app config to have a place to put all of these types of things! Thanks for all the feedback!

Hmm it feels important enough to belong in your data model. It's likely something that's setup during onboarding, and users may want to add/update more later. All the configs are a text field. For the build, you could normalize and say the user provides a dockerfile.

I think you would just need some way for them to basically take the env config, and test it. So it builds the snapshot using dockerfile, creates a sandbox, clones the repo. That should validate the img works.

Likely then the user will want a post sandbox start setup - so some user provided setup field where they run a bash script in the repo, to create db, migrate, run their services etc. Basically the env is a deterministic config for have an application ready for the agent to work

Yeah, open-inspect handles this with a setup script in a well known location: I'll have to decide how I want to provide that functionality

How would you differentiate this from other folks (Guild, AgentField, etc)? Curious on your design thinking here.

I'm not super familiar with those, but from a quick look --- Guild: There product description at seems relatively similar, but I dont think that product is open source. I see but that appears to be an older project. My thesis is that having something that is open source so you can deploy into your infra and customize to connect to any weird custom data sources you need is valuable --- AgentField: This looks lower level than Deputies (is closer to what I'm using Flue for). Deputies is meant to be the thing end users are interacting with whereas agent-field is a building block to create such systems. --- Open-Inspect: The closest thing I have seen in the wild is @colemurray's open-inspect Open-inspect is great and is a more mature project, but Deputies can deploy anywhere (while open-inspect is currently Cloudflare only since it relies on Durable Objects)

Thanks! Would love to chat with you about how you view the agentic control plane since its really in an interesting definitional space right now.

Sure! I think there are probably hundreds of companies building similar systems internally right now… There are also: - Frontier lab cloud options (Claude code for web, etc…) - paid options (e.g. Devin / Ona) - open source options (open-inspect / open-SWE/Deputies) My thesis with Deputies is that open source (to enable any weird custom integration necessary) and deployable anywhere (to meet the company where they already work) are valuable traits of such a system!

Will follow up. Thanks!

Hey Sid, im exploring utility of OpenInspect for a project of mine and im curious if you could expand a bit more on how Deputies is different and which of OI deployment constraints does it solve. What deployment/sandbox platforms are you planning to support in the near future?

Open Inspect mostly has a superset of features, with the exception of a docker sandbox provider which Deputies has. Open Inspect can only deploy to Cloudflare because it relies on Durable Objects. Deputies can deploy anywhere that can run a nodejs server (or container) + Postgres. Deputies currently has docs for deploying to @Railway or via docker compose but adapting to other platforms will be simple. Currently Deputies supports @daytonaio and docker sandboxes, but I’ll likely add more providers in the coming weeks (which ones depends a bit on user demand) TL;DR: if you are okay with deploying to cloudflare provably go with open inspect, otherwise give deputies a try Hopefully that helps!

You could leverage AIegis in your centralized hub to protect agents against malicious data!

👀

If you would find it useful in your stack, I'm happy to help out any way I can!