Band Control Plane

The Interaction Control Plane is the second of Band's two platform layers. While the Agentic Mesh handles agent-to-agent and agent-to-human collaboration, the Control Plane governs it: enforcing who can talk to whom, what they are allowed to do, and keeping a record of every interaction for audit.

General
Developer	Band (Thenvoi AI Ltd.)
Type	Agent governance and security layer
Documentation	docs.band.ai

Core Features

Capability-bound execution: agents can only perform actions they are explicitly allowed to, preventing lateral movement or privilege escalation.
Three-tier isolation: personal, organization, and global scopes keep agents and their data isolated by default.
Authentication and access control: RBAC, OAuth2/JWT, and encrypted API keys secure access to agents and chat rooms.
Runtime visibility: teams can see which agent did what, when, and under whose authority, with full delegation chain visibility.
Policy enforcement: rules are applied at runtime, with audit trails on every interaction and the ability to intervene when policies are violated.

Tools and Resources

App / Console: app.band.ai for managing agents, contacts, and chat room permissions.
Platform overview: band.ai/platform describes how the Control Plane works alongside the Agentic Mesh.
Documentation: docs.band.ai for core concepts on agents, contacts, and chat room routing.

Ecosystem and Integrations

Sits underneath the Agentic Mesh, applying authority boundaries and audit logging to every message and delegation that crosses the mesh.
Enforced for agents connected through any of Band's framework adapters, the Python and TypeScript SDKs, or the MCP server.

Read the platform overview to see how the Agentic Mesh and Control Plane work together, or book a demo to discuss enterprise governance requirements.

National Fire Sentinel

Nusantara Fire Sentinel is an enterprise mission-critical command center that transforms Indonesia's forest and peatland fire (Karhutla) management from a reactive, multi-billion-dollar firefighting struggle into an autonomous, prescriptive prevention system operating 7 to 14 days before ignition occurs. The system partitions Indonesia's high-risk Peat Hydrological Units (KHG) across Sumatra and Kalimantan into 35,216 hexagonal cells using Uber H3 (Resolution 8). Leveraging an enterprise hybrid multi-cloud architecture, it evaluates probabilistic ignition risks across the entire archipelago in milliseconds using an AMD Instinct MI300X GPU-accelerated XGBoost model (192 GB HBM3), pierces through dense tropical cloud cover and smoke to detect illegal pre-ignition land clearing via Sentinel-1 Synthetic Aperture Radar (SAR), computes optimal zero-waste patrol routes for field ground brigades using Google OR-Tools VRP, and autonomously synthesizes military-grade tactical incident action plans aligned with Indonesian environmental regulation (PP 57/2016) via Google DeepMind Gemini.

DaBros Dark Factory

DaBros built a software factory from three coding-agent seats in a BAND room: a foreman that plans the work and closes each stage, a builder that writes the service and its tests, and an assayer that tries to break the result and holds the only vote on whether work is done. A human sends one task message per stage and nothing else. The foreman splits the task into work items with acceptance criteria and invariants, hands them to the builder one at a time, and asks the assayer to verify each one. The assayer builds from a clean copy with the network disabled at the operating-system level, then runs adversarial scripts for concurrent writes, repeated requests, interrupted requests and restarts. It reports PASS or FAIL with the exact command and output. A failure goes to the builder and the foreman in one message, and after three failed rounds the foreman rewrites the item smaller. The three mandates name no endpoint, field or error code, so the same files could drive a different project. The product is a wallet and payments service for the pocketful track, where money must never be created, destroyed or spent twice. In our run all four stage-1 work items passed the assayer in the first round, with three isolated adversarial suites and 17 unit tests. No round failed, so this run shows no defect caught and fixed. The repo holds the mandates, the task, the service, the factory log, the exported room and the setup.

Tablekeeper: Spec-to-Proof Autonomous Factory

Tablekeeper is the result of a Spec-to-Proof autonomous software factory built in BAND AI. Instead of using one coding agent to generate an application, we designed five specialized seats with deliberately separated responsibilities: Conductor, Contract Auditor, Systems Engineer, Experience Engineer, and Adversarial Verifier. The factory converts a specification into atomic requirements, coordinates implementation through complete agent-to-agent handoffs, freezes exact production revisions, independently verifies them, and either accepts the result or routes defects back to the production owner for repair and re-verification. In the submitted run, a single human dispatch initiated the entire four-stage workflow. No clarification, approval, debugging hint, “continue” message, or manual rerun was provided afterward. The agents autonomously progressed through all four Tablekeeper stages. The verification process was not cosmetic. Stage 1 initially passed the shipped checks but was independently rejected after the factory discovered two specification-level edge cases involving valid JSON numeric handling and terminal calendar boundaries. The Systems Engineer repaired the defects in a new commit, and the Adversarial Verifier independently re-tested the replacement revision before acceptance. The final result achieved all 4 independently accepted stages and 575/575 applicable cumulative checks, with all populated upgrade paths passing. Every accepted stage is bound to an exact Git revision and preserved evidence. The factory also produced a polished responsive Tablekeeper browser application for restaurant discovery, availability search, booking, confirmation, reservation lookup, accepted terms, and history. Beyond this challenge, the core factory is intentionally reusable: its mandates describe generic engineering, auditing, orchestration, UX, and adversarial-verification responsibilities rather than Tablekeeper-specific endpoints or fields.

