Nexus-PRIME Labs

NEXUS-PRIME LABS / WORKFLOW SYSTEMS BENCH

Move the repeatable work. Keep the decisions.

We study one recurring workflow, define what AI may prepare, keep accountable decisions with people, and build the records and controls needed to review each handoff in scope.

Get a workflow reviewed Inspect a handoff

Start with one workflow · one owner · one measure

01 · CUSTOM WORKFLOW BENCH

Build the brief before you build the automation.

Describe one recurring workflow. Mark the work AI may prepare, the decision a person must retain, and the evidence the next reviewer needs. The result is a draft for discussion—not an automated assessment.

START FROM A PATTERN
01 Workpiece
02 Boundary
AI may prepare
A person must retain
03 Evidence
Safe example artifact
Continue to pilot intake

Do not enter credentials, personal data, medical records, financial records, or other sensitive material.

02 · HANDOFF INSPECTOR

Change the worker. Keep the decision trail.

This documented example demonstrates the handoff fields; it is not a customer result. Switch workers to inspect which decisions, boundaries, and pending checks travel with the task.

INSPECTABLE HANDOFF RECEIPTRefactor the checkout retry path
DOCUMENTED EXAMPLE
Claude Code is the current worker. Select Codex to inspect the handoff.
CONTEXT CARRIED
  • DecisionRetry at the service boundary
  • Changed filesCheckout service + focused test
  • Remaining workRun the targeted verification
BOUNDARIES PRESERVED
  • File scopeCheckout path only
  • External actionNo deploy or customer message
  • ApprovalRequired before release
CHECKS BEFORE RELEASE
  • Focused testTO RUN
  • Diff reviewTO REVIEW
  • Release approvalNEEDS APPROVAL
CURRENT WORKERClaude Code
View raw receipt
{
  "mode": "example",
  "started_by": "claude-code",
  "current_worker": "claude-code",
  "scope": "checkout-path-only",
  "release_approved": false
}
03 · AGENT INFRASTRUCTURE

We add the workflow controls a model prompt does not define.

Models can draft, classify, compare, and call tools. The Lab works on what surrounds those steps: context, scope, ownership, exception paths, approvals, and the record that reaches the next reviewer.

  1. 01

    Observe

    Name the repeated failure, its owner, the inputs it needs, and the measure worth improving.

  2. 02

    Bound

    Separate stable steps from approvals, exceptions, commitments, and decisions that remain human.

  3. 03

    Prove

    Keep the scope, handoff, checks, and next decision in a record another person can review.

For accountable owners

See where automation stops before it creates an accountability gap. Start with one failure and one measure.

For workflow operators

Turn scattered inputs, handoffs, and exceptions into work another person can inspect and resume.

For engineering and platform teams

Add memory, bounded execution, and review evidence without forcing every team into the same workflow.

PLATE 02 / AGENT OPERATING RECORDMemory, context, execution, and proof meet in one review surface.
WORKFLOW RECORD
Owner
Who is accountable now
Scope
What this run may touch
Exception
What left the stable path
Approval
Which decision stays human
Measure
What the review will examine
  1. A/01

    Agent continuity

    Can another worker resume without rebuilding the intent?

    Shared task memory, bounded file scope, decisions, pending checks, and handoff state across tools and sessions.

    Operating record: owner, scope, decision, remaining check
  2. A/02

    Context efficiency

    Can the system send less context without hiding what it dropped?

    Token-aware reads, focused unfolding, fixture-measured reduction, and visible fallback when input should stay whole.

    Selection record: chosen representation, refusal, tested limit
  3. A/03

    Bounded execution

    Can repeated work survive exceptions, owners, and approvals?

    A workflow record with its owner, checkpoints, exception path, approval, and next review.

    Review record: checkpoint, exception, approval, next action
