## What this release changes in practice

The useful question after a model release is what you can now ask an agent to
finish. A stronger model may take a task further, use more of your existing
tools, or need fewer corrections. Your workflow still needs a way to tell
whether it reached the result you wanted.

OpenAI's [GPT-6 Astra announcement](https://openai.com/index/gpt-6-astra/)
describes improvements in computer use, software engineering, and following
user intent. Its [model guidance](https://developers.openai.com/api/docs/guides/latest-model?model=gpt-6-astra)
also describes steering work while it is underway and continuing independent
work while tools run.

[Grok Bot](https://x.ai/bot) presents delegation through persistent agents that
use apps, coordinate work, and run routines. Its
[documentation](https://docs.x.ai/grok-bot/overview) explains how people provide
tasks, context, and access, then review results and provide corrections.

Those are provider descriptions. This note proposes a practical evaluation;
it does not report a ReactorJet benchmark of either product.

## Give the agent a finish line

Try a small browser bug: a form submits twice when a person clicks quickly.
Give the agent a concrete brief:

> Fix duplicate form submissions. One action should create one submission.
> Preserve keyboard access, validation, and recovery after a failed request.
> Prepare the patch and evidence for review; leave production unchanged.

The agent can inspect the repository and choose an implementation. A clear
brief gives it room to work while preserving the decisions you have already
made. Record any later change to the requirements in the same brief so the
evaluation follows the current task.

## Keep the check outside the proposal

Before the agent edits code, save a browser test that reproduces the failure.
Keep that acceptance check outside the files the proposing agent may edit.
Run it separately against the candidate, alongside checks for keyboard
submission and retry behavior after a network error.

This is what a workflow that verifies itself should mean: verification is part
of the system, with evidence that can be inspected independently. The agent's
own completion message is one account of the work, not the acceptance decision.

## Use a few clear parts

- An [intent brief](/components/intent-brief) records the expected result and permitted changes.
- An [independent evaluator](/components/independent-evaluator) checks the candidate against the agreed behavior.
- A [policy gate](/components/policy-gate) decides which results can advance and which need review.
- An [evidence packet](/components/evidence-packet) keeps the patch, checks, and decision together.

For a task that uses several apps, use the same pattern. Specify the finished
deliverable, limit access to what the job needs, and check the result in the
system where it matters. A scheduled report might need source reconciliation;
a support draft might need a policy check before sending.

## Try it, then compare the outcome

Run the same bounded task with your current setup and the new one. Keep the
starting state, acceptance checks, and permissions consistent. Record whether
the acceptance checks pass, how often a person intervenes, the total time, and
the cost of unsuccessful attempts as well as successful ones.

Use a small set of repeatable tasks before drawing conclusions. One polished
run can show a possibility; repeated results tell you whether to change how
you work.

Start with the [independent-check tutorial](/guides/tutorial/run-an-agent-task-with-an-independent-check),
then [trace a failed run](/guides/tutorial/trace-a-failed-agent-run) to see whether
your workflow also explains the cases that do not finish.