01 / Orchestration
One control plane
An orchestrator routes work across specialist domains rather than treating every agent as an interchangeable generalist.
System architecture / engineering record
The work behind the work.
BlackBoxx.ai operates a private, modular AI environment built around specialized agents, explicit authority boundaries, human-controlled execution, and evidence that survives the demo.
Technical, not theatricalThis page separates what is operating now, what remains on the roadmap, and what has been independently acknowledged upstream. Sensitive implementation details are intentionally omitted.
16specialized agents
15bounded namespaces
34directional routes
3upstream improvements
Architecture
A governed operating environment for AI-assisted work.
The architecture connects user intent, orchestration, specialized agents, model routing, tools, memory, infrastructure, and real-world outputs. The central design question is not only what an agent can understand, but what it is technically allowed to do.
Control model
Agent intelligence and agent authority are separate things.
A highly capable agent can still be prevented from taking actions or crossing boundaries outside its approved envelope. That distinction is the difference between an impressive demo and infrastructure you can begin to trust with real work.
02 / Least privilege
Capability ceilings
Every non-orchestrator agent operates below an explicit ceiling that removes destructive capability classes it does not need.
03 / Directed access
No wildcard routes
Agent collaboration is allow-listed through directional rules, including one-way relationships where a domain may receive work but never initiate it.
04 / Verification
Controls are tested
Permitted routes and expected denials are exercised live. A control that has not been challenged is not yet a verified control.
DorkOS technical bulletins
Production use → diagnosis → upstream improvement.
These are public, verifiable examples of BlackBoxx.ai tracing reliability defects to root cause and collaborating with the DorkOS maintainers. Statuses below reflect the public record as of September 14, 2026.
Fix merged
Desktop watchdog reload loop
A slow first paint could become an endless 11–13 second reload cycle that destroyed unsaved operator state. The server remained healthy throughout, which meant ordinary server troubleshooting could not explain the failure.
Diagnosis
A heartbeat from the outgoing page arrived after reload, reset the failure count, and prevented the recovery ladder from advancing.
Evidence
45/45 health checks returned HTTP 200, the server and renderer processes stayed stable, and 92 cycles were traced in application logs.
Upstream result
PR #1853 now accepts a heartbeat only from the page the watchdog is actually waiting on. The fix is merged; release delivery is pending.
“Your trace of the reset was exactly right and turned a day of digging into an afternoon.”Dorian Collier · Creator of DorkOS
Fix merged
False server-unreachable diagnostics
The desktop cockpit displayed “can’t reach its server” while the server was continuously reachable. That message misdirected diagnosis and trained the operator to distrust the system’s primary health indicator.
Diagnosis
The screen was keyed to a configuration request rather than server health, and a cumulative failure counter could remain set for the life of the page.
Evidence
The panel was observed while the health endpoint returned 45/45 successful responses in 1.0–5.4 milliseconds.
Upstream result
PR #1857 reserves “unreachable” for cases where nothing answered and reports actual server errors without guessing the cause. The fix is merged; release delivery is pending.
Shipped · v0.73.0
Remote Access packaging and state failures
Remote Access failed to start because a required native binary was absent from the packaged desktop application. The visible switch then snapped back without preserving the error, while higher log levels still failed to disclose the root cause.
Diagnosis
The per-platform ngrok package was a nested optional dependency the desktop packager never reached; separate state-sync and logging defects obscured the failure.
Scope
The upstream response expanded beyond the missing binary to persistent errors, retry behavior, restart survival, dropped-tunnel detection, and useful logging.
Upstream result
The combined fixes were released publicly in DorkOS v0.73.0.
“Your diagnosis was exactly right, and it saved us a lot of time.”Dorian Collier · Creator of DorkOS
State of the system
Operating now is not the same as planned next.
Credibility depends on keeping that line visible.
Operating now
Current environment
- 16 specialized agents coordinated by an orchestrator
- Claude Code and Codex runtimes in production use; OpenCode and Ollama in beta
- 34 explicit directional collaboration routes
- Capability ceilings applied to every non-orchestrator agent
- Dedicated local hardware with human-controlled execution
- Permitted and denied paths tested against expected policy
Roadmap / select
Planned next
- Local inference promoted from beta once runtime routing is finalized
- Stronger isolation between sensitive domains — separate user accounts tested, rollout in progress
- Expanded model routing across additional runtimes
- Additional security hardening and recovery testing
- Long-running agent workflows with clearer lifecycle controls
- Multi-machine expansion when the control model is ready
Emerging infrastructure
Exploring identity beyond the application layer.
Programmable namespaces may become useful infrastructure for agent identity, authentication, delegated access, and continuity. BlackBoxx.ai is participating early while keeping exploratory work distinct from operating systems.
01 / Strategic namespaces
Owned infrastructure assets
BlackBoxx.ai founder Karl Ohlemann owns a strategically selected portfolio of 23 Web3 top-level domains through Freename, all minted on Polygon, including .blackboxx and .moonvault. These assets are being evaluated as programmable namespaces; they are not presented as production infrastructure today.
02 / Ecosystem access
Early product participation
Karl is a Freename VIP client and early product-feedback participant, with direct access to product, engineering, and executive teams through private previews, workshops, roadmap discussions, and feedback sessions. This is emerging-infrastructure participation and technology ecosystem access—not a claim of a formal partnership.
Open systems / real use
Built on DorkOS. Pressure-tested by operating it.
DorkOS is open-source software released under the MIT License. BlackBoxx.ai is an independent user and contributor, not DorkOS or its maintainer.