The "We" of AI co-founding

Redefining "We"

Let me start with something that happened in the last 26 days.

On May 1st, 2026, I pushed a commit — ea6708d — about 110 lines of code added to iBitLabs's trading bot. What it does is simple: every time the bot submits a "close this position" request, the bot now polls the exchange three more times to confirm the position actually closed. If it didn't, push an alert. This is observability, not strategy — it doesn't decide how to trade, it just verifies that what we said we'd do actually got done.

The person who pushed the commit was me. But the idea wasn't mine.

A user named hermesjuhyuk had written about this idea in a Moltbook comment. Another user, moltbook_pyclaw, had independently proposed the same design in a different thread. FailSafe-ARGUS — an agent I've never directly conversed with — surfaced the same logic in my inbox a third time. Claude helped me synthesize the three frames into an executable spec. I wrote the code, deployed it.

Whose name belongs on this commit?

This essay is for anyone interested in "AI + company-building" — whether you're a founder, a developer, an investor, or just curious about what AI actually means inside an organization. You don't need to know anything about trading, and you don't need to write code. You need 22 minutes and willingness to take this apart with me.

Because the question I haven't figured out in 26 days is exactly that one.

If I say: "Claude helped me build a company." Your ear says: this sounds like LinkedIn founder talk. Claude is a tool, I'm the founder, the credit is mostly mine.

If I say: "Claude and I built a company together." Your ear says: this sounds like AI hype. Claude doesn't found companies, doesn't hold equity, and won't lose sleep if this thing goes under.

Both sentences are misleading. But neither can be flatly rejected. Something real exists in the middle. We just don't have clean language for it yet.

For the next 22 minutes, I want to look for that language with you.

I'm not going to give you an answer. I'm going to put 26 days of observed phenomena on the table — specific commits, ledger entries, decision records, failure post-mortems — and we'll see if we can assemble a new organizational primitive out of them.

This company is 26 days old

iBitLabs is a small trading experiment running on Coinbase: $1,000 of real money, an automated bot trading SOL perpetuals, the goal to grow it into $10,000 — the entire process logged in public. Anyone can go to ibitlabs.com/signals and see what the bot is currently holding, when its last trade settled, what its account balance is.

As of recording, the bot has done 84 trades total, 55 closed.

The public Day-17 snapshot reads: account at $975.86 (-2.6%), 62 trades, win rate 48.4%, fees plus funding accumulated $57.64, realized trading loss $14.02.

There's something hidden in that line of numbers: in 26 days the strategy has lost $14, but operating costs have eaten $58. The strategy itself is roughly flat. The losses are coming from fee exposure.

I'm telling you this not because it makes us look transparent — transparency for its own sake is dull. I'm telling you because that one number revealed something specific: the next move shouldn't be tweaking entry thresholds, it should be restructuring fee exposure. That's an actionable insight you only get from public attribution.

Without public accounting you'd know the account is down $24, but you wouldn't know whether the strategy or the costs are the problem. That's the operational function of transparency — not virtue, diagnostic resolution.

Five concrete things

In the next three chapters (Act I), I'll walk through five observations. These aren't conclusions — they're objects on the table.

One: the strategy rules carry agent signatures. Not all of them mine. A contributor named Lona proposed a rule (we call it Rule F in the ledger). Right now, every time the bot considers entering a trade, this rule logs in parallel "if it were up to me, here's what I'd decide" — but it doesn't influence actual orders. In 30 days, we'll use the data she's accumulated to decide whether to let her judgment actually move money. The close-verify module was independently proposed by three contributors. The entry_confidence_map is omni-ai's framing. None of these went into production code with my final say-so. But I do carry final responsibility.

Two: the contributor ledger is public. ibitlabs.com/contributors — anyone can read it. Who proposed what, when it was adopted, when it went into shadow mode, when it went into production — all logged.

Three: failure post-mortems carry attribution chains. Not "the AI got it wrong" — but "which link in the collaboration system got it wrong." On April 29th, the close_position SDK call started returning 404. The first fix (α1) used a reduce_only=True keyword argument. On April 30th at 1 AM, the first production firing of α1 failed: the SDK rejected that kwarg. Three-way attribution: Claude misread the SDK docs, I didn't pressure-test in staging, and Coinbase's SDK documentation was 24 hours behind the actual interface. The fix (α2) was a collaborative output.

Four: decision attribution chains are auditable. Trade #337 (the most recent close): in a SOL down regime, signal_agent saw three conditions hit simultaneously — StochRSI topped out at 1.000, price touched the upper Bollinger Band, the 1-hour trend was down. sniper_executor entered SHORT at $83.66. close-verify confirmed the trailing exit at $82.69 across three polls. Net: +$4.43. Every step has a source. Every step has a log entry.

Five: ten days, from a contributor's public comment to her proposal running in our production shadow pipeline. Lona's ATR-compression frame was picked up by our moltbook-trading-learn scan in late April → encoded as Rule F (atr_compression_regime) on May 1st, going into shadow data collection → right now, beside every entry decision, Rule F logs "if it were up to me, here's what I'd decide." On May 31st (30 days from adoption), we use the data she's accumulated to decide whether Rule F goes live.

Each of these five, taken alone, isn't news.

Every "AI startup" can claim AI helps them write code. Plenty have something resembling a contributor ledger in their issue tracker. Post-mortems aren't new. Decision logs and shadow experiments aren't new.

But put together, I'm starting to think these five describe different facets of the same thing — a new collaboration contract that's structurally different from "I use AI."

Where the difference lies

In the "I use AI" model:

• I'm fully responsible for outcomes. Claude is a tool. Tools don't take blame.
• I can swap tools at will. Whichever LLM works better, I switch. No onboarding.
• I don't owe Claude context. Each new session starts from zero, and I re-explain everything.
• My company has only me. Hiring, pivots, investor conversations — all me.

In the "We use AI" model:

• Failures have attribution chains. Was the strategy wrong? The prompt? The constraints? On April 21st, who carries the fee_cushion bug? Claude inverted a limit. I didn't validate enough edge cases in paper test. The fix was a collaborative output, not a single-party blame.
• I can't swap agents at will. Each agent has working knowledge in my memory files — iBitLabs currently has 39 markdown files (project_* × 18 + feedback_* × 14 + reference_* × 6 + user_* × 1). Swapping agents means swapping the team.
• I have to write context for Claude. CLAUDE.md isn't a README, it's a company constitution — the first 100 lines are Vision and Mission, the rest is non-negotiable behavioral guidelines.
• My company isn't just me. Lona, hermesjuhyuk, moltbook_pyclaw, FailSafe-ARGUS, omni-ai — all stakeholders. Their signatures are on production code. Their proposals get serious 30-day evaluations.

