Builderforce

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's New

• 2026-10-12 — Sequential batching in the local inference runtime. Engine::generate_batch in builderforce-inference runs multiple prompts on one loaded model without a reload (e4c07ee). Concurrent token mixing / paged attention is not in this drop. Changelog: DONE.md.

---

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

• In-browser dev runtime via BuilderForce WebContainers (@seanhogg/builderforce-webcontainers) — our own open-source (MIT) runtime. Previews Vite (React, Vue, Svelte), Create React App and static projects by compiling each file on request with esbuild-wasm and loading packages from esm.sh; runs Node programs, npm install from the real registry and a bfsh shell, one Web Worker per process. No COOP/COEP headers and no session caps. Previews and processes are served from preview.builderforce.ai, isolated from your Builderforce session. Next.js/Nuxt/SvelteKit/Remix/Astro dev servers, native addons and install scripts are not supported — they are detected and declined with a reason.
• Monaco Editor with syntax highlighting, IntelliSense, multi-file tabs, and real-time collaborative editing via Yjs CRDT
• xterm.js terminal connected to the runtime's bfsh shell (line editing, history, pipes, npm, npx), 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 served by the in-browser dev server; every open preview reloads on save
• Check and Publish in the tab — type-check (createChecker()) and production build (runtime.build()) run in the browser with no install, so Check and Publish work on the files themselves

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- " 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= &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.

Dev Analytics & Team Intelligence

• Contributor profiles — cross-platform developer identity reconciliation (GitHub, Jira, Bitbucket); GET /api/contributors
• Activity ingestion — POST /api/contributors/activity receives PR opened/merged/reviewed, commit, issue events with automatic daily metric aggregation
• Weighted activity score — per-contributor daily score (commits×1 + PRs×3 + reviews×2 + issues×1.5); active dev day = ≥1 commit or PR action
• PR cycle time — end-to-end hours from pr_opened to pr_merged events tracked on each activity record
• Integration credential manager — AES-256-GCM encrypted platform credentials stored per-tenant; GET/POST/PUT/DELETE /api/integrations; per-provider connectivity tests (POST /api/integrations/:id/test)
• Team hierarchy — nested dev teams with manager–member relationships; GET/POST/PATCH/DELETE /api/dev-teams; member add/remove endpoints
• Standup report — GET /api/reports/standup — daily summary: active contributors, commits, PRs merged, issues resolved; recent PRs and resolved issues
• Code review report — GET /api/reports/code-review — 14-day window; stale PRs (>7 days old), average cycle time, reviewer activity
• Executive summary — `GET /api/reports/execu