Questions about running a company of agents

Yes. Running dev3d unmodified, for yourself or your team, asks nothing beyond keeping the license intact — no obligation to publish anything, and no restriction on commercial or internal use. The AGPL only adds an obligation when you modify it and let other people use your version over a network: then you have to offer them the Corresponding Source of what you are running. Section 13 is the clause that says so. If that does not suit you, the copyright holder can license otherwise, and that is worth asking before you ship rather than after.

No. With no provider configured the server boots in mock mode: the entire pipeline still runs, employees are scripted instead of billed, and the office is fully demonstrable. That is how the test suites run too, so the whole thing costs nothing to exercise. When you do add keys, the health endpoint reports the mode and the office badges it so nobody has to wonder whether a run is spending money. The honest limit of mock mode is that it tells you nothing about how a real model behaves on your brief.

Write a plugin.json, and an entry module if you need tools or event subscriptions — declarative plugins ship data only, which is the safer and more portable option. Bundle the directory as a .tar.gz with plugin.json at the root, serve a catalog JSON that points at it with a sha256, and any dev3d installation can browse and install it. The host refuses a hash mismatch, treats the archive as hostile input, and namespaces everything you register, so a mistake in one model entry costs you that entry rather than the whole plugin. Note that installing is gated off by default — DEV3D_ALLOW_PLUGIN_INSTALL is false, because installing runs your code inside someone else’s orchestrator process.

No. dev3d is self-hosted only, and deliberately so: nothing in the orchestrator authenticates, so it is built to be bound to localhost on a machine you control. Running it for other people over a network is possible, and the AGPL is designed with exactly that case in mind — but the security work of putting it in front of the internet is yours. This website is a separate Next.js application, not the orchestrator.

It writes into the workspace a run is confined to, which is a real directory on the machine. Every tool resolves paths through one choke point bound to that workspace, so an agent cannot reach outside it — but the workspace itself is a normal folder, and the orchestrator is not inside an operating-system sandbox. Point it at a checkout you would be willing to lose, and review the diff; the review stage is where a wrong change is supposed to be caught, not a substitute for reading it yourself.

A GitHub issue is usually faster than the form, because the thread ends up next to the code and the suite that should cover it. Include the dev3d version and what /api/health reports — the active mode in particular, since mock and live fail in completely different ways. If you would rather not open an issue, the form works and a person will read it.