Feature list · status as of 21 Oct 2026
Your own multi-agent software factory
Installed on your server, tuned to your team and run together with you. Every feature below carries its real status. Nothing here is a promise dressed as a product.
- live on the production install today
- partial works with limits
- planned designed or decided, not built
- gap not built
Why BrightGears
The best models and agent tools, working together on your infrastructure.
Adapted to how you work and improved every week by people who watch it closely. Points 1 to 5 run on our production install today.
- 1live
A whole factory, run with you
Not a bot you install and forget. A team of agents with leads, helpers and reviewers, threads that are tracked to the end, and a follow-up on every open task. Our specialists set it up with you, watch how it works, and keep improving it. It is part software, part consulting.
- 2live
Made for your team, not for everyone
We have few clients on purpose and think about each install. At setup we adapt the factory to your way of working: your language, your habits, your review culture, how much autonomy you want. It starts working the way your team already works.
- 3live
The best of the market, not one vendor
We pick the best models and agent harnesses available and make them work together: Claude and OpenAI's Codex today, more as they appear. One reviews the other's work. When a better tool comes out, you get it.
- 4live
Your server, your data, your control
Everything runs on your own server. Code, conversations and decisions stay there; nothing goes to a vendor's transcript store. You decide what agents may do, down to the exact command they need approval for.
- 5live
Your existing subscriptions
The factory runs on the AI subscriptions your team already pays for and switches between them automatically when one hits its limit.
- 6partial
Self-improvement a big vendor will not ship
Aggressive, experimental techniques under our own supervision: simulated twins of your team that test the factory on practice tasks, and automatic A/B tests that keep only the habits that measurably work. Twins are live in their first form; A/B tests and the full practice-task loop are in build.
Feature by feature
What the factory does today, and what is still in build.
Runs in the client's infrastructure live
One install per client, on the client's server or cloud account. Code, repos and data stay there.
Uses the subscriptions the team already pays for live
The client signs in its own Claude and Codex accounts from the web UI; gears rotate across them and wait out limits. API keys at API rates are the fallback.
Every thread has a next check live
Each open thread keeps at least one scheduled follow-up: when the gear looks again and why. Closing a thread needs a stated reason.
Team preferences that the system learns live
Gears propose habits from how the team works; a person confirms them; every gear in the install follows them on the next turn. A person-only flag turns a habit into a locked auto-approve rule (today each change needs one admin command).
An agent team, not one agent live
Each thread's gear runs helpers and multi-step workflows (writers, critics, reviewers) and shows each agent's progress in one small status line that stays last in the thread.
Exact-command approvals live
Risky actions wait for a person to approve the exact command, with a use count and expiry. First answer wins.
One private control room live
A 12-screen web UI: all threads and their cards, decisions, subscriptions and limits, routines, team habits, quality pulse, lessons and simulated users. Each thread keeps a persistent working folder on the client machine.
Shared context between threads partial
Each turn gets its own thread's new events plus short lines on what other threads in the channel are doing. Install-wide digests and search are planned.
More than one model provider partial
Claude runs the turns; Codex runs as a helper on its own pooled logins, useful for cross-provider review. Codex as a full turn runner is planned.
Simulated users for testing partial
Each team member has a simulated twin whose behaviour profile is distilled daily from their real messages. It can drive test threads without authority. Closed-loop evals on top of it are planned.
A factory behind every install partial
One core for all clients; improvements in how agents delegate, review and follow up ship to every install. Today the operator rolls updates per install; signed self-updates and cross-client lesson distribution are planned.
Self-improving loop with A/B tests planned
Happiness scoring of every message and reviewed lessons are live. Live A/B tests of preferences on new threads, keeping only the winners, are designed, not built.
Autonomy dial per team planned
From “a person reviews and merges every PR” to “gears merge to main and people check releases”. Today autonomy is set through approvals and preferences; one team-level setting is planned.
In detail
Every area, one line each.
The same inventory our engineers work from, tagged by status.
Where it runs
| Area | BrightGears | Status |
|---|---|---|
| Hosting | Client's server or cloud, one install per client; operator admin over a private network | live |
| Workspace state | Persistent per-thread working folder on the client's machine | live |
| Private network | Inside the client network, no proxy hop | live |
| Regulated data | Stays on client infrastructure (compliance docs not yet written) | partial |
Cost
| Area | BrightGears | Status |
|---|---|---|
| Billing | Client's own subscriptions, rotated; API keys as fallback | live |
| Usage limits | Switches automatically to the next subscription; pauses only when all are at their limit | live |
Work model
| Area | BrightGears | Status |
|---|---|---|
| Intake | Every member message in an invited channel; silent on talk between people | live |
| Unit of work | Thread = card (title, why, now, next, owner, next checks) | live |
| Follow-ups | Mandatory next check per open thread; close needs a reason | live |
| Live steering | New messages enter the running turn at once | live |
| Status in thread | One small status line, always last: state, team, waits, next check | live |
| Agent team | Helpers and multi-step workflows per thread, shown in status | live |
| Schedules | Routines (interval), health round, per-thread checks; wall-clock schedules planned | partial |
Context and learning
| Area | BrightGears | Status |
|---|---|---|
| Cross-thread context | Each turn sees other threads' recent activity in the channel; install-wide digest planned | partial |
| Team knowledge | Preferences: proposed by gears, confirmed by people, applied to every gear | live |
| Quality signal | Happiness score per member message, Pulse, thread metrics | live |
| Lessons | Lessons from closed threads, 7-day client review before upstream | partial |
| A/B tests | Preferences tested live on new threads; keep winners | planned |
| Simulated users | Per-member twin, profile distilled daily from real messages, no authority | partial |
| Closed-loop evals | Sims drive test tasks; regressions blocked | planned |
| Cross-client learning | Reviewed lessons become core defaults for all installs | planned |
Models and tools
| Area | BrightGears | Status |
|---|---|---|
| Providers | Claude turns; Codex helpers on pooled logins; Codex turns planned | partial |
| Connectors | Whatever the client's machine reaches; managed connectors not built | gap |
| Repos | Any git host the machine reaches; GitHub App integration on backlog | partial |
| Files in Slack | Members' attachments land in the thread folder | live |
Control and safety
| Area | BrightGears | Status |
|---|---|---|
| Approvals | Exact command, use count, expiry, first answer wins; web UI | live |
| Locked rules | Managed settings: gears cannot widen their own permissions or hooks | live |
| Roles | Owner, approver, viewer | live |
| Autonomy level | Set per team: manual merge to autonomous merge | planned |
| Sign-in | Private network today; Slack sign-in planned | partial |
| SSO, audit export | Not built | gap |
| Data retention | Client controls the machine; nothing stored at a vendor; no TTL policy yet | partial |
Channels
| Area | BrightGears | Status |
|---|---|---|
| Slack | Yes | live |
| Telegram | Yes (one chat = one thread; topic router designed) | partial |
| Microsoft Teams | Researched: 1.5–2.5 weeks, needs a public HTTPS endpoint | researched |
Pricing and terms
Runs on the subscriptions you already have.
How billing works live
- Runs on the client's existing Claude and Codex subscriptions, pooled and rotated.
- Switches automatically to the next subscription when one hits its limit; pauses only when all are at their limit.
- Fallback is API keys at API rates.
What we do not claim
- Subscription terms: consumer plan terms forbid automated or bot access; Team and Enterprise terms are unclear.
- We have not yet modelled the cost difference, so “10× cheaper” is not a claim we make.
Not built yet
What is next, and what clients have asked for.
Building next
- Live A/B tests of preferences on new threads, with a person approving the winner.
- Closed-loop evals with validated simulated users before any change reaches a client.
- Cross-client distribution of reviewed lessons as core defaults.
- Install-wide shared context: a per-thread now/next digest every gear sees, plus thread search.
- Codex as a full turn runner and cross-provider review as a default habit.
- GitHub App per client, autonomy dial, Slack approval buttons.
Open client asks
- Cost reporting
- SSO and audit export
- Retention policy and off-site backup
- Compliance docs
- The subscription-terms question
Managed connectors, SSO, audit export and an SLA are not built. Gears' repo access via a GitHub App is on the backlog.
See the factory run on your tickets.
Few clients on purpose. Every install is set up with you and improved every week.