Grex in practice
Check a website. Research a decision. Make a focused code change. Grex runs defined tasks on computers you own and keeps the output, checks and review together.
Private early access · Current capabilities, November 2026
The assignments and output outlines below are illustrative. The linked field reports describe work actually run through Grex, including failures.
Site intelligence
For the operator responsible for several live websites.
A deployment can leave a broken link, a missing asset or a page that never becomes ready. Give Grex a defined set of public pages to inspect, then read the findings alongside what it could not check.
Check the home page, pricing page and getting-started guide each morning. Report broken internal links, failed assets and page errors. Compare the findings with the last accepted report.
Inspect the affected URL and supporting observation before deciding what to fix. A repair can become its own scoped coding mission.
Discuss this use caseFrom the field
Seven accepted site reports, after a schedule incidentOn November 2, seven site reports eventually received acceptance. Scheduled dispatch had failed and required manual recovery.
The boundary
Checks cover configured public pages. They do not log in, complete purchases or prove every customer journey works.
Research briefs
For a founder or product lead choosing the next useful change.
Before adding another page or chasing a competitor feature, ask a narrow question. Grex gathers sources, retains what it fetched and produces a cited brief you can inspect.
Compare the public guidance on our site with the questions a first-time buyer needs answered. Recommend three missing pages. Support each recommendation with sources, and separate observed facts from your interpretation.
Read the brief and follow its evidence before choosing a next step. An accepted brief can inform a coding task; it does not authorize publication or establish demand.
Discuss this use caseFrom the field
Four page-gap briefs became website workFour accepted briefs identified missing pages on four sites. Across that day’s 17 research missions, five were accepted and twelve failed.
The boundary
Source checks establish traceability, not universal truth. A brief can fail its checks or review, and incomplete or undated evidence remains a limitation.
Inside the product
Open the work in the dashboard to inspect its artifacts, checks and review. The record keeps the evidence behind the outcome available for your next decision.
Repository missions
For a technical team with a clear change and a repository it controls.
A missing guide, a routing bug or a focused implementation task can have a clear finish line. Specify the files a builder may change and the checks the result must pass.
Add a getting-started page using the approved brief and the existing site components. Limit changes to the page and its route. Check that the route loads, the links resolve and the production build passes.
Inspect the patch, checks and review. An accepted submission is ready for a separate decision to land the change, merge it and deploy it.
Discuss this use caseFrom the field
Nine changes reached four live websitesNine of 18 missions were accepted and later merged and deployed by the operator. Eight failed and one was cancelled.
The boundary
Review acceptance is not deployment. A narrow task and appropriate checks still matter; rejected changes are not a finished deliverable.
Video missions
For an operator turning an existing Grex field report into a short video.
A written result can also become a narrated, captioned video. The current workflow starts with a prepared storyboard and source article, then renders on a worker with the required video tools.
Render the prepared storyboard for a published Grex field report. Use only the approved public pages for footage. Include narration and captions, and retain the video checks with the result.
Watch the result and assess whether it faithfully represents the source. Operator acceptance and public distribution remain separate decisions.
Discuss this use caseFrom the field
Read the storyboard and renderer implementation reportThe October 29 report records accepted storyboard work and renderer components. It does not establish automatic video production or a published campaign.
The boundary
This is a constrained public-site workflow with prepared inputs. It requires a configured rendering worker and does not automatically publish to social platforms.
Recurring work
A daily site check needs a schedule. A standing responsibility needs a way to review evidence and choose what happens next. Grex keeps both in the product.
Schedules still need operational attention. Offices organize reviews and proposals; they do not independently launch every proposed task. Read the schedule failure and recovery account →
A separate experiment
AutomationBench is where we are testing simulated business tasks. That work is experimental; it is not a live customer email or CRM integration. The first pilot did not show a quality improvement over its direct runner.
Read the results and next study →