Why this page
The platform moves fast, and some building blocks are implemented but not yet conclusively verified in every scenario. Instead of scattering such points across many pages, this page lists them in a consolidated, plain-spoken form — so you can make a sound operational decision.
1. Cloud gateways are experimental
Alongside the official vendor APIs there are adapters for the cloud gateways AWS Bedrock, Google Vertex AI and Azure OpenAI. These are implemented but not yet live end-to-end tested.
- Production use of a gateway should happen only after customer-side verification with real cloud credentials.
- The direct vendor APIs (Anthropic, OpenAI, Google Gemini) and on-prem operation via Ollama/vLLM are not affected.
2. Parallel runs only behind a feature flag — and only on one host
Up to v0.20 exactly one run executed per project. Since v0.21 there is a workflow layer above it: a piece of work splits into tasks that run as independent child runs in parallel — each in its own git worktree. This is off by default.
- Without the feature flag
softwarefabrik.workflow.enabledthe platform behaves as before: one run per workspace. - With the flag, at most three child runs execute concurrently per workflow. The limit is deliberately low: every run costs tokens, and more parallelism mainly increases integration effort.
- Since v0.21 the lock applies to the workspace, not the project. Two agents in the same directory remain excluded — otherwise no change would be attributable to a single run.
- No distributed worker pool. All child runs execute as processes on one machine.
- Merge conflicts and contract breaks are resolved by a human. Both pause the workflow and wait for a decision; an agent that reconciles the branch itself is planned, not built.
3. Execution of generated code — isolated environment recommended
Build runs execute agent-generated code (e.g. mvn verify, npm run build). Such code should always be treated as untrusted.
- Run build runs on an isolated or trusted environment, not on a host with sensitive access.
- The container sandbox (
execution.sandbox.variant=container, with network, CPU and memory limits) encapsulates the build and scans of the generated project (mvn verify, trivy). - The agent CLIs themselves (Claude Code, Codex, Gemini, Aider, Kimi) run as processes on the host — since v0.31 with an empty, ephemeral HOME, so the operator's configuration and credentials no longer reach them. This does not protect against targeted reads via absolute paths; that requires an agent container (planned, separate ADR).
4. Repository integration: pull requests and CI feedback for GitHub only
Push, pull request, CI status polling and GitHub releases are implemented against the GitHub API.
- GitLab, Bitbucket and Azure DevOps are not connected yet. For those hosts the local merge into the base branch applies; branch isolation, quality gate and the correction loop work unchanged.
- PR/CI feedback is deliberately opt-in (
git.pr-feedback.enabled, off by default): unattended periodic remote contact should be a conscious operational decision. - The factory-wide GitHub token is only used for hosts on the allowlist (
git.allowed-hosts, defaultgithub.com).
5. Budget caps apply per tenant, not per user
Token usage and cost are captured per project, run, provider, tenant and per seat (the user who triggered the run) and exported as CSV.
- The hard budget cap applies at tenant level. There is no seat-level cap — the seat view reports, it does not constrain.
- If you need to enforce per-user limits, separate by tenant.
6. MCP null state: what it does and where it ends
Since v0.31 no agent run reaches an MCP server the factory has not explicitly approved (ADR-0017). The limits of this isolation:
- Workspace configuration of other CLIs (such as
.codex/,.gemini/,.kimi-code/in the repository) can take effect in non-regulated profiles. It is, however, captured before and after every execution and recorded in the audit chain; the canary harness shows per CLI version whether it takes effect. - In the BAIT/MaRisk/DORA and BSI/VS-NfD profiles, agent CLI adapters only run with a passed isolation proof for the installed CLI version. Until an admin has produced one via the canary, only the mock adapter is usable there — deliberately fail-closed.
- Two sources cannot be proven by marker: the system-wide managed level (not placeable without root — a file with servers found there makes the proof fail) and the claude.ai connectors of a subscription login (switched off via environment variable, listed as unchecked in the protocol).
- A proof applies to the environment it was produced in. After a CLI update a new canary run is needed; until then the block applies automatically.