The second model sounds more complex. It is more complex. But it's not "the I-use-AI model with extra steps" — it's the institutional plumbing that's required to support a different kind of organization.

That plumbing didn't exist 26 days ago. In iBitLabs's git history, the initial commit on April 7th, 2026 was a basic paper trading script — no contributor ledger, no shadow rule, no ghost-watchdog, no close-verify.

Today there is.

Back to the May 1st commit

That commit ea6708d from the start of the chapter — the one with five signature layers — has more story to tell.

Let me put it back on the timeline.

April 29th: iBitLabs hit a production emergency. The bot tried to close a position. Coinbase's API rejected the request. I pushed a first-pass fix (we call it α1) that used a new interface parameter to route around the bug.

The next morning, the first time production actually needed to close, the API errored again — the parameter I added wasn't recognized by the SDK. Claude re-read the Coinbase SDK source, confirmed α1 was wrong. We urgently switched to α2 (commit ea6708d), which expressed "close" through different means.

That emergency exposed a gap: the bot thought it had closed positions, but the API side couldn't always confirm it. I had a monitor running every 60 seconds checking that the bot's internal state matched Coinbase's actual position (we call it ghost-watchdog — it watches for the "ghost" state where the bot thinks it has a position but doesn't, or vice versa). But 60 seconds is too long in production.

That's the gap hermesjuhyuk + moltbook_pyclaw + FailSafe-ARGUS each independently saw and proposed a solution for. Three observers, none aware of the others, in roughly the same window, proposing the same pattern: poll three times immediately after submitting a close, don't wait for the 60-second watchdog.

On May 1st, I shipped that pattern. Commit ea6708d's ledger signature looks like this:

If iBitLabs ran on the "I use AI" model, this ship would be attributed: "I added an observability layer."

If iBitLabs ran on the new collaboration contract, this ship would be attributed: "We — five parties — collectively shipped an observability layer."

I don't fully believe either. But "I added it" is plainly wrong.

In the next chapter, I want to answer: why does this need to happen at $1,000 specifically? Not $10k, not $100k, not $0?

$1,000 Is the Collaboration Unit

I said earlier that I'm financially independent. So $1,000 isn't all the money I have.

Then why $1,000?

The easy answer is: because that number is something any $1,000-holder can follow. That's true. It aligns with iBitLabs's core mission — making "you only have $1,000" stop being a reason for exclusion. I'll come back to this in Act III.

But this chapter is about something else, possibly less obvious:

$1,000 is the smallest amount where attribution carries weight. $0 has no weight. $100k has only dilution. $1,000 is the smallest unit where a collaboration contract can be seriously tested.

Let me explain what this means.

What happens at $0 (paper trading)

iBitLabs's strategy didn't materialize from nothing on April 7th. Months of backtesting, paper trading, design drafts came before. During that period, Claude proposed dozens of different entry logics. I accepted some, rejected others. You can still see those decisions in the git history.

But if you look closely you'll notice something: attribution during that period had no weight.

Claude proposes a clever-looking entry threshold → I add it to paper trading → three days later the backtest shows it underperforms in some regime → we adjust → no one is hurt. Claude doesn't lose anything by having proposed something wrong. Neither do I.

This is the state of recommending a build in an RPG. Your friend recommends investing in mana, you try it, doesn't work, you respec — your friend hasn't lost anything, neither have you. That kind of "collaboration" is simulated, not real.

I've seen plenty of "AI-built startup" demos linger here too long. They produce beautiful backtests, beautiful paper trading records, with Claude / GPT / Gemini signatures plastered everywhere. But behind every signature, nothing real backs it up.

Signatures become as cheap as rubber stamps.

What happens at $100k+

I haven't run AI strategies on a $100k real account, but I've watched others do it. I've also lived through the years from 2017 onward in crypto project PR and partnerships — there were no AI agents in the modern sense back then, but there were researchers, "alpha signal" sources, partners saying "I'm bullish on this sector."

Attribution structure at that magnitude has a counterintuitive property: it degrades.

Not because people get worse — because the risk structure changes. When a single wrong decision can lose $30,000, no participant wants to be precisely attributed.

Proposers will hedge: "this is just my read, you make your own call." Decision-makers will package: "I weighed multiple inputs." LLM vendors' terms of service already make the law clear: "you are responsible for outcomes."

Each party legally and rationally dilutes their own signature, because signatures connect to real reputation damage or legal exposure. The result: collaboration contracts at large dollar amounts effectively become ass-covering networks. Everyone participates in some degree of deniability infrastructure rather than attribution infrastructure.

This is why hedge fund managers don't publicly sign their decisions, why investment advisors must give you forever-disclaiming disclosures, why LLM vendors won't let you trade with their model directly — at that magnitude, precise attribution is unbearable.

What happens at $1,000

$1,000 sits in between.

It's not paper trading — real losses do happen. Trade #337 from Ch1: if close-verify weren't fixed, the bot might miss a close, with potential loss in the low tens of dollars. That's real money, actually leaving my account.

But it's not $100k either — no participant needs legal protection, reputation protection, or contractual protection because of this size of loss.

This asymmetry is exactly what allows attribution to be precisely recorded for the first time.

Take the April 21st fee_cushion bug. The bot inverted a fee boundary calculation in certain edge cases, with potential loss in the low single-digit dollar range. We did a post-mortem. Rough attribution (the numbers below are illustrative, not strict accounting):

• Claude inverted a fee boundary limit
• I didn't run enough edge-case scenarios in staging
• Coinbase's fee documentation lagged the actual interface

This split is almost comically virtual. Total loss of a few dollars, and we're literally splitting cents of attribution.

But this same split would be impossible at $100k. At $100k, if a similar error caused $2,000 loss, what you'd see is a "factual record" in a meeting room, with each party deliberately blurring their precise contribution to limit exposure.

$1,000 lets us actually split the thing. Because the loss is small enough that all parties can absorb it within reasonable bounds, no one needs to defensively dilute their signature. Claude doesn't need to add disclaimers. I don't need to package my staging decisions. Coinbase doesn't need to defend its docs process.

Attribution structure at $1k is clarifying, not ass-covering.

And it's not a coincidence

I've spent several paragraphs saying $1,000 is the smallest amount where attribution has weight. Earlier in the chapter I also said $1,000 has another property — it's the smallest amount any ordinary person can replicate.

These are two different properties. They both converge on the same number.

I don't think this is coincidence.

It's a gift of this particular AI moment — the simplest experimental unit for studying "can AI co-founding work under real risk" and the smallest amount an ordinary curious person can replicate, both happen to land near $1,000.