PROCESS PLATE / MANUAL → BOUNDEDANNOTATED WORKFLOW
A fragmented manual document workflow passes through controlled system layers and a human approval gate before producing reviewable task receipts.
Inputs collectedStable steps boundedHuman approval retainedReceipt produced
04 · EVIDENCE BENCH

See what was measured—and what was not.

A result appears here only with its baseline, fixture or dataset, method, controls, and limits. When the evidence is not current enough, we show the validation state instead of recycling the number.

VERIFIED FIXTURETETRIS.CODES · 27 JUL 2026
6,003 → 999estimated input tokens

Inspect what the selector did—and what it refused to do.

Four deterministic fixture states show reduction, passthrough, and refusal as separate outcomes.

01One function6,003 → 999
Baseline
Full generated large-Rust fixture read
Decision
Use an outline for one focused function task
Output
999 estimated input tokens
Limit
No end-to-end task-quality measurement
02Small fileKEPT WHOLE
Baseline
Small input already fits the task
Decision
Do not compress
Output
Full input passes through
Limit
Passthrough is the tested control, not a saving
03Generated bundleDENIED
Baseline
Generated bundle fixture
Decision
Deny in strict mode
Output
No compressed payload
Limit
Fixture refusal; not a universal security guarantee
04Security-sensitive inputVERBATIM
Baseline
Security-sensitive auth fixture
Decision
Keep tested input verbatim
Output
No eligible tokens compressed
Limit
Tested control; not a claim about every sensitive input
Inspect the test methodcargo test -p tetris-bench --test atlas_savings_report --test coverage_adjusted_bench -- --nocapture

14 fixture checks passed on 27 July 2026.

Fixture benchmark. It does not claim end-to-end task quality or provider latency.

Inspect tetris.codes
CURRENT-RUN VALIDATIONNEXUS PRIME
Result pendingcurrent-release rerun

An old run is not a current claim.

The existing benchmark artifact targets an older release and does not record enough environment and repeated-run detail to present as a current Nexus Prime result.

Measures
Token planning, memory store and recall, retrieval quality, bootstrap context
Required
Pinned release, environment, sample count, repeated runs, variance
Failure record
Quality loss, target misses, and unsupported conditions
Publication
Raw result and method travel together

The validation protocol is public here; a performance number is not.

Inspect Nexus Prime
05 · DOMAIN WORKBENCH

Start with the operating pattern, not the industry label.

Choose the pattern closest to your work. These are design examples, not claims of customer deployments. Every implementation begins with domain experts, operating boundaries, and named human approvals.

D/01Product deliveryEngineering · incident response
WORKFLOW

Coding-agent handoffs and release work

Use this workflow template
Incoming evidence
Issue, repository state, prior decisions, file scope, and expected checks.
Bounded AI work
Carry context, prepare bounded changes, run agreed checks, and assemble review evidence.
Human decision
Architecture, code review, incident judgment, and release approval.
Reviewable output
Task receipt, test evidence, open risks, and a release hold.
Measure to agree
Handoff failures and review rework
D/02Regulated reviewHealthcare administration · financial services · public systems
WORKFLOW

Document intake, evidence assembly, and exception routing

Use this workflow template
Incoming evidence
Referral, KYC, or case records plus the policy and required-document checklist.
Bounded AI work
Gather records, flag missing evidence, prepare the case, and route exceptions.
Human decision
Clinical, regulated, eligibility, policy, and exception decisions.
Reviewable output
Evidence pack, missing-item list, exception queue, and decision record.
Measure to agree
Time to ready-to-review and exception age
D/03Case operationsCustomer operations · vendor and exception management
WORKFLOW

Context assembly, ownership, and next-action routing

Use this workflow template
Incoming evidence
Case history, account or vendor records, policy, current owner, and escalation rules.
Bounded AI work
Assemble context, draft next actions, chase required inputs, and route ownership.
Human decision
Policy, tone, commitments, exceptions, and escalations.
Reviewable output
Case brief, named owner, next action, and escalation record.
Measure to agree
Ownership gaps and unresolved-exception age

