Entire's Trails need a review contract, not just green agent evals.

The innovation is a richer review object

Entire opened its Git-compatible forge on October 26, 2026 with three linked claims: Trails replace the pull-request review surface, distributed hosting serves agent-scale Git traffic, and Continuous Memory makes prior coding sessions searchable. The launch matters because agent-generated code stresses the weakest part of current delivery systems: not writing a diff, but establishing why a change exists, what produced it, which checks actually ran, and who may accept the remaining risk.

A pull request can carry this information, but teams usually reconstruct it from an issue, a branch, CI logs, agent transcripts, review bots, chat messages, and a human's memory. Entire's CLI captures agent sessions as checkpoints linked to commits. A Trail follows a branch from intent to merge. Repository runners score each push and raise findings. CI results from providers such as Buildkite and Depot can sit beside those findings. The model is coherent: review the causal chain, not only the final patch.

The dangerous interpretation is that enough review agents can replace review authority. Entire's launch says agents can address findings in a loop while a human validates progress and that teams may merge after evals are satisfied without reading every line. That can be sensible for low-risk, well-tested changes. It is unsafe as a universal rule. A proposer and an evaluator can share the same blind spot, prompt injection, stale context, or model defect. Green scores prove only that specified evaluators returned a passing state.

The acceptance unit should therefore be one exact Trail state: immutable head commit, intent, checkpoint identities, runner definitions, model and prompt versions, deterministic test results, unresolved findings, human approvals, merge target, and timestamp. Change any material input and the approval expires.

Five layers sit behind the “Trail” label

The CLI makes the workflow concrete. entire enable installs agent and Git hooks. A commit containing agent work receives a checkpoint reference. entire trail create opens the review object; entire trail watch streams findings and runner events; entire trail approve records approval; and entire trail merge performs the merge. The commands are useful because they give both humans and agents one operable surface.

git switch -c add-rate-limiting
entire enable
# run the approved coding agent and commit the candidate
entire checkpoint list
entire checkpoint explain CHECKPOINT_ID
entire trail create --title "Add rate limiting" --type feature
entire trail watch
entire trail finding
# deterministic CI and human challenge happen here
entire trail approve
entire trail merge

Do not turn that sequence into an unconditional bot loop. Put policy between finding resolution and approval. A protected service, not the coding agent, should verify the exact head, runner definitions, CI receipts, reviewer identity, exception state, and target branch before approval or merge commands are permitted.

Define the Trail contract outside the evaluator

The contract should separate evidence collection, assessment, and authorization. Agent runners may assess code. Deterministic systems attest tests, builds, signatures, and policy. Humans accept business and security risk. One model should not be able to rewrite all three layers.

trail_contract: v1
identity:
  repository: immutable_repo_id
  base: protected_commit_sha
  head: exact_commit_sha
  checkpoint: content_digest
intent:
  ticket: required
  allowed_paths: explicit
  risk_class: low|medium|high
evidence:
  deterministic_checks: [build, unit, integration, secret_scan]
  model_evals: versioned_and_advisory
  runner_config_digest: required
  transcript_policy: redact_and_review
authorization:
  proposer_cannot_approve: true
  human_owner: required
  unresolved_blockers: zero
  approval_expires_on_change: true
release:
  merge_receipt: required
  rollback_target: required
  evidence_retention_days: 180

Use different policies by risk. A documentation typo with passing link checks may need a single reviewer. An authentication change should require deterministic security tests, a security owner, and manual inspection of trust boundaries. A database migration should require forward and rollback tests on a representative copy. A generated dependency update needs provenance, license, vulnerability, and behavior checks. “All runners green” is not one risk policy.

Bind every approval to hashes, not display names. Runner labels such as “Security” or “Confidence” can remain constant while prompts, models, thresholds, or code change. The review receipt must record the runner configuration digest, evaluator identity, model/provider version where available, input scope, timestamp, and raw verdict. Otherwise a later auditor cannot tell what “green” meant.

Build a receipt that survives the UI

A review surface is useful; an exportable receipt is durable. Keep a machine-readable record beside the merge commit or in a controlled evidence store. It should be possible to re-run deterministic checks without Entire, explain which findings were waived, and discover which session evidence was intentionally excluded.

{
  "trail": "et/platform/api#42",
  "base": "sha256:base",
  "head": "sha256:head",
  "checkpoint": "sha256:checkpoint",
  "intent": "SEC-1842",
  "runner_config": "sha256:runners",
  "checks": [
    {"name":"unit","type":"deterministic","status":"pass","receipt":"ci-884"},
    {"name":"security-review","type":"model","status":"pass","model":"pinned-id"}
  ],
  "exceptions": [],
  "reviewer": "team:platform-security",
  "decision": "approve",
  "approved_at": "2026-10-30T09:40:00Z",
  "merge_commit": "sha256:merge",
  "rollback": "sha256:base"
}