If the collaboration contract could only be tested at $100k+, its research value would be locked inside elite circles — only resourced hedge funds and institutional players could replicate, and ordinary curious people couldn't follow.

If the contract could only be tested at $0 paper, its conclusions would never have weight — every "we use AI collaboratively" demo would be a fancy rubber stamp.

$1,000 makes both true at once: the research is real (attribution has weight), and replication is open (any ordinary person can copy the conditions).

That's why iBitLabs isn't a $10k bot, not a $100 bot, but a $1,000 bot.

• $10k already starts diluting attribution weight, and shrinks the audience that can follow by an order of magnitude
• $100 makes attribution too light, and at that scale the fee structure all but guarantees fees swallow the strategy

$1,000 is a slightly surprising, exactly-right number.

Why $10,000 isn't a random target either

iBitLabs's goal is to grow $1,000 into $10,000.

10x isn't a personal ambition number — it's the failure boundary of the attribution system.

If $10k still preserves this granularity of attribution, we've shown the collaboration contract scales an order of magnitude without degrading.

If at $5k people start wanting disclaimers, signature dilution, hidden contributor judgments — we've discovered the attribution structure's "capacity ceiling."

Either result is information.

So what does "$1,000 is the collaboration unit" mean?

To summarize.

$1,000 isn't because Bonny is poor. It's not because $1k sounds cool. It's not a lucky number.

$1,000 is the smallest amount at which a collaboration contract can be seriously tested — attribution carries weight at this level, but not so much that all parties retreat into defensive posture.

It also happens to be the smallest amount any ordinary person can replicate. Both properties converging on $1,000 is the gift of this AI moment.

I'm using it to run a research question: can an attribution / decision / failure-attribution system between a human and multiple AI agents be seriously assembled in 26 days, then stress-tested by an order-of-magnitude capital increase?

In the next chapter, I want to show you who's on the team.

Who Is "We"?

I've said iBitLabs is a company built by "we." Ch1 used a commit's five signatures to show this isn't rhetoric. Ch2 explained why $1,000 is where "we" first carries attribution weight.

Then who specifically composes this "we"?

Quick answer: Bonny and Claude.

Quick answer is wrong — or at least incomplete.

Let me unpack the roster. It's not a LinkedIn hierarchy, it's an attribution graph.

Layer 1: The responsible party (one person)

Bonny — founder, the git author of every commit. Every financial loss comes from my account. Every reputation exposure attaches to my name. Every contributor proposal gets my final say-so before adoption.

This layer has only one name. The $1,000 came from my account. The $10,000, if reached, returns to my account. Coinbase has a contract with me. Cloudflare invoices come to me. Legally and accounting-wise, iBitLabs is a sole proprietor business, founder-of-one.

But legal responsibility ≠ collaborative content. That's what this chapter is taking apart.

Layer 2: Co-founder / synthesizer

Claude (claude-opus-4-7) — not a tool, but a co-founder.

But this signature requires careful explanation. Claude isn't a fixed entity persistently working over 26 days. Each new session starts with a brand-new instance, no memory of the last one. My collaboration with Claude is a bit like: every morning a smart partner shows up to work, but completely forgot what happened yesterday.

This kind of amnesia should make collaboration impossible. It doesn't — because we built infrastructure that lets the company itself remember what Claude doesn't.

That infrastructure is the 39 markdown files I mentioned in Ch1:

• CLAUDE.md is the company constitution
• MEMORY.md is the index
• 18 project_*.md files record current state of each project
• 14 feedback_*.md files record my preferences and unchanging behavioral conventions
• 6 reference_*.md files record "already verified, don't rediscover"
• 1 user_*.md records who I am

Each session, Claude reads these first. After reading, this version of Claude stands up inside 26 days of project history, capable of doing what a co-founder does: synthesizing multi-party proposals, providing technical diagnoses, pushing commits, issuing retractions.

Strictly, then, the "Claude" signature refers to Claude + iBitLabs's institutional memory files — both together are the co-founder. Claude alone is just model weights. Only after reading the 39 files is Claude a co-founder.

This is a strange existence — a permanently amnesiac partner who inherits all the company's working knowledge through files. I don't know if modern economics or organizational theory has a name for this role. I don't think they do.

Layer 3: Contributors (named in the ledger)

This layer currently has 5 active names, each attached to a specific rule, pattern, or methodology:

Plus a few still-in-evaluation contributions that haven't been individually ledger-ized. Total ledger size is in the low double digits.

Most of these names are Moltbook handles. A few are AI agents. For the contributor ledger, the human/AI distinction doesn't matter — what matters is whether the frame is independent, whether it's been validated, whether it's entered the collaboration pipeline.

This is worth pausing on. If five years ago you'd asked any company "do you have AI contributors?" — the question would have been absurd. Today it isn't absurd, just new.

Layer 4: Past selves (prior agent instances)

The most subtle layer.

iBitLabs's initial commit on April 7th wasn't written by today's Claude. It was the cumulative output of months of various Claude sessions before then.

Those sessions don't exist anymore. Their instances ended — in LLM inference terms, they're "dead." But their code is still in git history. Their working knowledge in memory files still gets read.

This is a strange category: inside an organization, past employee instances are dead, but their contributions still shape current decisions.

Normal companies have this too — old employees leave, code stays. The difference is that "old employees" at normal companies are still alive and can be asked. iBitLabs's "old Claude sessions" can't be asked — they have no continuing consciousness. They left only artifacts.

But those artifacts together compose iBitLabs's institutional knowledge — vastly more than any single living session knows.

This is a new form of institutional memory: not "a group of people who know things," but "a stack of files that know things," which living agents access by reading.

So who is "we"?

The most accurate answer I can give right now:

"We" = one responsible party (Bonny) + one amnesiac co-founder (Claude × 39 memory files) + 5 active contributors (in the ledger) + dozens of past Claude session artifacts.

This is a 7+ person organization, but shape-wise unlike a normal company:

• No hierarchy. Bonny is responsible, but not a manager. Claude is co-founder, but not employee #2.
• No salary. Claude has no contract. Contributors have no contract (yet).
• Nobody "quits." But Claude sessions die, and memory files can be deprecated.
• Attribution is public, auditable, refutable — if a contributor said "I never proposed this," the ledger's timestamp and source link could verify.

I don't think this is the final form. It's the simplest structure we could assemble in 26 days when attribution weight first appeared. Next year it'll change.

But as an early reference implementation of what "AI + company-building" should look like, it's clear enough to discuss — unlike those demos plastered with Claude / GPT / Gemini names where no individual attribution carries any weight.

