Gino Bronstein

Project Ares · Build log · Updated 29 Sep 2026

Five Work edits passed. I am not calling the job done.

After fixing what the first measurements exposed, five real documentation and test edits passed review and verification on the first try. Median provider use was 15,087 tokens. A later native merge exposed a receipt defect, so Work acceptance stays open.

Current state
The token half of the packet Work study is met on five small, fully specified edits. Its merge-rate comparison, native Preview, and beta-readiness evidence remain open.
Current focus
Repair the re-gated merge receipt, prove retry and revision behavior live, settle the Work merge-rate comparison, and verify Preview in the native app.
Measured Work study
5 of 5 reviewed and verified · 15,087 median tokens · 23 Sep 2026
Project Ares Studio showing governed work waiting for human approval
Ares Studio · the final decision still belongs to the person using it

How I got here

The newest truth comes first.

Start with the five-run result and the later native merge, then scroll back through the decisions that brought Ares here.

#

A real merge exposed the next evidence gap.

Redaction held in native Work. Episode writeback was repaired in code, while the merge receipt still used an old base.

Open case file

The problem

Secret filtering had altered ordinary code and file paths. The Vault also recorded only the first merge under a reused Objective.

The decision

Prove the redaction repair in a clean native build and record one Episode per merged execution while keeping consolidation owner-approved.

What I built

I repaired redaction, changed Episode writeback to follow each merged execution, and watched a one-line Work change pass review, re-gate, and owner merge.

Evidence

The native run cost 14,317 tokens, passed the 13-check gate, received independent approval, and merged as 279a708 after re-gating. The receipt kept code lines intact. The Episode change is merged with regression tests, but not claimed as live-proven here. The merge diff hash still included unrelated history from the old base.

What I learned

A successful merge is not complete proof if the receipt describes a larger change than the one Ares made.

#

I got five real Work edits below the token target.

All five passed verification and independent review on the first attempt.

Open case file

The problem

The previous batch cost far more than its packet suggested and missed context needed to edit the right place.

The decision

Remove the unnecessary Governor preamble, isolate the packet executor from tools and global settings, and repair the retrieval windows before measuring again.

What I built

I fixed the packet path and reran five fresh, fully specified documentation or test edits in native Studio.

Evidence

Five of five were reviewer-approved and verified, each with a 13-check PASS gate. Median provider use was 15,087 tokens per attempt, below the 25,000 target. None needed a retry or revision; the merge-rate half of S3 was not measured yet.

What I learned

Reducing a prompt is not enough. The whole execution path has to stay bounded, and the result needs an honest comparison group.

#

Five real runs showed me where packet Work falls short.

Two changes passed review and verification. Three blocked, and the true token cost missed the target.

Open case file

The problem

A small context packet looked efficient, but the first measurement missed provider usage and later revisions exposed retrieval gaps.

The decision

Count the full run, including revisions, and hold acceptance until the failures are repaired and measured again.

What I built

I connected provider usage to receipts, tested a context-rescue repair, and ran five real documentation or test changes through native Studio.

Evidence

At that point, two of five were reviewer-approved and verified, with no owner merge yet. Median true provider usage was 555,907 tokens per objective against a 25,000-token target. The 13-check gate passed on that build; packet Work was not accepted.

What I learned

A bounded prompt does not guarantee a bounded run. Retrieval, revision context, tool access, and accounting all affect the real cost.

#

I watched Ares work on its own code in Studio.

A cited, read-only Chat answer and one governed Work change completed on Project.Dev.

Open case file

The problem

Passing tests did not prove that the owner-facing app could take a real project from question to merge.

The decision

Use Project.Dev in the native app, keep Chat read-only, and let the owner make the final Work decision.

What I built

I exercised the existing Chat and Work paths with the project selected: plan approval, isolated execution, an independent review, verification, and my Merge.

Evidence

Chat cited the repository without changing Git. The Work run passed 13 checks, received an approved independent review, and was owner-merged as f491c97. The merge controls did not refresh immediately, so that UI detail remains open.

What I learned

A good receipt is not the whole experience. The interface must show the owner what happened just as clearly.

#

I made a receipt answer who reviewed it and what changed after a rewrite.