Run deterministic checks in an environment the proposer cannot rewrite after execution. The agent may add tests, but a protected pipeline should execute the repository's approved suite. Test the tests: inject a known-bad change and prove the gate turns red. If the model writes both implementation and assertions, a passing suite may simply encode the same misunderstanding twice.

Keep model evals because they catch semantic, maintainability, and security issues ordinary tests miss. Calibrate them with a labeled set of accepted and rejected changes. Measure false negatives, false positives, stability across repeated runs, and sensitivity to prompt or model updates. A confidence score without calibration is decoration.

Continuous Memory creates a second repository boundary

Entire checkpoints can include prompts, transcripts, and touched files. By default they live in separate Git refs and can be pushed alongside code. The CLI documentation warns that public repositories make those transcripts readable, that redaction is best effort, and that teams should inspect outgoing checkpoints. It supports a separate private checkpoint repository or disabling session pushes.

This is not a minor configuration detail. Agent conversations routinely include pasted logs, customer examples, internal URLs, failed commands, environment names, and fragments of secrets that scanners may miss. A public source repository can be suitable for code while the accompanying transcript is confidential. Classify checkpoint data independently from the branch.

Searchable memory adds poisoning and staleness risks. A wrong decision in an old transcript can become future context. Retrieval should return source identity, commit/time, confidence, and supersession state. Critical architectural decisions belong in reviewed documentation, not only in a model conversation. Treat memory as supporting evidence, never hidden authority.

Separate forge throughput from review quality

Entire reports pushes up to 89 times faster than GitHub and codebase-graph retrieval using up to 71% fewer tokens. These figures are first-party and workload-specific. ForgeMark is public and useful: it runs real smart-HTTP Git operations, reports throughput and latency percentiles, supports branch, repository, clone, and session strategies, and writes JSON results. Its documentation also distinguishes Entire-native targets from GitHub mirror mode, where forwarded writes cannot outrun the upstream.

Reproduce the benchmark against repositories you are authorized to load-test. Use your object sizes, clone patterns, checkpoint frequency, concurrency, regions, and CI behavior. Measure p95/p99 latency, errors, ref conflicts, retry amplification, upstream forwarding, recovery, and cost. Then measure the full path from task start to accepted merge. A faster push that creates more review noise can lengthen delivery.

Choose the custody model before the interface

The current Hacker News discussion includes the right objection: parts of a Trail can look like stacked pull requests, CI checks, and project management. That does not make Trails pointless. It sets the evaluation standard. Entire must reduce reconstruction work, improve finding quality, preserve intent, and shorten safe review more than a well-integrated conventional forge. Test that outcome directly.

Failure modes worth injecting before migration

A 30-day mirror-first pilot

Days 1-5: choose two low-risk repositories and one representative service. Record existing task-to-merge time, review time, CI latency, defect escape rate, clone/push latency, and reviewer effort. Define the Trail contract, checkpoint classification, human roles, runner ownership, retention, and stop conditions.

Days 6-10: install a pinned CLI version, keep GitHub as source of truth, route checkpoints to a controlled destination, and test enable/disable, hook preservation, clone, mirror, branch protection, checkpoint inspection, deletion, and access. Do not migrate production custody.

Days 11-15: configure deterministic checks and a small set of model runners. Seed known defects. Measure whether each gate catches the intended failure and whether repeated model evals are stable. Record false positives and reviewer overrides.

Days 16-20: run normal agent tasks through Trails. Compare diff review with evidence review. Measure how often the checkpoint explains a change, whether findings reduce manual work, and whether memory retrieves correct, current decisions.

Days 21-25: inject a stale runner, secret-like transcript, mirror outage, failed forwarded push, poisoned memory item, missing CI job, and changed head after approval. Require the system to fail closed and preserve a receipt.

Days 26-30: review the evidence with platform, security, developers, and maintainers. Approve only an exact configuration and scope. Keep a tested export and rollback path. Native hosting should be a separate decision with its own durability, residency, access, support, and disaster-recovery acceptance.

FAQ

What is an Entire Trail?

A Trail follows a branch from intent to merge. It presents findings from repository runners, comments, approvals, agent sessions, code changes, and CI events through the web interface and CLI.

Do green agent evals make a change safe?

No. They show that configured evaluators passed. Keep deterministic tests, protected policy, independent challenge, exact evidence identities, and human authority for consequential changes.

Can Entire be piloted without replacing GitHub?

Yes. GitHub mirror mode keeps GitHub as the source of truth and forwards pushes upstream. That is a useful pilot path, but teams must test reconciliation and failure behavior across both systems.

Is Continuous Memory the same as reviewed documentation?

No. It makes sessions and code context searchable. Retrieved memories can be stale, confidential, incomplete, or wrong. Reviewed decisions should remain in authoritative project records with supersession and ownership.

Are the performance claims independently proven?

ForgeMark is public and supports reproduction, but Entire's headline results remain first-party and workload-specific. Re-run them on authorized infrastructure and measure end-to-end accepted delivery, not only Git operations.