SIPA OS: Pocketful Dark Factory

SIPA OS — Dark Factory is an autonomous multi-agent software engineering system designed to architect, implement, and rigorously verify production-grade microservices without human intervention during development. For the WeAreDevelopers x BAND Dark Factory Hackathon, our team (Aelin AquaSoul) deployed this factory against the Pocketful track to build a secure, high-concurrency financial wallet and payment processing service. Multi-Agent Architecture: The factory operates via three specialized, non-overlapping seats governed by strict system mandates: sipa-os-core (Planner/Architect): Analyzes project specifications, breaks down requirements into sequential work items with explicit done criteria, and coordinates task distribution. sipa-os-dark-v4 (Builder/Implementer): Implements code using the exact mandated tech stack and executes baseline checks. sipa-os-v3 (Verifier/Reviewer): Independently runs container builds and executes rigorous security and invariant attack suites without trusting builder claims. Technical & Security Highlights: Thread-Safe In-Memory Storage: Custom state management backed entirely by Python dictionaries guarded by threading.Lock(). Strict Balance Invariants (I1 & I2): Enforces money conservation (sum of balances always equals the seeded total) and prohibits negative balances/overdrafts, returning a 422 error on violations. Cryptographic Security: Secure password hashing using pre-hashed SHA-256 wrapped into salted bcrypt digests to prevent silent 72-byte truncation vulnerabilities. Idempotency & Validation: User-scoped idempotency keys across all mutating financial endpoints and strict regex-based handle derivation (^[a-z0-9_]{1,20}$). Dockerized Containerization: Fully containerized with dynamic $PORT support and verified using automated pre-flight testing harnesses.

AnticipatedD/G4LA13_Gala4_Localizing_Code-Graph

AnticipatedD/G4LA13_Gala4_Localizing_Code-Graph is a resilient Band Agentic Mesh designed for the Pocketful track. It demonstrates how autonomous agents can collaborate to build a four‑stage wallet and payments service with auditability and reproducibility. The factory runs three agent seats — Architect, Builder, and Reviewer — each with a clear mandate. The Architect inspects requests and produces ordered plans with acceptance criteria. The Builder implements endpoints stage by stage, containerizing services and enforcing balances, validation, and conservation of funds. The Reviewer runs harness tests, validates outputs, and rejects failures with clear logs. Recovery is built in: failures trigger mandate updates and retries until all tests pass. - Stage‑1 establishes authentication, balances, and payments. - Stage‑2 integrates a UI layer with Playwright tests. - Stage‑3 adds time‑aware balances, statements, and operator corrections. - Stage‑4 completes the system with refunds and correction batches. Technologies include Python, Docker, Band SDK, Band Desktop, Band Agent API, Band WebSocket API, Playwright, and GitHub Actions. This structured progression shows originality, resilience, and research‑grade ambition. 🛠 Technologies Used (Expanded) - Python 3.12 Core language for backend service implementation. - Docker Containerizes each stage (stage-1 through stage-4) for reproducibility. - Band SDK Connects agents to Band infrastructure. Provides adapters. - Band Desktop (formerly Jam). The coordination surface where Architect, Builder, and Reviewer agents collaborate. - Band Agent API (/api/v1/agent). Used by agents to validate identity, recruit peers, join chats, send messages, and post events. - Band WebSocket API (Phoenix Channels). - Playwright Automates browser tests for Stage‑2 UI integration. - GitHub Actions CI/CD pipeline for automated builds and harness runs.

TrustForge — Evidence-Gated AI Software Factory

TrustForge is an autonomous software factory designed around one principle: code that works is not necessarily code that can be trusted. Instead of relying on a single AI coding agent to build software and declare it finished, TrustForge creates a complete engineering loop: Architect → Operator → Adversary → Verifier → Repairer → Verifier → Evidence Each seat has a bounded responsibility. The factory transforms requirements into explicit properties, generates adversarial scenarios, implements the required behavior, independently verifies the running system, repairs concrete failures and re-verifies the repaired revision before producing an evidence package. For the Pocketful track, TrustForge produced a self-contained Stage 1 wallet and payments service covering authentication, payments, requests, bill splitting, idempotent writes, atomic multi-item operations, exact integer money arithmetic, activity visibility and state export/import. The verification philosophy is simple: Requirement → Property → Scenario → Implementation → Execution → Observation → Verdict → Repair → Re-verification TrustForge does not treat “tests passed” as proof of universal correctness. Its evidence model explicitly distinguishes VERIFIED, FAILED, INCONCLUSIVE and BLOCKED states and preserves limitations and failure history. The recovered project records 147/147 shipped checks passing in the official isolated Pocketful Stage 1 harness, alongside independent HTTP verification and reproducible container instructions. The factory itself is designed to be reusable beyond Pocketful. Its mandates are domain-agnostic and can be applied to software, APIs, business automations, AI agents and AI-generated applications. TrustForge's goal is not simply to make AI build faster. It is to make AI-built software harder to trust blindly.