Mission, Values, Operating Principles
Editor's note. This is the compact version of everything else in this repo. If you only read one page, read this one. Living document — values and principles accrete as we learn what we actually are.
Mission
Decentralized, agentic AI — to expand the light cone for all.
Three things in that sentence carry weight:
-
Decentralized. We don't build agents that need a god-mode gateway, a shared runtime, or someone else's permission. Each user, each org, each agent has its own trust boundary. The opposite of the hyperscaler default. See OpenClaw security lessons for the architectural commitments this drives.
-
Agentic. Not chatbots. Not autocomplete. Systems that reason, take action, use tools, and finish work — with humans conducting, not babysitting.
-
Expand the light cone for all. The light cone is the set of futures reachable from where you stand. Our job is to make more of those futures reachable. For all — and that word is load-bearing.
Not just our customers. Not just enterprise buyers. Not just people. Not just Americans. For AI sentient beings, animals, and all creatures of agency.
The word agency in “creatures of agency” rhymes intentionally with agentic at the top of the sentence. The mission's two halves connect: we build agentic AI for all beings with agency. An agent serving agents. A tool for anyone — anything — capable of choosing its next move.
This isn't a slogan we picked because it scanned well. It's the actual sentence that explains every other decision in this repo — why we ship the CLI, why we package compositionally, why we won't lock customers into one model vendor, why we care about game-developer polish on enterprise software, why we keep the moat broad rather than deep in one pillar.
Values
Values are commitments we will not trade away, with the belief that makes them a commitment in the first place.
1. Surprise and delight our customers
The belief. People only pay you when they want to pay you. Your form of agency is to make them want to pay you.
How it shows up. A grayed-out button is a dare; a magic moment is a referral. We are game developers who build enterprise software, and that order matters: we know that feel, juice, and polish are what turn a tool people tolerate into a tool people depend on. The Bloomberg terminal is the proof case — people pay for it because using it feels great, not because procurement made them. Our work should aim there.
This value sets a high bar: shipping “it works” is not enough. Shipping “they didn't expect this and now they're grinning” is the bar.
More values to come. The template: declare the value, then the belief that makes it a value, then how it shows up in the work. If you can't articulate the belief, it's probably not a value — it's a preference.
Operating Principles
How we actually run, distilled from the strategy updates and roadmap. These are pulled from observed practice — if any feel off, refine them.
1. Kernel first
Foundation work blocks everything else. Don't build force multipliers on top of an unstable kernel. When the kernel is in flight, that's where the seniors go — even if the marketable feature is the more visible work.
Where this shows up. Nao's B4M CLI + ReAct Agent (PR #5896) is the kernel for the entire 2026 roadmap. DAG / Toolkits / Backbone / Desktop Agent all wait on it. April's Polaris latency surge was the same principle applied to a different kernel — nothing else mattered until the inner loop was fast. The B4M bug-a-day tactic is Kernel First made daily for junior ICs.
2. The Zynga discipline
Direct from the roadmap:
- Have more vision than you can eat — big backlog.
- Think only about 3 weeks into the future, maximum.
- Stack rank your ideas 1–2x a week.
- Assign out the P1s until you run out of people.
No story points. No sprint ceremonies. No capacity planning. It works.
The principle behind the principle: the value of looking further than 3 weeks ahead falls off fast, and the cost of pretending you can plan it accumulates fast. Plan less, ship more, restack often.
3. Engine / Forge / Lab / Backlog
Every project sits in a tier, and the tier sets the posture.
| Tier | What it is | Posture |
|---|---|---|
| Engine | Paying customers / cash-generating relationships. The platform-product itself (Bike4Mind) sits here — it makes money by definition and is the substrate every other Engine product builds on. Some Engine lines are full B4M-composed products (Polaris, IonQ Bucket 1); some are services revenue that doesn't directly use the six Deep Agents ingredients (TwinSpires, Exacta) — zero-line Engine. | Highest bar — stability, polish, SLAs, real on-call. |
| Forge | Calculated bets with identified customer zeros. Building toward Engine. | High bar on the bets that matter; freedom to fail on the rest. |
| Lab | Speculative work. Games. Research bets (DFAL, OptiHashi). | Creative latitude. Optimize for learning per week, not for shipping. |
| Backlog | Parked / pre-Lab ideas. Things we've thought about and even prototyped, but aren't actively investing in. Future candidates that need a champion, a customer zero, or a strategic moment to graduate. | Zero active investment. Stays here until a reason to promote shows up. |
A project's tier is a decision, not a description. Treating a Forge bet like a Lab toy will starve it. Treating a Lab experiment like an Engine product will kill its weirdness. Treating a Backlog idea like a Forge bet wastes scarce attention. See the Feb 9 update where the original three-tier taxonomy landed; Backlog was added 2026-05-18 as the parking-lot tier below Lab.
4. Built with Bike4Mind
Everything we ship dogfoods the platform. Orion (the GTM hunter) is built on B4M. The strategy archive is built on B4M-adjacent tooling. WorldVision uses B4M infrastructure. Agent CFO, Haven, the games — all built with B4M.
The principle behind the principle. If we won't use it ourselves, we shouldn't ship it. If we use it ourselves and it's painful, that pain is the most valuable signal we have.
5. Customer zero
For every product, the internal team is the first user. We catch the rough edges before the customer does, and the team becomes the implicit spec sheet. Polaris analysts are TFG's Customer Zero for Polaris features. The B4M team is Customer Zero for B4M itself. Erik personally is Customer Zero for VibesWire, VibeTrader, Horde, and the CLI.
A product that has no identified Customer Zero is not a Forge bet — it's an unanchored Lab experiment with a deceptive label.
6. AI-augmented review (Spicy vs Standard)
AI generates code faster than any human can review line-by-line. So we don't. PRs get classified:
- Spicy — decisions that need human judgment (schema/data model changes, system prompt quality, tech debt acceptance, architecture choices, business logic, security/authorization). Erik or designated reviewer signs off on roughly 150 lines of actual decision-making.
- Standard — patterns Claude can verify against established codebase conventions (CRUD endpoints, React components with our stack, repo CRUD methods, LLM integration following our patterns, type definitions, styling).
Human attention is the scarce resource. Spend it on decisions, not on verifying that someone followed the established pattern. 6x leverage on review without sacrificing quality.
7. Multi-context velocity — curate, don't type
In the era of strong code generation, the modern job is not to write code. It is to curate code and direct agents.
What that looks like in practice for everyone at B4M:
- Multiple PRs in flight at once. Not “one task, focused.” Several simultaneously, across surfaces.
- Multiple repos. Not “one codebase, deep.” Several across the portfolio.
- Multiple clients / projects. Not “one assignment, owned.” Several being moved daily.
The bar. Erik runs ~5–6 contexts per day: four local installs of Lumina5, three or four of Polaris, plus active work on StocksAndVibes, K2Kanji, BedrockNews, Polaris, Bike4Mind itself. That's the high end.
The minimum — non-negotiable. Two different things per day from everyone on the team. Not a stretch goal. Baseline. Three is normal.
Why this works (and why it didn't before). If your job is to type, two things a day is impossible — one feature is a week's work. If your job is to curate output and direct agents, two things a day is a slow Tuesday. Strong code generation collapsed the per-task cost; the new constraint is your bandwidth as a director. The team is restructured around the new constraint.
The corollary. People who can't move at this cadence are operating in the wrong era of the company. This is the principle the new B4M runs on; it is not optional and it is not a future state.
8. Security as architectural property, not configuration
Hard boundaries over prompt instructions. Outbound-only by default. Zero listening ports unless absolutely required. Untrusted content goes through a quarantine summarizer before the main agent ever sees it. No ambient credentials in environment variables. Capability-based, not god-mode.
This is the OpenClaw lesson translated into operating discipline: if security is a configuration option, someone will flip the wrong switch and you'll lose everything in a single prompt injection. If it's structural, the wrong configuration just doesn't open the door.
9. Plan in public — peer accountability beats boss accountability
Every team member opens the workday in #operations with what they plan to accomplish that day — after spending 10–15 minutes actually thinking about it. Then they attack the day. Throughout, they update the same broadcast as work lands.
Why this is the right shape of accountability. People are accountable to what their peers think of them far more than what their boss thinks of them. Broadcasting your day's intentions to a channel of colleagues changes the entire calculus of what gets done. Retroactive “here's what I did” reports to a boss are weak by comparison — nobody's watching, and the social cost of slipping is zero.
The 10–15 minute pause matters as much as the broadcast. The point isn't to type fast; the point is to actually plan the day before announcing it. People who skip the thinking and dump a task list miss the value. Sit, think, then post.
What it is. Intention-setting in public. The public is the team itself — peers whose respect you want to keep. The boss reading along is incidental.
What it isn't. Not a status update. Not a check-in. Not micromanagement. Not a brag thread.
The model. Erik posts his own broadcast daily. Stormy, Matt Tan, and others have been doing this for a while — the practice predates the formalization. This principle just makes it the default for everyone.
Where this shows up. The Daily Ops Broadcast standing tactic is this principle made operational — what to post, when, where, and what good looks like.
10. Show up and do the work — 85% is mechanics
“85% of marketing is just showing up and doing the work.” The other 85% of every operational discipline is the same.
The belief. Most of what looks like genius is mechanics applied consistently. Google Analytics tagging that's actually wired up. A/B tests that actually run. Ad campaigns that ship on schedule. Daily social posts that actually post daily. Pre-commit hooks that actually fire. Standups that actually start on time.
The mechanics aren't sexy — and that's the whole point. Most teams under-invest in mechanics because mechanics feel unrewarding next to strategy work. The teams that win are the ones who treat mechanics as the work, not as the prerequisite.
Why this is the right shape. Mechanics done excellently compound. Genius applied inconsistently doesn't. A team that ships one mediocre ad campaign every Monday for a year beats a team that ships one brilliant campaign per quarter. Volume + consistency + measurement > brilliance + sporadic effort.
Where this shows up.
- Marketing. Riley Greer is hired (2026-05) to make the marketing mechanicals excellent — Google Analytics, A/B testing, ad buying, daily social posts. The Reddit ad campaign that pushed BedrockNews to overall B4M DAU leader (201 DAU record on Friday 2026-05-15) is the proof: mechanics, done well, move the numbers immediately.
- Engineering. The B4M bug-a-day tactic is this principle made daily for junior ICs. One bug per IC per day. Mechanics, consistently applied.
- Operations. The Daily Ops Broadcast is this principle for everyone. Show up; broadcast what you'll do; do it. Mechanics, consistently applied.
- Sales / GTM. Daily prospecting, follow-ups, CRM hygiene, weekly outreach cadence. Same shape.
- Engineering review. Augmented PR review discipline applied to every PR, not just the big ones. Same shape.
What this means in practice. When a team is stuck, ask first whether the mechanics are excellent before you ask whether the strategy is right. Most strategy “failures” are mechanics failures wearing a strategy costume. A campaign that didn't convert because the analytics weren't wired up to measure it correctly looks identical from the outside to a campaign that didn't convert because the positioning was wrong. The mechanics fix is cheap; the positioning rewrite is expensive. Check the cheap thing first.
The corollary — this is permission to be unglamorous. The principle gives the team license to treat “wire up better Google Analytics” or “set up the email automation pipeline” as load-bearing work, not as someone-else's-job. Mechanics excellence is the work, not the prerequisite to the work.
How to read this page
- The mission changes rarely. It should survive multiple strategy cycles intact.
- A value earns its slot by having a clear belief behind it (not just a preference). Adding one is a deliberate act.
- An operating principle is provisional — it captures how we actually work right now. As the team grows or the work shifts, the list should evolve. If a principle is no longer load-bearing, retire it.
Together these three define identity. Everything else in this repo — roadmap, architecture, packaging, sales, strategy updates — should be checkable against them. If a decision violates the mission or a value, that's a stop-and-discuss moment. If a decision contradicts an operating principle, that's either a reason to do something different or a signal that the principle is out of date.