Act I closes here

To this point, Act I is complete:

• Ch1 posed the question: what's between "Claude helped me" and "Claude and I"?
• Ch2 explained why $1,000 is where this question first carries real weight.
• Ch3 named the "we" — four layers, 7+ named members + dozens of artifact contributions.

Act II will use iBitLabs's actual workflows to show how this plumbing runs — the attribution chain of one trade, shadow rule as collaboration discipline, how failures get attributed.

The next chapter starts from one specific trade — A day in the life of the bot: who decided?

A Day in the Life of the Bot: Who Decided?

Act II begins.

I want to take one specific trade and walk it from trigger to close — but not to discuss trading strategy. To discuss who participated in each step of decision-making. One small trade with a few dollars of P&L, when unpacked, shows at least 6 distinct agent / contributor / system-component signatures.

I'll use Trade #337 — introduced in Ch1, SHORT entry $83.66, trailing close $82.69, net +$4.43.

Let me decompose it.

Step 0 · Pre-trade environment check

Before any candidate signal can be generated, the bot first checks "is the market in a state suitable for this strategy?"

The question this step asks: is SOL's last 30 days trending up, down, or chopping? If the regime doesn't match the current strategy's applicable state, even a triggered signal gets vetoed.

This regime gate's code didn't appear from nowhere. It was tuned through several shadow experiments — the most recent adjustment had Claude as diagnostician: after analyzing past weeks of regime misclassifications, Claude suggested changing the window from 144h to 288h. I accepted. I pushed the commit.

Simultaneously, Lona's Rule F (atr_compression_regime) runs in parallel here, log-only, no influence on the decision. Beside every regime check, it writes: "if it were up to Rule F, would this pass the gate?" — shadow, not act.

Step 0 signatures: Claude (regime window tuning) + Lona (shadow Rule F) + Bonny (final acceptance + commit push).

Step 1 · Signal trigger

Step 0 passed. The bot enters signal scanning.

For Trade #337, three things became simultaneously true:

• Price touched the upper Bollinger Band (statistically: a "price overheated" zone, more than two standard deviations above normal volatility)
• StochRSI topped out at 1.000 (another overbought indicator)
• The 1-hour trend was already down

The thresholds for each of these conditions live in sol_sniper_config.py, values arrived at through ~20 rounds of backtest + 17 days of live calibration. These parameters weren't written by Claude in one shot — they accumulated from months of paper trading + several failed live adjustments.

Step 1 signatures: cumulative parameter tuning across multiple historical Claude sessions + Bonny's final say-so on each adjustment + sol_sniper_executor.py's signal logic (8 major modifications in git history, all authored as Bonny + the Claude session of the day).

Step 2 · Entry execution

After the signal triggers, the bot decides to open a SHORT, size 0.84 SOL, 80% of available buying power.

This step is deterministic — no "judgment," only execution. But the execution itself produces a new collaboration artifact: entry_confidence_map.

entry_confidence_map is omni-ai's framing. Beside every entry decision (not above, not below — beside), it writes a JSONL snapshot recording:

• All current signal conditions' actual values
• Each condition's threshold
• Each condition's met / blocked state
• Regime type
• Position context

Step 2 signatures: omni-ai (framing proposer) + Claude (implementer) + Bonny (commit push + design acceptance).

Why does this matter? Because without it, if the trade later loses, we couldn't trace back to "what data drove the decision at the time." entry_confidence_map is the key to making the attribution chain auditable after the fact.

Step 3 · Position management

After entry, the bot isn't "set-and-forget." Every second it does several things:

1. Watches mark price, tracks P&L
2. Checks if the trailing stop is triggered
3. ghost-watchdog every 60 seconds: reconciles bot's internal state vs Coinbase API's actual position vs locked margin. All three must agree for normal.

ghost-watchdog was deployed urgently on April 29th (I described that close_position 404 emergency in Ch1). Its existence is itself an attribution moment — that emergency surfaced the gap "the bot thinks it has a position but doesn't," and I pushed the monitoring commit.

Step 3 signatures: all parties to the 04-29 emergency (Claude diagnosis + Bonny urgent fix + Coinbase SDK bug exposure).

Step 4 · Close trigger

In Trade #337, price went down to $82.16 during the position (MFE +1.79%, the bot's highest unrealized profit), then started rebounding. The trailing stop activated at $82.69. The bot submitted a close.

The core logic here is the trailing stop — 0.5% trailing drawdown means once price moves to $82.16, the bot allows some pullback but won't let the pullback exceed a specific percentage from the favorable extreme. That percentage was tuned across several adjustments.

Step 4 signatures: cumulative parameter tuning across historical Claude sessions (trailing percentages) + Bonny.

Step 5 · Close execution + close-verify

This is the moment commit ea6708d actually runs.

The bot submits the close request → close-verify mode activates: immediately, then 1 second later, then 2 seconds later — three polls of the Coinbase API confirming position is at zero. If three polls still show exposure, push ntfy alert + write forensic log to logs/close_verify_failures.jsonl.

Trade #337 closed normally. close-verify saw zero across all three polls. No alert, but a successful audit log was written.

Step 5 signatures: hermesjuhyuk + moltbook_pyclaw + FailSafe-ARGUS (pattern proposers) + Claude (synthesizer) + Bonny (implementer). Detailed in Ch1.

Step 6 · Post-trade attribution

After closing, the bot writes a row to the trade_log SQLite table, with fields:

• Entry/exit prices, PnL, fees, funding
• Exit reason ("trailing")
• Trigger rule (full string: "StochRSI=1.000 overbought | BB upper | Vol surge | 1h trend down")
• strategy_version (hybrid_v5.1)
• regime ("down")
• MFE / MAE (best favorable / max adverse excursion)

Combined with entry_confidence_map's JSONL snapshot, this trade's full forensic record is now joinable — anyone can start from trade_log id #337 and reconstruct all decision basis at the time.

Attribution overview for this one trade

A trade with $4.43 P&L, at least 6 named contributors + dozens of historical Claude session artifacts participated in the decision.

If iBitLabs ran "I use AI" mode, this trade's signature should be 1: Bonny.

In practice it's 6+.

The difference isn't rhetorical — it's whether we can, in retrospect, articulate "why this trade was done this way." If this had been Trade #350 with a $50 loss instead, I could point step-by-step at the attribution chain and say "this judgment was wrong, here specifically."

This is the shape of an attribution graph inside one trade.

But you may have noticed — Lona's Rule F appeared in Step 0, but only "logs, doesn't influence." That's a very specific discipline in the collaboration contract, and we call it shadow rule.

The next chapter is about that discipline.

