01
Visible loops
See what TARX is checking, when it last checked, and what comes next.
FREE TO THINK
● PRIVATE PREVIEW UTC
● FOR BUILDERS
Build with
agent loops,
not just prompts.
TARX is a local-first runtime for visible, governed agent loops. Give it a goal, constraints, and proof criteria. It watches the system, runs checks, updates the next action, and escalates when a human or coding agent needs to step in. Every loop is bounded, timestamped, and inspectable.
See how loops work →Why loops now?
Chat was the demo.
Loops are the work.
Coding agents are moving from step-by-step prompting to delegated workflows that run against a goal. That is powerful and, today, mostly a black box: you cannot see what the agent is checking, when it last checked, or why it did what it did. TARX is built for the next phase: agent work with evidence, reliability, escalation, and operational visibility. You stay in control because you can see the loop.
What TARX does
A visible runtime
for governed AI work.
TARX turns AI work into loops you can watch. Instead of prompting an agent step by step, you give TARX a goal, constraints, and proof criteria. TARX runs a bounded managed loop locally: goal -> contracts -> plan -> action -> proof -> critique -> next action -> escalate or stop.
02
Local-first runtime
Work happens on your prepared local stack, with model and provider truth surfaced.
03
Governed autonomy
Bounded profiles, stop conditions, and failure thresholds. No forever-agent claim.
04
Proof-first
Evals, self-tests, endpoints, screenshots, artifacts, and status docs.
05
Human and agent in the loop
Codex or Builder can handle critique, patching, and judgment instead of babysitting.
06
Developer control
Explicit loop specs, YAML contracts, claim locks, dry-run modes, and validate-only modes.
How TARX works
Every loop
is a contract.
01
Goal
What the loop is working toward.
02
Contracts
Constraints, claim locks, and proof criteria.
03
Plan
The loop's intended actions.
04
Action
The runtime executes locally and visibly.
05
Proof
Evals, self-tests, artifacts, screenshots, and endpoints.
06
Critique
Evidence is reviewed against the contract.
07
Next action
The loop updates what comes next.
08
Escalate or stop
Hand to a human or coding agent, or stop on a threshold.
Loop workflow examples
Use the right loop
for the job.
Watch, build, critique, release, and research loops are different operating modes. Each emits proof, each has a stop condition, and each can escalate when judgment is needed.
01
Watch loop
Monitors app status, evals, self-tests, reliability, and the next action.
02
Build loop
Scopes work, sends Builder or Codex prompts, waits for proof, and updates status.
03
Critique loop
Reviews screenshots, artifacts, UI contracts, claims, and regressions.
04
Release loop
Runs founder-demo proof, claim locks, packaging readiness, and go or no-go checks.
05
Research loop
Gathers market, customer, and source context, then distills decisions.
06
Ops loop
Future connector and automation workflows. Planned, not claimed as live.
Local-first runtime
It runs on your machine, and tells you the truth.
TARX runs as a local managed runtime. The prepared Electron app opens to Always On. A visible composer drives runtime activity that streams as it happens. The inspector and lower terminal show the ground truth of what ran. Model and provider are surfaced, not hidden. Cloud is fallback, not primary.
Claim boundary: prepared-machine founder RC. Public download, clean-machine, and offline readiness are not claimed yet.
Proof and claim locks
Claims you can check.
TARX is built on explicit contracts, claim locks, evals, self-tests, and proof artifacts. The product does not assert a capability it cannot show. Loop health is reported in the founder RC, loop timestamps update visibly over time, and loops run under explicit profiles: demo, stress, and overnight.
Codex and Builder
TARX does not replace
your coding agent.
It runs the loop around it. TARX is not a better code model and does not claim to be. It wraps coding agents with local runtime, loop control, proof, and escalation. When a loop needs code written, patched, or judged, TARX escalates to Codex or Builder as a critique and patching layer, captures the proof, and updates the next action.
What is live today
Founder RC proof.
- Packaged Electron opens to Always On in founder RC.
- Visible composer to runtime activity to evidence to inspector and lower-terminal truth.
- Bounded managed local watch sessions run locally in the prepared founder RC setup.
- Loop timestamps update visibly in the app over time.
- Loop health is reported as healthy_with_watch in the founder RC.
- Loop runner supports explicit profiles: demo, stress, and overnight.
What is not claimed yet
Boundaries stay visible.
- Public download, standalone, offline, or clean-machine readiness.
- Unbounded unsupervised autonomy.
- Full Codex or Claude Code replacement.
- Live mesh or Supercomputer execution.
- Enterprise policy enforcement.
- MCP memory as a live public capability.
FAQ
Builder questions
answered plainly.
Is TARX autonomous?
TARX runs bounded, governed loops with stop conditions, failure thresholds, and escalation. It does not claim unbounded unsupervised autonomy.
How is TARX different from Codex?
Codex is a coding agent. TARX is the loop cockpit around coding agents: local runtime, loop control, proof, and escalation.
What runs locally?
The prepared founder RC runs as a local managed runtime with visible runtime activity, evidence, and model/provider truth surfaced. Public clean-machine download is not claimed yet.
How do loops stop?
Loops stop through explicit stop conditions, failure thresholds, profile duration limits, or manual stop.
Founder alpha
Build with
TARX loops.
Founder alpha is open to a small group of builders who want AI work that keeps moving and stays inspectable.