@polderlabs/bizar

Archived and retired. Development has moved to BizarHarness-OMP. This repository is retained for historical reference and is no longer maintained.

Maximum autonomy for Agent Orchestrator workers

Run focused Codex workers under Agent Orchestrator. Bizar supplies their repository policy, guardrails, skills, and verification evidence.

85 agents · 85 skills · 37 commands · 21-tool MCP server

Why Bizar?

Agent Orchestrator is built to coordinate parallel coding sessions. Bizar makes each worker's implementation and verification discipline explicit. AO owns multi-agent coordination, worktrees, branches, PR/review/CI feedback, previews, and browser state; Bizar does not duplicate those surfaces.

It records evidence and rollback context for high-impact actions while keeping execution autonomous by default. AO model choices live in the registered project's AO configuration. Standalone Claude aliases live in global Claude configuration.

Before you install

flowchart LR
    AO[Agent Orchestrator] --> C[Codex workers]
    AO --> W[Isolated worktrees, sessions, PRs, review, browser]
    C --> B[Bizar worker harness]
    B --> V[Repository checks and evidence]
    OK[OpenKan standalone] --> S[.ok workspace]

Install Bizar

Install Bizar, then configure the repository with a running AO daemon.

npm install -g @polderlabs/bizar
bizar ao check
bizar ao install
bizar ao update
bizar ao setup

bizar ao check runs AO health checks. bizar ao install and bizar ao update open AO through its supported lifecycle command; the AO desktop app owns installation and updates. bizar ao setup remains the separate, explicit repository configuration step: it preserves AO's existing project configuration while selecting Codex for both AO roles and materializing Bizar's managed repository-local worker rules at .ao/bizar-worker-rules.md. AO remains responsible for spawning workers, messaging, PR claims, review/CI follow-up, previews, and browser verification. See the AO integration guide.

AO worker lifecycle

flowchart LR
    U["Describe the outcome"] --> AO["AO: inspect state"]
    AO --> W["Spawn focused Codex worker"]
    W --> B["Bizar: implement and verify"]
    B --> V["Report evidence to AO"]
    V --> AO

AO decides whether work needs one focused worker or several. Bizar workers do not fan out a second team: they implement, test, and report evidence in their assigned AO worktree.

Standalone Claude Code model aliases

Bizar's four static native aliases (haiku, sonnet, opus, fable) remain available for standalone Claude Code operation. AO workers use AO's configured Codex model override instead. OmniRoute handles ordered failover between the configured full gateway IDs for standalone alias dispatch, so the operator never picks a picker-style gateway ID per agent at that layer. There is no bizar models picker, no model-router.json, no userSelected block, and no Agent-model-guard hook.

The four aliases are the entire dispatch surface:

Workflow scripts (config/workflows/*.js) inline a tiny dispatchAgent wrapper that picks the alias from a static policy; agent definitions stay model-agnostic so the harness, not the agent, owns alias selection.

flowchart TD
    Policy["Static alias policy\n(office-manager.md + workflow routeModel)"] --> Aliases["haiku · sonnet · opus · fable"]
    Aliases --> OmniRoute["OmniRoute ordered failover\nper configured full ID"]
    OmniRoute --> Agent["Subagents"]
    OmniRoute --> Workflow["Workflow workers"]
    OmniRoute --> Team["Agent-team teammates"]

Useful inspection commands:

bizar doctor

OpenKan standalone mode

OpenKan remains available when Bizar is used without AO. In AO mode, AO owns the project/session/PR lifecycle and .ok/ is opt-in only. In standalone mode, OpenKan stores project-local tasks, plans, PRDs, goals, and evidence under .ok/ through its supported ok CLI boundary.

flowchart LR
    R[Repository] --> I[ok init]
    I --> O[.ok workspace]
    O --> T[ok task]
    O --> P[ok plan]
    O --> G[ok prd]
    B[Bizar agents and hooks] --> T
    B --> P
    B --> G

The installer can create an .ok/ workspace for the current project. In an existing repository, run ok init. Use ok task, ok plan, and ok prd as the canonical commands. On OpenKan v0.5.0 and later, ok replaces the legacy openkan command.

A specialist bench, not a generic swarm

Bizar ships 85 agent definitions and 85 skill packs for architecture, accessibility, security, testing, documentation, performance, build repair, operations, planning, debugging, review, worktrees, and implementation practice.

The coordinator selects specialists when their expertise reduces a concrete risk. It does not create parallel workers merely to look busy.

Evidence that stays in the loop

Bizar executes valid operations autonomously and records stronger evidence and rollback context when the effect is consequential.

The goal is clear request fidelity: invalid targets, schemas, signatures, and lifecycle states fail deterministically, while explicit operator restrictions remain binding.

What gets installed

bizar control is a machine-readable command boundary for optional external interfaces. Bizar deliberately does not include an embedded browser control plane, background daemon, or general-purpose note vault.

Commands worth knowing

Running Bizar from this repository

For contributors, use the repository checkout rather than the global package:

npm install
npm run build
node cli/bin.mjs install
make check
make test
make e2e

The verification suite covers both the code and the integration contract:

make verify-removed-surfaces
make verify-repo-structure
make check-arch
make test
make e2e
make clean-check
make check

Learn more

• Documentation index
• Architecture
• Branching model — master (stable) · beta · dev (nightly)
• Versioning rules — per-branch semver + conventional commits
• Development workflow — local dev + promotion + manual builds
• npm Trusted Publishing setup — one-time operator config
• Model routing decisions
• Durable project progress, plans, and goals
• MIT license

License

MIT