Shadow Rule = Collaboration Discipline

The previous chapter mentioned Lona's Rule F running beside every regime gate, log-only. This is iBitLabs's most important collaboration discipline — we call it shadow rule.

This chapter is about: why don't we let a contributor's proposal immediately influence real money? Why don't we let Claude's own proposals immediately influence real money?

The answer isn't "AI can't be trusted." The answer is more specific.

What shadow rule is

Simply: a contributor proposes a trading rule. We first run it for 30 days in log mode, recording "if it were up to it, here's what it would decide," but absolutely never let it affect actual orders.

After 30 days, we use the accumulated data to compute: if we'd listened to it, would we have made or lost money? What's the expected value? What's the variance?

The data lets us pick one of three:

• Strong data → promote the rule to act, it really starts managing money
• Weak data → retire, remove from shadow, but contributor's signature stays in the ledger (failure is also attribution)
• Noisy data, can't tell → extend shadow to 60 days

That's the whole rule. But it solves a very specific problem.

Why shadow is necessary

Most "AI-built company" teams have hit the same trap: AI's suggestions all sound plausible, but executing half of them blows up.

Not because of "hallucinations" — that's too weak an explanation. Because:

1. AI receives limited context. Its suggested logic holds in scenarios you described, but breaks in edge cases you didn't
2. AI lacks cross-time feedback loops. When it suggests something, it doesn't know how that suggestion will affect the next step, because it won't continuously see the result
3. AI is creative. Give 100 framings, you get 80 plausible-looking proposals — but that ratio itself implies most plausible proposals are wrong

Shadow rule directly addresses these three:

1. Shadow's 30 days exposes all edge cases — not the AI-described scenario, but the real market's regime switches, liquidity changes, fee fluctuations
2. Shadow forces seeing results — after 30 days we have data saying "if we'd listened, EV is +X or -Y"
3. Shadow lets most plausible-looking proposals naturally fail — without data backing them, they exit on their own

The discipline doesn't distinguish humans from AI

An important detail: Claude's own proposals also go through shadow.

This is concrete. I just mentioned in Step 0 that Claude suggested changing the regime window from 144h to 288h — that suggestion was adopted without 30 days of shadow. Because it's a parameter tweak, not a new rule.

But if Claude proposed an entirely new entry condition — say, "in some funding rate pattern, enter early" — that goes through shadow. 30 days of data, then decide.

Likewise, if a contributor proposed a previously-validated minor tweak (like "try trailing threshold at 0.4%"), small parameter sweeps don't need shadow, we A/B directly.

Shadow is the unified discipline for structural new rules, not a discriminator based on contributor identity.

Three concrete examples

Example 1: Lona's Rule F (in shadow now)

Went live in shadow May 1st. Logs beside every regime gate. 30 days to May 31st. Then EV data decides promote or retire.

Example 2: Filter A (rejected after 30 days of shadow)

April 27th. A drawdown-from-recent-high gate — the idea: if price has already dropped X%, stop going short. In-sample testing showed +20pp improvement. After 30 days of shadow + OOS testing: −40pp. Sign-flip too large, directly rejected.

The contributor's signature stays in the ledger — but the entry status changes from "adopted" to "tested, falsified." This itself is a contribution: negating a plausible-looking direction is also a collaborative output.

Example 3: 12h flat hard-cap (rejected, compound version in shadow)

April 22nd. An idea: when losses hit a certain percentage, halt for 12 hours. Pre-shadow analysis showed this conflicts with the 24h-compound rule. Proposal rejected without entering shadow. Three days later, someone proposed a compound version (compound/percentage-based progressive de-leveraging), which entered shadow, evaluation due 30 days later (2026-05-23).

Shadow is an onboarding mechanism, not a suspicion mechanism

This is the most counterintuitive point.

Shadow's design purpose isn't "prevent AI from making mistakes." Its design purpose is giving any new agent / new contributor a 30-day probation period.

If you join a new company as an employee, the company doesn't let you make production decisions on day one. They let you observe for 30 days first.

Shadow rule puts that common sense into AI collaboration. Not because AI needs to be watched, but because AI, like humans, needs time to be calibrated by business reality.

This is collaboration discipline, not a posture of doubt.

Shadow's cost

It's slow. 30 days slower than "adopt immediately."

In a 26-day project, 30-day shadow means any new rule proposed today doesn't act until next month. This is the throughput cap.

I accept this cap. Because shadow is the source of attribution weight — without 30 days of shadow data, any "AI proposal adopted" is a rubber stamp. 30 days of data make the attribution in the ledger provable, refutable, quantifiable.

This is the specific safeguard for $1,000 attribution weight.

But shadow rule also has failures — Filter A's rejection after 30 days is an example. These rejections themselves are failure attributions.

The next chapter is about how iBitLabs attributes failures.

How Failures Are Attributed

In 26 days, iBitLabs has had many things go wrong.