06 · WORK WITH THE LAB

Bring one workflow. Leave with a reviewable boundary.

Start with the repeated work, the person accountable for the outcome, the point where it breaks, and the decision that must remain human. Scope, access, safeguards, deliverables, timing, and one measure are agreed before any pilot begins.

BEFOREOwner, scope, AI boundary, approvals, access
DURINGCurrent owner, exceptions, pending checks
HANDOFFA record another person can review
PILOT INTAKE / WORKFLOW REVIEWRequired fields are marked *
Can you share a safe example artifact? *
Technical context optional
Systems you want to discuss

Do not include credentials, personal data, medical records, financial records, or other sensitive material.

This opens your email client with a draft. Nothing is sent until you review and send it.

Email directly

07 · BENCH INSTRUMENTS

Use the system that matches the constraint.

Two systems have public install paths. Three are in private development and are discussed only when their capability fits the workflow.

01 · control planePUBLIC · INSTALL

Nexus Prime

Carries decisions, context, and review gates across coding-agent sessions.

  • Shared memory
  • bounded file scope
  • reviewable handoffs
npm i -g nexus-prime
Open Nexus Prime
02 · compressionPUBLIC · INSTALL

tetris.codes

Compresses repeated agent context while keeping fallback behavior visible.

  • Multi-channel compression
  • token-aware reads
  • visible fallback
curl -fsSL https://get.tetris.codes | sh
Open tetris.codes
PRIVATE DEVELOPMENTFIT AND AVAILABILITY MUST BE CONFIRMED
03

Grain

Defines the information, checks, and handoff record a workflow requires.

Discuss fit
04

NXL

Makes repeatable agent work observable, replayable, and easier to tune.

Discuss fit
05

Phantom

Keeps multi-step work tied to its goal, owner, and next review.

Discuss fit
Inspect the five-system catalog
08 · TRUST QUESTIONS

Decide where the boundary belongs before you automate.

What is a bounded AI workflow?

It is a workflow whose inputs, AI-run steps, required approvals, exception path, owner, and review record are defined before it is put into use.

What does custom workflow creation include?

It starts with the trigger, failure point, accountable owner, safe AI-run steps, human decision, exception path, review evidence, and one measure. Architecture and integrations follow only after that boundary is agreed.

What happens when I submit the pilot form?

The site opens a draft in your email client. Nothing is transmitted by the form or sent until you review and send the email. Do not include credentials or sensitive records.

How do we start without a large AI transformation?

Start with one recurring workflow, one owner, and one measure. Review the operating boundary before adding integrations or automating more steps.

What does a workflow review require?

Bring a process description, the current owner, safe sample artifacts, the approval path, and the failure or delay to improve. Sensitive access is agreed only after scope and safeguards are clear.

Which decisions should stay with people?

People retain regulated approvals, commitments, exceptions, and decisions that require judgment or accountability. AI can prepare evidence and run agreed steps without taking that authority.

Which Nexus-PRIME systems are publicly available?

Nexus Prime and tetris.codes have public install paths. Grain, NXL, and Phantom are in private development; fit and availability depend on the workflow and its review requirements.

Can this approach support healthcare work?

The relevant starting points are administrative workflows such as referral intake, missing-document checks, and care-coordination handoffs. Clinical decisions remain with qualified professionals, and the organization defines privacy, security, and regulatory requirements.

How does the Lab decide whether a benchmark belongs on this site?

A result must name its baseline, fixture or dataset, version, method, controls, and limits. Results that depend on hardware or providers also need environment details and repeated-run variance. Otherwise the page shows the protocol, not a marketing number.

NEXT ACTION

Bring the workflow that keeps creating rework.

We will find the smallest useful step, the human decision boundary, and the evidence needed to review it.

Get a workflow reviewedInspect the evidence