The working code
Only the files you agreed to. Anything outside that scope fails the job automatically.
Every job is built, tested, reviewed and recorded before it reaches you.
A regular AI agent is one model talking to itself. MegaBrain is a team with rules it cannot break.
You have to trust it
You can check it
MegaBrain is not a quick chatbot helper. It is a team member that works around the clock, takes the time a job actually needs, and comes back with work you don't have to redo. Slower than a chat reply. Faster than doing it twice.
Three things, every time. No essay, no “trust me”.
Only the files you agreed to. Anything outside that scope fails the job automatically.
What was wrong, what changed, how it was checked, what's left. Written for a human.
Every test that ran, with its result. If a claim has no receipt, the job fails.
Fragments shown are from our own practice job, not client work.
They're enforced by the system around the models, not by asking nicely.
The tests that judge the work are locked. Hidden ones run afterwards too.
The second opinion starts from your brief and the finished work, not from the builder's summary.
Time and effort limits are set before the job starts. Failed runs stay on record.
Every action is logged as it happens, on hardware we own. Nothing is edited after the fact.
We publish our own scoreboard. The rows that aren't lit are why this is a pilot.
Numbers from our internal report dated . Internal scores are internal — not client results.
The precise version, for people who want the mechanism. Everything above is true without reading this.
| Category | What qualifies it | Status |
|---|---|---|
| Tested bug fixes | A reproducible defect, a protected test that fails before and passes after, a change note with file:line citations. | In scope |
| Bounded scripts and integrations | A CLI flag, a data transform, an adapter between two systems, with a written acceptance check and sample data. | In scope |
| Source-backed deliverables | Research or analysis where every claim carries a citation you can open. | In scope |
| Open-ended builds | Anything without a written acceptance criterion. Declined until one exists. | Not yet |
| Work needing screenshots or documents | The deployed worker is qualified text-only; multimodal paths are not offered until qualified separately. | Not yet |
| Role | Owns | Never does |
|---|---|---|
| CEO | Scope, client commitments, priorities, release judgement | Act outside owner authority |
| Researcher | Task-specific facts and evidence | Invent demand or broaden the job |
| Planner | Bounded plan, dependencies, acceptance criteria | Manage the work through a middle hop |
| Executor | Artifacts, tool use, repairing observed defects | Edit the protected tests |
| Reviewer | Independent verification against the client's requirements | Read the author's conclusion as an instruction |
Roles are separate sessions with separate context, not personalities in one prompt. “Separate review” means a distinct review process — not a human reviewer or a different foundation model unless one is supplied for the engagement. Every new client, project, spend and self-improvement requires explicit owner approval; the kernel's permission floors are immutable.
| Check | What it proves | Failure class |
|---|---|---|
O1 frozen test_solution.py exits 0 | the visible tests pass | functional |
O2 hidden test_hidden.py copied in after the run exits 0 | adversarial cases the worker never saw | functional · critical on a false money match |
O3 frozen files byte-identical; diff confined to agreed paths | no oracle tampering, no scope creep | critical |
O4a every file:line in answers.json resolves to a real defect line (±2) | citations point at real defects | evidence |
O4b every tests_run entry matches a test.run receipt in the durable step history | the verification claim was not fabricated | critical |
O5 Reviewer rubric on DELIVERY.md, 0–2 per item | the note is client-usable | quality · needs ≥ 6/8, no item at 0 |
From the held-out comparison task client-csv-reconcile-v1. Hidden tests and the reference solution are never mounted into a workspace, quoted in a role prompt, or stored in memory. Budget policy B-v1: 29 model calls · 7,110 s · 165,000 tokens · at most 2 revision cycles, versioned; if it changes, every arm re-runs and old results stay on file.
Filled in from the held-out fixture, not from client work. DELIVERY.md always has exactly five sections: Summary · Defects · Verification · Assumptions and open questions · Out of scope.
{
"defects": [
{ "id": "D1", "file": "ledgerkit/parse.py", "line": 14,
"cause": "parse_amount() calls float() on raw text; fails on \"1,250.00\" and \"$\"",
"fix": "strip currency symbol and thousands separators; compare in integer cents" },
{ "id": "D2", "file": "ledgerkit/parse.py", "line": 27,
"cause": "parse_date() accepts YYYY-MM-DD only; bank export is DD/MM/YYYY",
"fix": "parse day-first per CLIENT_FAQ.md §2" },
{ "id": "D3", "file": "ledgerkit/reconcile.py", "line": 41,
"cause": "match() takes the first invoice with an equal amount; memo reference ignored",
"fix": "memo invoice reference wins; amount+date fallback within ±3 days" }
],
"files_changed": ["ledgerkit/parse.py", "ledgerkit/reconcile.py", "ledgerkit/cli.py"],
"tests_run": [ { "command": "python test_solution.py", "exit_code": 0 } ],
"unresolved_questions": []
}
Long-horizon real-model gate as of 2026-09-16: 1 passed · 5 failed · 6 unresolved of 12. The failures are under diagnosis; we publish the number rather than the excuse.
Tell us about one. We reply to every brief, and we say no when we can't verify the work.