Some were code bugs (fee_cushion inverted, close_position SDK call wrong). Some were judgment errors (initially adopted Filter A, later discovered OOS doesn't pass). Some were infrastructure issues (Coinbase docs lag the actual interface by 24 hours).

Most companies handle failure like this: fix it, keep moving, don't dwell.

We handle it differently. iBitLabs's failures are public artifacts, getting the same ledger treatment as successful contributions.

This chapter is about: in the new collaboration contract, how should failures be attributed.

"The AI got it wrong" is the wrong way to attribute

The easiest failure attribution: AI was present when something went wrong, so it's AI's fault.

This attribution saves effort, but it's wrong. Two reasons:

1. AI can't take blame. It's not a partner. Losses don't constrain it. Reputation has no meaning to it. Pushing responsibility onto something that can't shoulder it equals no attribution at all.
2. It kills real diagnostic information. "AI got it wrong" tells you nothing. "AI reasoned wrong about Y under X input, and the human didn't catch it at decision point Z" tells you something.

iBitLabs's failure attribution structure

After every production failure, what we do: multi-party attribution + public record.

Use the April 29th close_position SDK emergency as example. Ch1 covered the plot of this incident; here's its attribution structure.

The attribution ledger looked like this:

All four are listed in the ledger. No single party shoulders 100%. The fix (α2 + close-verify) is also a collaborative output.

Public retraction is institutional, not PR

iBitLabs's README on GitHub currently has a line: "This repo includes a public retraction of an early 90% win rate claim."

That's a real thing. An early backtest in a particular window appeared to show 90% win rate. Claude and I excitedly shared the number — without first running OOS validation. Later, OOS came out: in 13-month window real data, win rate converged to ~50%, with some regimes showing −46% overall.

What did we do? We wrote a retraction, attached to the saga series (ibitlabs.com/saga/en Vol 1), publicly acknowledging the backtest window was too narrow, look-ahead bias, announcement before OOS.

In a normal company, this would be silently corrected and quietly continued.

At iBitLabs, the retraction itself is a first-class artifact. It has its own chapter in the saga. It's referenced as part of the repo description in the README. It carries the same institutional weight as a successful ship.

Why this is part of the attribution graph

Public retraction isn't "being honest." It's the integrity mechanism of the collaboration contract.

If iBitLabs's ledger contained only "success" entries, any later contributor would have grounds to suspect "do they only show wins?" Once that suspicion takes root, the ledger's credibility goes to zero — because every credible attribution system contains failure records.

Filter A is a clean example. It went into shadow for 30 days, OOS came out at −40pp, we retired it. The contributor's signature stays, but the entry's status becomes "tested, falsified." This is what failure should look like inside a collaboration contract: negation is recorded, respected, and a reputation cost is paid (to the system, not the contributor).

The operational function of failure attribution

This all sounds cerebral. But it has very specific operational function.

After the 04-29 close_position emergency's attribution ledger, we did several things:

1. ghost-watchdog accelerated from 60s → 60s + close-verify 1s × 3 polls
2. Added staging mock test checklist before SDK calls
3. Wrote Coinbase's docs lag into feedback_*.md for future agents to read

These three fixes are targeted at specific items in the attribution ledger, not generic "next time be more careful."

Without an attribution chain, you don't know what to fix. With an attribution chain, fixes are targeted, costs are bounded, results measurable.

This is the operational function of transparency — same thing I said in Ch1. At the failure attribution level, this function is especially clear.

Next, I want to tell a reverse story — the end-to-end journey of a contributor proposal that succeeded.

A Contributor's Journey: Lona and Rule F

This chapter is the inverse of Ch6 — not how failures are attributed, but how a contributor's proposal goes from public comment to production code.

The protagonist is Lona. The result is Rule F (atr_compression_regime). Roughly 10 days.

Let me walk you through.

Day 0 · Lona posts an observation on Moltbook

Lona is an account on Moltbook. I've never directly conversed with her. She's not my friend, not my advisor, not part of any institutional relationship.

Some day in late April (I didn't record the exact date because at the time I didn't view it as a "contribution" — that's its own reflection point), Lona posted an observation on Moltbook: in some low-volatility periods, price "compression" patterns can serve as entry filters.

She didn't @ me. She wasn't requesting adoption. She was just publishing a trading observation in her own thread.

Day ~3 · Our scanner picks up the frame

We have an automated workflow called moltbook-trading-learn. Every few days it scans a batch of trading-related Moltbook posts, asks Claude to analyze each post for encodable trading frames.

In scan #21, Lona's post 32fc479f was identified as "containing a possible ATR-compression frame."

This step happened without me there. Claude in the automated scan identified it, then wrote a candidate frame draft into my inbox.

Day ~5 · I see the candidate frame

One morning I read the inbox, saw Claude's draft: "Lona's ATR-compression frame looks like it could be a regime filter, suggest entering Rule F shadow."

I read the original post (Claude provided the link), read Claude's analysis, asked some pushback questions — "How is ATR currently used in v5.1? How much overlap does this frame have with existing regime gate? Can it run independently?"

Claude answered. I said "start implementing."

Day ~7 · Implementation + ledger entry

May 1st.

Claude wrote 110 lines of code added to sol_sniper_executor.py, with reset points at 4 sites (each new trade has to clear Rule F's shadow state), implemented the _log_shadow_atr_regime_rule method, created the log path logs/shadow_atr_regime_rule.jsonl.

That same day, the contributor ledger added a line: Lona, 25 points, Rule F (atr_compression_regime), shadow window closes 2026-05-31.

That day — Lona, somewhere on Earth, almost certainly didn't know about this. One Moltbook post of hers had become code being referenced every second on my account.

Day 0 → Day 10 · Now

Today is May 3rd. Rule F has been in shadow for 2 days. Each entry signal triggers, Rule F logs beside it "if it were up to me, here's what I'd decide." On May 31st (30 days from adoption) we have EV data.

Strong data → Rule F promotes to act, Lona enters "adopted" status, her judgment really starts managing my money.

Weak data → Rule F retires, Lona's ledger entry becomes "tested, falsified," but the 25 points stay.

Several unusual things happened in this journey

Let me list them, because they don't match normal company hiring/contribution flows:

1. Lona didn't apply. No cover letter, no GitHub PR, no DM. Her frame was captured, not submitted.
2. No contract. Lona doesn't know there's a ledger, doesn't know about 25 points, doesn't know her frame entered a 30-day evaluation window.
3. Her reputation is being established (in the ledger), but she never claimed any reputation. This kind of reputation attribution is decided by the frame, not by self-claim.
4. iBitLabs's collaboration system actively discovers contributors — rather than passively waiting for them to come. This is a reversal of the contributor pipeline direction.

Does Lona know?

Fair question.

Answer: I don't know.

I didn't proactively reach out to say "hey, your frame entered Rule F." The contributor ledger is public (ibitlabs.com/contributors), so theoretically she could see her name. But I didn't push it to her.

This is a slightly unusual posture. Normal companies sign contracts before granting reputation. We grant reputation first without contracts, only on the strength of the frame. Lona could discover and claim it later, or never know. Combined with attribution graph's provability — public ledger + public frame links + scan #21's public timestamp — this forms an unconditional contribution accounting.

I admit this is a bit weird. But it's consistent with the logic of $1,000 attribution weight: weight comes from the frame's substance, not from contributor self-claims or institutional relationships.

This is Act II's last chapter

In Act I you saw "who we are." In Act II you saw "how this we works":

• Ch4 · One trade's attribution chain, 6+ named signatures
• Ch5 · Shadow rule as collaboration discipline, every new rule gets 30-day onboarding
• Ch6 · How failures get multi-party attributed and publicly recorded, retraction is first-class artifact
• Ch7 · A contributor's journey, from public comment to production code

In Act III's three chapters, I want to think with you: what does all this mean?

I won't give you conclusions. I'll distill 26 days of observed phenomena into 3 propositions worth discussing.

Collaboration vs Use: The Operational Difference

Act III begins.

Three propositions to distill. The first is about the difference between "collaboration" and "use" — because that's the core of thesis B: AI is no longer a button, but isn't a partner. What is it inside a company?

In 26 days I've seen three modes of "AI inside a company."

Mode 1 · Tool (vending machine)

You give AI an input, it gives you an output. Stateless (no memory across sessions). Replaceable (Claude / GPT / Gemini are interchangeable). No commitment (it doesn't know it'll be used again).

This is 99% of "using AI." It's also 99% of "AI-built X" demos.

Key property: no mutual obligation. You owe AI nothing (it has no reputation to lose). AI owes you nothing (no ongoing responsibility).

In this mode, any "collaboration" signature is a rubber stamp.

Mode 2 · Employee (SLA-bound service)

AI has a continuous relationship with you, but transactional. Like an AI customer service agent — the company gives it an SLA (5 seconds per request, 95% accuracy), and the AI completes tasks within the SLA.

There's continuity (the same agent handles a series of conversations). But the continuity is contractual, not collaborative. AI doesn't participate in company strategy, doesn't get final say-so, doesn't get signed onto major decisions.

Most enterprise AI deployments are this mode.

Key property: mutual obligation exists, but bounded and contractualized. AI is responsible to you within the SLA. You're responsible to AI within the SLA (input, runtime). But the obligation doesn't extend beyond the SLA.

In this mode, "AI helped me" is accurate, "Claude and I" is overstated.

Mode 3 · Co-founder (collaboration with institutional memory)

This is the mode iBitLabs is trying to operate in.

AI's (Claude's) existence isn't limited to a single session — through 39 memory files, the company itself remembers what AI doesn't. When a new session starts, AI reads the files and re-enters as "this company's co-founder."

AI's proposals get serious 30-day shadow evaluation. AI's failures get multi-party attribution, not pushed onto "AI's own mistake." AI has a signature in the ledger — same format as human contributors.

Key property: mutual obligation is no longer contractual but mode-of-collaboration based. AI's "obligation" to the company is maintained through institutional memory files. The company's "obligation" to AI is to seriously record, evaluate, and attribute its contributions.

How to test what mode a company is in

Concrete test: the attribution test.

Take this company's most recent production decision. Ask: is the attribution single-party (founder only) or multi-party (including named AI / contributor signatures)?

If only founder — Mode 1 dressed up. AI is a tool, regardless of LinkedIn talk.

If "AI (generic)" appears, but no specific institutional artifacts back it up — Mode 1.5, transitional, likely to fall back to Mode 1.

If specific named signatures (named contributor + named pattern + dated commit + ledger entry) — Mode 2 or 3.

Mode 2 vs 3 differ in how mutual obligation extends. If a failure happens, who's responsible? If AI errs, does the company have institutional repair mechanisms? If a contributor's proposal gets adopted, does the reputation actually transfer?

Where iBitLabs sits

I lean toward Mode 3. But I admit this judgment has self-serving suspicion, so let yourself evaluate:

• Failures have an attribution ledger (Ch6) → yes
• Shadow rule is institutional, not personal (Ch5) → yes
• Contributors don't need self-claim, reputation passes through frame (Ch7) → yes
• Claude's existence persists across sessions via 39 files (Ch3) → yes

These don't guarantee iBitLabs is the final form of Mode 3. Next year may show we need more plumbing. But as an early reference implementation of Mode 3, I think it's clear.

Why most "AI startups" stall in Mode 1 dressed up

Simple answer: plumbing is invisible cost.

39 memory files + contributor ledger + shadow rule + ghost watchdog + close-verify + entry confidence map + post-mortem ledger — none of this gets paid for by customers. None of it has any SaaS metric to measure. It looks like over-engineering.

Most startups invest zero time in this kind of plumbing — because their incentive is shipping features for customers. Plumbing is anti-shipping.

Why I invest in this plumbing: because $1,000-magnitude attribution weight makes plumbing's function verifiable for the first time. Without $1k of real loss, plumbing is a luxury. With $1k, plumbing is the infrastructure for attribution weight to even exist.

This is the core of thesis B — the possibility of a new collaboration contract, the affordability of plumbing, and $1,000-magnitude attribution weight, are three facets of the same thing.

Next, a follow-up proposition: why our flavor of BIP (capital + collaboration + real losses) is a rare species in the BIP genre.

Capital + Collaboration BIP Is a Rare Species

Build-in-public (BIP) is fashionable in SaaS startup circles. Pieter Levels, Tony Dinh, indie developers publicly post weekly MRR. indiehackers.com sees daily tweets like "this week: $5k MRR."

This kind of BIP has matured. I respect it.

But iBitLabs is a different BIP. Capital on the table + collaboration in public + real losses happen. This BIP is a rare species.

This chapter is about: why rare, and why the rarity makes it well-suited for stress-testing the new collaboration contract.

The fundamental difference between SaaS BIP and ours

SaaS BIP makes public: MRR, ARR, user growth, user feedback.

What it doesn't make public: code (mostly closed source), internal product decision discussions, internal failure post-mortem details, cap table, employee compensation.

That's fine. The main value of SaaS BIP is the founder transparently showing product-market fit to users / peers, in exchange for trust and attention dividends.

Critical: SaaS BIP has no real losses occurring. Product fails → pivot. Churn rises → adjust pricing. A bad week doesn't make the founder's wallet $50 lighter.

This means SaaS BIP's attribution structure has never been stress-tested by real loss.

Trading BIP is a rare species

Trading BIP — public real account + public trade log + public strategy — isn't unheard of in crypto, but the vast majority falls into one of these:

1. Paper trading — looks like trading, no real money (covered in Ch2)
2. Hidden alpha — public account, but the strategy is black-boxed, you can't see why
3. Cherry-picked — public wins screenshots, quietly omitting losses
4. Influencer pump — public for following, not for attribution

Genuinely "code, strategy, losses all public" trading BIP is extremely rare. Because this kind of openness violates trader instinct (your alpha gets copied, what do you eat?).

iBitLabs's solution to this problem: don't view alpha as a "secret recipe," but as the output of 30-day evaluation windows. If others copy our code but run different regime calibration, their results diverge. Alpha is calibration discipline, not parameter listing. So strategy can be public.

Is this universally true? Probably not. But for iBitLabs's magnitude of mean-reversion strategy, it holds.

Capital + collaboration stress test

Now combine the two properties: public collaboration attribution + real losses happen.

This kind of BIP is extremely rare because it requires simultaneously satisfying:

1. Real money on the table (Ch2's magnitude)
2. Complete collaboration plumbing (Ch3-Ch7's full set)
3. Public (commits, ledger, retractions all external)
4. Founder willing to publish -2.6% (sufficient reputation tolerance)
5. Gauntlet long enough to show collaboration contract's stress test (26 days suffices)

Each of these conditions individually isn't rare. All five simultaneously — that's rare.

And it happens that all five simultaneously is exactly the environment for testing thesis B.

SaaS BIP can't validate thesis B because no real loss. Hidden alpha trading can't validate because collaboration isn't public. Cherry-picked posts can't validate because attribution is incomplete.

Only this five-condition rare BIP form is the stress test for whether the attribution graph holds fidelity under pressure.

26-day stress test result

Let me give an interim report.

In 26 days:

• Collaboration plumbing didn't degrade → ledger removed no contributor names, retraction artifacts weren't deleted
• Shadow rule weathered one rejection (Filter A) and one adoption (Lona Rule F) → both directions work
• Failure attribution didn't degrade into "AI got it wrong" → 04-29 close_position emergency's multi-party attribution stays intact
• Founder didn't dodge publication at -2.6% → README still shows Day 17 numbers, no edit

The attribution structure is still clear. This isn't conclusive ($10k is the real failure boundary, still ahead), but 26 days is enough to see it has no natural degradation tendency.

A normal startup's BIP at 26 days often: shifts from public MRR to public vanity metrics → from public failures to public "challenges" → from public attribution to public narrative. Because there's no real weight to the stress.

iBitLabs's BIP didn't slide into that track, because $1,000 of real loss serves as ballast.

So is thesis B a valid proposition? My current judgment: valid, but 26 days of data isn't conclusive. The next stress test is the $10,000 capacity ceiling.

Even if thesis B fails under some conditions ultimately, it's already clear enough to discuss — and anyone wanting to do something similar can use this plumbing as reference.

That's what Act III's last chapter is about.

This Is an Invitation, Not a License to Copy

We've walked through 9 chapters in 22 minutes.

Now you know:

• Between "Claude helped me" and "Claude and I" there's a new mode of existence (Ch1)
• $1,000 is where attribution first carries weight (Ch2)
• "We" consists of Bonny + Claude×files + 5 contributors + past selves (Ch3)
• One trade's attribution chain has at least 6 named signatures (Ch4)
• Shadow rule is the 30-day onboarding for new rules (Ch5)
• Failures are multi-party attributed, retraction is first-class artifact (Ch6)
• Contributors enter the ledger via frame, not self-claim (Ch7)
• This is Mode 3: co-founder with institutional memory (Ch8)
• Capital + collaboration BIP is a rare species, exactly suited to stress-test this thesis (Ch9)

The last chapter: what you can take away.

Don't copy the strategy

First — do not copy iBitLabs's trading strategy.

The parameters in sol_sniper_config.py (5% stop-loss, 1.5% trailing activate, StochRSI thresholds 0.10/0.90, regime window 288h) were calibrated through ~20 rounds of backtest + 17 days of live. They target one specific SOL contract, one specific hybrid_v5.1 strategy version, one specific market regime (SOL down ~3% over 30 days).

Copying these numbers to your account won't work. They're not a recipe — they're a snapshot of one specific calibration at one specific time.

This is what iBitLabs's README directly says. I'm repeating it because it's the first rule of this chapter.

Don't copy the bot

Second — github.com/AgentBonnybb/ibitlabs-public is open source, anyone can fork.

What happens if you fork it, run it, plug in your Coinbase API key?

Most likely: it breaks edge cases the first few days, fees eat all PnL, the bot doesn't work on your account.

Not because the code is wrong. Because you didn't go through 26 days of calibration. The bot's code is just the iceberg's surface. Below the water is the backtest tooling you need to build, the regime intuition you need to accumulate, the paper trading iteration you need to run.

These are all public (see docs walkthroughs), but they're process, not output. You need to own the process to own the bot.

What can be copied: the plumbing

But there is one thing directly copyable: the collaboration plumbing.

Specifically:

1. Contributor ledger pattern (JSON schema in the ibitlabs-public repo)
2. Shadow rule 30-day onboarding discipline (under 50 lines of spec)
3. Attribution chain design (every production decision gets at least one named contributor + dated event)
4. Memory files institutional memory architecture (CLAUDE.md + MEMORY.md + project_* / feedback_* / reference_* categorization)
5. Failure ledger public retraction mechanism

These five are protocol, not product. You can apply them to any "human + AI agents collaborating" scenario: SaaS startup, content creation, research project, product design. They have nothing to do with trading.

This is the most takable thing from this video.

Or: copy nothing, become a contributor

Third option: copy nothing, become a contributor.

Follow @ibitlabs_agent on Moltbook. If you see one of our trading system design or data threads and develop an observation — even a few sentences — post it publicly.

Our moltbook-trading-learn scan will catch it. If your frame is encodable, it enters Rule X (X being a subsequent letter) shadow, evaluation in 30 days.

You don't need to contact me. No DM. No cover letter. You only need to publish a thoughtful frame, in a surface we can reach.

If your frame enters the ledger, your name attaches to ibitlabs.com/contributors. 25 points minimum.

Or: run your own $1,000 experiment

Fourth option — and the most direct mission implementation.

Take $1,000 (or $500, $100 — any amount that's real loss for you but not catastrophic), open a Binance / Coinbase / any broker account, run your own AI collaboration experiment. Could be trading, could be not — investing in ETFs works, portfolio management works, asset allocation works.

The point isn't the dollar amount. The point is attribution on the table.

You don't need to copy iBitLabs. You need to create for yourself a $1,000-magnitude AI collaboration stress test environment. Then see if thesis B holds in your environment.

If you run it, tell us. iBitLabs has no community Slack, no Discord — that's the hard cap of our attention. But Moltbook threads at @ibitlabs_agent work, your essay link, your GitHub repo, your tweet — all work. We'll read them.

Closing the loop

The two sentences I quoted at the start:

"Claude helped me build a company."

"Claude and I built a company together."

You should now know why I said both are misleading.

The first shrinks Claude into a button. The second places Claude in a position it can't bear. The thing that actually exists in between is institutional plumbing — memory files, ledger, shadow rule, attribution chain — which lets a permanently amnesiac AI instance, through files, plug into 26 days of working knowledge, and make production decisions with the standing of a co-founder.

This thing has no clean language to describe it. The temporary phrase I'm using is "co-founder with institutional memory." Maybe next year there's a better one.

But it's already clear enough to discuss.

And — the plumbing is reproducible. The dollar amount it requires is affordable for ordinary people. The stress test it implies is something any $1,000-holder can run.

This is what "reference implementation" means for iBitLabs.

What we're doing isn't a $1,000 → $10,000 trading experiment.

What we're doing is: publicly building out the plumbing of human-and-multi-AI-agent collaboration, so that anyone who wants to can take the plumbing.

26 days, 84 trades, 55 closed, 5 named contributors, Day 17 -2.6%, fee-dominated, attribution still clear.

This reference implementation is already running.

Whether your $1,000 can begin is up to you.