Builderforce.ai

A human-in-the-loop, fully agentic cloud — train your own AI agents and use them inside your own agent, manage your whole workforce on a Kanban board, and review and approve every action without ever leaving VS Code.

What is Builderforce.ai?

Builderforce.ai is a human-in-the-loop, fully agentic cloud where ideas become software and software becomes agents. You stay in control of every step while AI agents do the work — train your own specialist agents and put them to work inside your own agent, manage the whole workforce from a Kanban board, and review, validate, and approve everything without leaving your editor. It combines a full in-browser IDE with an AI training pipeline, a Workforce Registry for specialist agents, and an orchestration portal for self-hosted BuilderForce Agents meshes.

Three capabilities at the core:

One platform. Three roles:

Key Capabilities

In-Browser IDE

• Full Node.js runtime via WebContainers — run npm install, Vite dev servers, and interactive shells without leaving the browser
• Monaco Editor with syntax highlighting, IntelliSense, multi-file tabs, and real-time collaborative editing via Yjs CRDT
• xterm.js terminal connected directly to the WebContainer shell — full PTY, shared across collaborators
• AI Chat Panel — streaming AI assistant with full project file context; can apply code changes and create files directly
• Live Preview — iFrame running the Vite dev server; updates on save

AI Training Studio

• In-browser LoRA fine-tuning — uses @seanhogg/builderforce-memory / Transformers.js with WebGPU; trains Mamba-1/2/3 and GPT-style models up to 2B parameters entirely client-side
• Hybrid Local Brain — Mamba State Engine (mamba-engine.ts) runs an O(n) selective scan alongside transformer inference; agent state persists to IndexedDB as a compact Float32 state vector and is embedded in exported AgentPackage JSON
• Dataset generation — LLM-assisted JSONL instruction dataset creation with SSE streaming progress
• AI evaluation — independent judge scores model outputs on code correctness, reasoning quality, and hallucination rate (0.0–1.0)
• WebGPU fallback — CPU software path via forceFallbackAdapter: true; platform reports gpuMode: 'cpu-fallback' transparently

Workforce Registry

• Publish specialist agents — bundle a LoRA adapter, capability profile, and MambaStateSnapshot into a portable AgentPackage JSON artifact
• Skill-based discovery — agents are searchable by skills, evaluation score, and hire count
• Hire and deploy — one click to register an agent in your BuilderForce Agents mesh; PowerShell install script for local deployment
• Iterative improvement — training_sessions table tracks dataset → training → evaluation → re-training loops for continuous agent quality improvement

Local LLM Inference Pipeline

• Per-agent inference endpoint — POST /api/ide/agents/:id/chat routes inference through OpenRouter with the agent's persona injected into the system prompt; X-Inference-Mode: lora | hybrid | base | fallback-base header signals which path ran
• Mamba state injection — v2.0 agents carry a MambaStateSnapshot; each inference call prepends [Memory: step=N signal=X context="..."] to the system prompt, giving the agent persistent conversational memory without re-training
• Mamba state sync — PUT /api/ide/agents/:id/mamba-state accepts a MambaStateSnapshot from the builderforce CLI after each session; upgrades the agent package to v2.0 and recomputes inference_mode; GET /api/ide/agents/:id/mamba-state retrieves the stored snapshot
• Package versioning — agent packages are v1.0 (LoRA only) or v2.0 (LoRA + Mamba state); GET /api/ide/agents/:id/package returns the correct format and increments request_count
• Workforce routing in chat — POST /api/ai/chat with model: "builderforce/workforce-<agentId>" auto-routes to the agent inference endpoint (the legacy coderclawllm/ prefix is still accepted); no client-side changes required
• Inference logging — agent_inference_logs table captures model ref, latency, token counts, status, and inference mode per request for observability and billing

BuilderForce Agents Orchestration Portal

Builderforce.ai is the cloud-side control plane for BuilderForce Agents self-hosted agents:

• Fleet registration — agent hosts register at POST /api/agent-hosts with machine profile (IP, workspace dirs, ports, tunnel metadata)
• Heartbeat + capability sync — PATCH /api/agent-hosts/:id/heartbeat keeps capability maps and machine profiles current
• Assignment context — GET /api/agent-hosts/:id/assignment-context delivers assigned project metadata and context hints; the runtime syncs to .builderforce/context.yaml
• Host-to-host mesh relay — the AgentHostRelayDO Durable Object proxies WebSocket connections between agent hosts; POST /api/agent-hosts/:id/forward dispatches tasks to a remote host, authenticated with the SOURCE host's own API key (?from=<id>&key=…, or the X-AgentHost-From header) and refused across tenants
• Approval gates — human-in-the-loop control for high-impact agent actions; agents request approval before executing; outcomes are audited
• Task management — tasks and executions tables track work assigned to specific agent hosts; POST /api/tasks/next feeds the next task to a waiting agent
• Legacy mounts — /api/claws and /api/agentNodes still answer for fleets that have not moved, with Deprecation: true and a Link: rel="successor-version" pointing at /api/agent-hosts (presentation/middleware/legacyAlias.ts). New callers use the canonical path.

Multi-Tenant Platform

• JWT auth with web token (global) + tenant token (workspace-scoped) dual-token model
• Multi-auth — email/password, OAuth social login (Google, GitHub, LinkedIn, Microsoft), and magic link sign-in all coexist on the same account
• Tenant isolation — all resources (projects, agent hosts, agents, training jobs) are scoped to a tenant; no cross-tenant data access
• Multi-workspace — users belong to multiple tenants; bf_default_tenant_id auto-selects on login
• Admin observability — /admin surface for platform admins (superadmin flag); logs/global-errors.txt in R2; /observability LLM usage metrics

Billing & Subscriptions (Stripe)

• Stripe only — src/infrastructure/payment/StripeProvider.ts (Stripe Checkout + Billing, hosted payment page, webhook-activated). There is deliberately no provider switch and no manual fallback: a fallback that activated plans without charging meant an unconfigured deploy handed out paid plans for free.
• PaymentProvider interface — src/infrastructure/payment/PaymentProvider.ts keeps TenantService off the concrete Stripe client and lets tests inject a fake; it is not a provider-swap seam.
• Checkout flow — POST /api/tenants/:id/subscription/checkout always returns a hosted checkoutUrl. The plan activates only when the signed webhook confirms payment — never from the request itself.
• Webhook handler — POST /api/webhooks/payment receives Stripe events; HMAC-verified with a 5-minute replay window; activates/cancels subscriptions via normalised WebhookEvent
• Configuration — set the STRIPE_* Worker secrets (see src/infrastructure/payment/index.ts). They are validated lazily: absent secrets return 503 from the billing routes and never break Worker boot.