A pending merge now carries its review binding and replays only its reviewed delta when the base changes.

Open case file

The problem

A receipt could prove a review existed without naming it, and a rewritten base could replay stale history into an avoidable conflict.

The decision

Persist the review binding on the receipt, then rebase only the reviewed delta onto the current HEAD before re-gating.

What I built

I bound reviewer identity, verdict, and time to the execution receipt, then added the rewritten-base re-gate repair.

Evidence

Focused MergeQueueTests passed 22 tests; the canonical gate passed 13 checks and 863 tests with reverse-test proof.

What I learned

Traceability is not a label. It has to stay attached when the history underneath it moves.

#

I made Chat use less context and show its sources.

A local packet, line citations, and a native fast path earned owner acceptance across ten Chat turns.

Open case file

The problem

Read-only Chat was spending too much provider context on repository browsing before it could answer a focused question.

The decision

Build the context locally, cite packet lines, and answer simple code-structure questions without a model call.

What I built

I added graph-aware candidates, local ranking, a bounded packet, cited read-only Chat, and a no-model fast path.

Evidence

The accepted ten-turn run reached a median 18,281 provider tokens, 36.5% of the 50,025 baseline. Three turns used the fast path.

What I learned

Smaller context is only useful when the system can show what it left in and say when that was not enough.

#

I made Studio keep each conversation attached to its own work.

Streaming responses and recovery now return to the conversation and receipt that started them.

Open case file

The problem

Switching chats could leave the original card running forever or restore an old failed card instead of the valid pending merge.

The decision

Bind callbacks and recovery to the initiating thread, project identity, root, receipt, and owner decision.

What I built

I captured the original thread in callbacks and restored only receipt-backed pending work.

Evidence

The latest repair passed the 13-check gate and the full suite reached 740 tests. A Terra Chat reply passed with Project.Dev selected.

What I learned

Reliability is often small ownership details. If a screen loses its source of truth, the rest of the system cannot save it.

#

Ares completed work on Ares.

Two isolated Ares tasks reached an owner merge and wrote their own evidence.

Open case file

The problem

A workflow that works only on managed projects still leaves the product itself unproven.

The decision

Use Project.Dev as a governed target and keep every defect from the real run visible.

What I built

I repaired the generated-scheme false positive, completed two self-runs, and wrote an Episode and the first witnessed skill stamp.

Evidence

Both self-runs passed the 13-check gate and were owner-merged. The receipt does not name a reviewer provider, so I do not claim that part as verified.

What I learned

The useful test was watching Ares meet its own constraints and fail in public when they did not line up.

#

I made parallel work earn its place.

Ten verified Objectives now leave 12 Episodes across two projects.

Open case file

The problem

Adding parallel agents before evidence makes speed look more valuable than safety.

The decision

Allow parallel work only for disjoint write sets. Re-gate the second branch after the first merge.

What I built

I completed the ITAM merge and re-gate drill, then let routing use measured results only after five observations.

Evidence

Two cross-provider branches merged in sequence after re-gating. ITAM finished with 9 passing checks and 44 tests.

What I learned

Parallelism is not a toggle. It has to be earned from the shape of the work.

#

I joined the parts into one system I can actually use.

Chat, Work, research, recovery, and evidence memory now meet in one product.

Open case file

The problem

Even good infrastructure becomes unsafe when questions, research, and authorised work look the same.

The decision

Give every mode a clear boundary. Only an approved plan may enter execution.

What I built

I built a command centre, read-only Chat, governed Work, cancellable research, recovery controls, and evidence memory.

Evidence

The latest reconciled harness passed 13 checks. Newer branch work is not included in that claim.

What I learned

Removing the updater and unused adapters made Ares better. I would rather show less than pretend a feature is ready.

#

I stopped memory from promoting its own guesses.

Only work that passed and was integrated can become reusable memory.

Open case file

The problem

Agent memory can turn one confident mistake into a pattern that keeps returning.

The decision

Keep failures private and bounded. Promote a pattern only after fresh evidence and owner approval.

What I built

I added Project Episodes, a hidden Remediation Ledger, ordered retrieval, and human-approved Playbooks.

