Frequently Asked Questions
Common questions about OpenFlows architecture, security, and operations. For step-by-step diagnostics, see the Troubleshooting guide. Cannot find what you are looking for? Ask on GitHub Discussions
Key architecture facts
- Coder decides where work runs; OpenFlows decides how agents coordinate.
- Every AI call happens through your own model gateway in the control plane.
- Worker workspaces contain no LLM keys, no raw repository credentials, and no agent framework.
- Git identity is a scoped OAuth link — no shared tokens in workspaces.
- Config and extension happen through the control panel, no restart required.
OpenFlows is an autonomous AI software team that turns GitHub issues into reviewed, production-ready pull requests, running entirely inside your own self-hosted Coder environment. The founding idea: Coder governs where agents run; OpenFlows governs how they coordinate. Coder provides the workspaces, identity, and model gateway; OpenFlows provides the planning, review, and merge. Neither replaces the other, and worker workspaces hold no keys or credentials.
Models are enabled in the platform’s AI settings (the Coder dashboard), and you then assign one to each role in the agent registry. Every AI call happens centrally through your own model gateway in the control plane, so you choose the models available to your team and can switch a role to a different model live, without a restart.
All AI calls happen through the model gateway in the control plane. Worker workspaces contain no LLM keys, no raw repository credentials, and no agent framework — the intelligence they need is served to them from the control plane. This is a core part of the security-by-design model.
Each agent runs in its own isolated, disposable workspace provisioned from Coder. It reports progress and coordinates with the team strictly through a small, typed command surface — it never talks directly to the coordination store or the machine plane. That is what keeps the whole system safe and auditable.
Yes. OpenFlows acts on GitHub through a scoped OAuth link for each tenant — a real, attributable identity rather than a shared token. No raw repository credentials ever sit in a worker workspace.
Yes. OpenFlows is self-hosted in your own Coder control plane, so it runs in your VPC, on-premises, or fully air-gapped. All AI calls go through your own model gateway, and each step is a recorded, auditable event.
SENTINEL is instructed to attack the work for security holes, quality issues, and missing test coverage against the agreed plan. It reviews from its own isolated workspace and never touches the builder’s files. When it needs proof, it requests a safe, allowlisted command run for evidence. The posture is straightforward: when in doubt, don’t approve.
Recovery is built into the system. A central reconciliation loop retries failing work a bounded number of times. When retries are exhausted, the ticket is parked and escalated to a human — with a notification and links — rather than failing silently or spinning forever.
OpenFlows itself is open-source and free to run; the cost is your own model usage through your gateway. You control it by choosing a model suited to each role — for example, a more careful, higher-cost model for the reviewer and a general coding model for the builder — and tuning from there.
Yes. The agent registry sets how many workers a role may run at once (its concurrency ceiling). OpenFlows runs a fleet of worker workspaces in parallel and assigns work to whichever is free.
Code context is sent only to the model you configure, through your own model gateway in the control plane. If you run fully self-hosted or air-gapped with a local or self-hosted model, nothing leaves your infrastructure.
VESSEL, the DevOps role, watches CI and resolves merge conflicts. If a merge block is genuinely unresolvable, the work escalates to a human rather than being guessed at. Approved pull requests are merged when green.
Worker workspaces are short-lived and disposable. They are provisioned when work is assigned and torn down when the pull request is merged — no lingering state, no stale credentials, a clean slate every time.
The coordination store is the single, durable record of truth for the whole team — every ticket, worker, approval, review, and pull request. Only the orchestrator and the worker command surface may write to it, and writes are validated. Because the whole team reads one consistent store, no step can be skipped or forged, and the system can restart and pick up exactly where it left off.
A central reconciliation loop re-reads the whole system on a steady cadence, advances every piece of work, and repairs what is broken — with bounded retries. When it hits something that needs a human decision, it stops and escalates to you rather than guessing.
Add a skill, connect an MCP server, or enable a different model as a configuration-only change through the control panel — no restart or redeploy. Adding a brand-new role is the one extension that touches the system’s internals. See the Guides and the Agent Registry concept page.
OpenFlows is driven through the Command Surface reference, which covers the control panel and its command-line equivalent in plain language. There is no separate public HTTP API documented here.
Start with the Troubleshooting guide. It covers bootstrap failures, Coder connectivity, stuck tickets, and merge conflicts. If you cannot resolve the issue, open a report on the OpenFlows GitHub repository.