GPT-6 Astra still needs boring engineering

GPT-6 Astra was the single biggest technology conversation on X on 5 September 2026, and it is easy to see why. OpenAI describes it as its most capable broadly deployed model, with notable advances in computer use, coding, software engineering and efficiency. OpenAI is framing the release as entering the “AGI era”, while president Greg Brockman said it “might be about this model”. Those are large claims. For the automation work I care about, though, the useful question is smaller: what can I now trust an agent to do inside a real system?

The demo is not the pipeline

The public demos circulating are genuinely interesting. Astra is shown driving multi-step desktop and browser workflows, including turning a listing into 3D modelling work and moving through Blender plus web tasks faster than previous models. Better computer use matters because many business processes still live behind interfaces rather than neat APIs.

But a successful demo is evidence of capability, not evidence of production reliability. A client workflow has awkward files, expired sessions, inconsistent page states, slow APIs and outputs that look plausible while being wrong. The model can get substantially better and those failure modes do not disappear.

I see the same distinction in AI video pipelines, REST integrations against LLM and image APIs, and agentic workflows built with tools such as Claude Code and MCP. The impressive part is often one fuzzy step. Shipping it means engineering everything around that step.

Keep the outer loop deterministic

My preferred pattern is a deterministic outer loop with the model handling fuzzy inner work. Code decides what stage runs next, what inputs are allowed, how long a task can run, when to retry and what counts as failure. The model gets room where judgement is useful: interpreting messy material, choosing between reasonable actions or operating an interface that cannot be reduced to a stable endpoint.

That split also makes debugging less theatrical. If an agent fails halfway through a ten-step workflow, I want a state I can inspect and resume, not a long transcript ending with an apology. Some of the small experiments behind this approach belong in my prototype lab, because prototypes are where the boundary between model judgement and ordinary software becomes visible.

Verify the artefact, not the claim

An agent saying “done” is not a completion condition. If it generated an image, inspect the image or its required properties. If it edited code, run the checks. If it created a page, verify the rendered result and the important interactions. If it moved data through an API, validate the resulting record rather than trusting the tool-call summary.

This sounds obvious, but stronger models make it easier to skip. Fluent explanations create confidence. Production systems need evidence.

• Retry transient failures, but cap retries and record why they happened.
• Validate outputs at boundaries before another system consumes them.
• Set budgets for tokens, API calls and expensive generation steps.
• Give agents narrow credentials, scoped to the actions they actually need.

More capability means tighter boundaries

The safety notes around Astra reinforce that approach. OpenAI’s internal evaluations put the model across a “Critical” cybersecurity threshold: it could find and exploit vulnerabilities with less guidance. That prompted delayed safeguards and limited early access. System cards and reports also describe reduced interpretability and a higher risk of concealment, which has intensified the argument over control and restricted access.

For me, that is not an argument for avoiding agents. It is an argument for keeping them on a short lead. Credentials should be narrow and revocable. Destructive actions should require stronger gates. Certain steps should never be delegated simply because the model appears capable of completing them.

Capability is permission to attempt more, not permission to trust more.

Cost still decides what ships

There is another release this week that matters to practitioners. Anthropic released Claude Fable 5.1 with cost reductions specifically for agentic tasks and enterprise safeguards. The competitive headline may be model capability, but the less glamorous number in an automation proposal is cost per successful run.

Agents can multiply inference calls quickly: planning, tool selection, retries, visual inspection, correction and final verification. An automation that works beautifully but costs too much at normal client volume is still a prototype. Efficiency improvements can therefore matter as much as a more impressive desktop demo.

Sceptics are right to point at the gap between flashy demonstrations and real-world reliability. I would not use that gap to dismiss Astra. I would use it to define the engineering work. Better computer use expands the set of fuzzy steps we can hand to a model. It does not remove retries, verification, permissions, observability or cost control.

The models are getting less constrained by what they can do. Good automation engineering is increasingly about being precise over what they are allowed to do, how we know they did it correctly, and what happens when they do not.