Evidence

The writer checks receipts again, writes one Episode per Objective, and fails safely when the vault is unavailable.

What I learned

Memory can help Ares choose context. It should never get the authority to approve work.

#

I made interrupted work recoverable.

Work can pause, resume, reroute, or stop without hiding what happened.

Open case file

The problem

Long AI runs hit time limits, failed tools, crashes, and changing risk.

The decision

Save checkpoints and make budgets, fallbacks, and recovery choices visible.

What I built

I added risk floors, hard budgets, fallback boundaries, crash recovery, and evidence-based routing.

Evidence

Acceptance tests show that an exhausted budget pauses work and recovery never grants new authority.

What I learned

I trust a system more when it can explain a bad run and recover from it.

#

I stopped asking the builder to judge itself.

Building, independent review, revision, verification, and integration now form one loop.

Open case file

The problem

A builder reviewing its own work can carry the same bad assumption all the way through.

The decision

Use a separate reviewer and turn findings into a limited revision step.

What I built

I added structured review, rejection handling, a revision limit, and integration tied to verification.

Evidence

Real-model trials approved correct diffs and rejected test-deleting changes. The findings were saved.

What I learned

The useful part is independence, not how many agents I can put on a diagram.

#

I put real work through the controls.

Ares now isolates changes, records the run, and stops when proof is missing.

Open case file

The problem

The interface showed controls that the old execution path could still bypass.

The decision

Send normal Work through one real path and leave Merge to the owner.

What I built

I added isolated Git worktrees, bounded model execution, command and diff receipts, and an owner-gated merge.

Evidence

The executor cannot approve its own work. Missing review or verification blocks integration.

What I learned

If a boundary matters, it has to exist in the execution path. Copy on a screen is not enough.

#

I made approved plans survive a restart.

An approved plan is now still the same plan after the app restarts.

Open case file

The problem

A plan kept only in memory cannot support real approval or recovery.

The decision

Save every approved revision together with the policy it was approved under.

What I built

I added persistent Objective and Task Graph revisions, approval gates, and restart recovery.

Evidence

Tests reload revisions from a fresh store, keep old revisions unchanged, and block unapproved work.

What I learned

Approval only means something when the approved plan cannot quietly change afterward.

#

First, I worked out what was actually true.

Before adding anything else, I compared the roadmap, memory, code, and receipts.

Open case file

The problem

The project had old mock results and two ways to run work. I could not honestly say which claims still held.

The decision

Keep one governed path and stop calling work complete without a fresh receipt.

What I built

I wrote down the real state, isolated the tests, and routed normal Work requests through the Governor.

Evidence

A fresh PASS receipt covered isolation, independent review, and receipt binding.

What I learned

The first reliability feature was not a smarter model. It was being honest about the state of the system.

What I practised

What this project taught me to do.

Agent orchestration

I learned how to connect planning, tools, implementation, review, and recovery without letting any one agent quietly take control.

AI reliability

I put checks, receipts, failure states, and human approval into the workflow instead of trusting a confident answer.

Systems thinking

My support background keeps me asking what breaks, who needs to know, and how the work can recover.

Product restraint

I removed features that had not earned their complexity. A smaller, honest product is more useful than a busy one.

What comes next

The token target is met. Work acceptance is not.

Five small, fully specified edits passed review and verification below the token target. That does not yet prove the merge-rate comparison or the retry and revision paths in live use.

  1. Next01

    Complete Work evidence

    Record the owner merge decisions and define a comparison baseline. Exercise retry and revision behavior live before asking for S3 acceptance.

  2. Next02

    Fix the receipt and finish native proof

    Bind a re-gated merge receipt to the final task delta, then prove Preview, the post-merge UI, and a same-build walkthrough before a beta decision.

  3. Next03

    Keep Core AI behind its gate

    Wait for macOS 27, the 20 of 20 benchmark, owner semantic approval, shadow Objectives, and a tested fallback.

Gino Bronstein · Amsterdam, NL

Want to talk through Ares?

I am looking for an AI or product engineering team where I can keep building, questioning, and learning close to real users and real operational problems.

Talk to me about the work ← Back to portfolio