What is up people!
Think of a useful thing you’ve been meaning to make: a guide for a new colleague, a comparison of the software your team uses, or a proper explanation of a process that currently lives in eight documents and somebody’s head. You could probably ask AI for help with each piece. You would still have to turn the pieces into something another person could use.
That is the kind of job worth trying again after this week’s model releases. OpenAI’s GPT-6 Astra and Anthropic’s Fable 5.1 both put more emphasis on sustained work. The interesting experiment is to give one of them responsibility for a complete, bounded project, then find out how much work is actually left for you.
There is a good version of this, where the neglected guide finally gets made. There is also a version where you acquire forty pages of homework. The difference deserves more attention than another benchmark chart.
📌 TL;DR
Start with the finished object. Describe what someone should be able to use at the end, including the awkward cases a summary would leave out.
Give the work somewhere to remember itself. Longer projects need an explicit record of sources, decisions, and unfinished work.
Make the result easier to check. Ask for the supporting evidence alongside the deliverable, and count your review time when deciding whether the experiment worked.
Start with the finished object
In its Astra announcement, OpenAI describes stronger multistep work and better adherence to document, spreadsheet, and presentation templates. The company is rolling it out to Plus, Pro, Business, and Enterprise subscribers within existing usage allowances. Access can arrive gradually, and Enterprise administrators need to enable it.
Anthropic’s Fable 5.1 release makes a similar case for longer assignments. Its current product page lists access for Pro, Max, Team, and Enterprise users. These are the companies’ descriptions, not a comparison I’ve run on your work. They justify a fresh trial if you have access; they don’t establish that you should buy another subscription.
Suppose you organize community workshops. Volunteers answer the same questions about arrival times, room setup, cancellations, and equipment. The answers are scattered across eight approved documents. You’ve wanted a simple volunteer guide for months, but pulling it together keeps losing to the next workshop.
An obvious request would be to summarize the eight files. That might produce eight accurate summaries while leaving the original problem almost untouched. A new volunteer still has to work out which instruction applies, find the relevant exception, and connect the answer to the event they’re helping with.
A more useful assignment is to produce the guide itself. Tell the assistant who will read it, what that person needs to do, which documents are authoritative, and where the finished file should live. Include a sample of the writing or layout you want. Ask it to bring conflicting instructions back to you instead of silently choosing whichever sentence sounds more plausible.
The distinction shows up in the output. A summary might say that the venue has rules for equipment. A usable guide tells the volunteer where to collect the projector, what to check before the room opens, and whom to contact when the cable is missing, provided the source material actually contains those answers.
You are giving the assistant a more demanding job because the pieces have to fit together. It must notice when two sections use different names for the same room, avoid repeating the cancellation policy in three places, and leave a clear question when the source doesn’t explain something. Those connections are much of the work you were postponing.
Start by asking for one representative section. Choose something with a little friction, such as opening the room, where several documents might overlap. If the sample merely rearranges sentences, correct the assignment before asking for the whole guide. If it answers the questions a volunteer would actually have, you have a reason to continue.
This small sample also gives you a fairer test of the new model. A vague request can make a strong model look unhelpful, while an easy request can make a weak process look finished. One section with a real complication gives both of you something specific to improve. The method was useful before these releases; a stronger model gives you a reason to retry a job that previously needed too much help.
Give the work somewhere to remember itself
Once the assistant starts combining documents, its job includes remembering decisions. Perhaps you confirm that the newer venue instructions replace the older ones, or decide that the guide should cover volunteers rather than paid instructors. Those answers need to survive the next ten changes.
OpenAI describes an experimental Astra feature in Codex that keeps notes across context windows and lets the model search earlier windows. A context window is the amount of material a model can work with at once. This feature is intended to preserve details during long sessions; it isn’t yet a universal default.
There is an instructive failure in Anthropic’s new Fermat formalization report. Early attempts lost track of project state. The researchers describe progress after adopting Prove2Me, which recorded the relationships between mathematical tasks and helped agents find and reuse completed work. The organization surrounding the model contributed to the result.
Your volunteer guide doesn’t need a mathematical research platform. It does need somewhere to record that the September venue sheet supersedes the June sheet. A short project note can carry that decision, the reason for it, the remaining questions, and the location of the latest draft.
For example, imagine one source says volunteers should arrive at eight and another says eight thirty. The assistant asks, and you confirm that eight applies to instructors while volunteers arrive later. Saving only “arrival time: eight thirty” would lose an important distinction. Saving the two roles and their respective times protects the next section about who opens the building.
That is why a useful progress note records decisions rather than a diary of effort. “Read the files and worked on the guide” tells the next session almost nothing. “Arrival times differ by role; the organizer confirmed the distinction; equipment instructions remain unresolved” gives the work a place to continue.
Keep this record small enough to read. You don’t need a dashboard for a document. You need the current draft, the approved inputs, and a short explanation of the decisions that would otherwise be easy to lose. Ask the assistant to update the explanation when you correct it, and check that important corrections reached the actual guide as well.
This becomes particularly useful when the job resumes later. Instead of reconstructing the conversation, you can ask the assistant to read the project note, inspect the current draft, and continue with the unresolved items. If it cannot access those files, attach them again. A reassuring claim that it remembers is less useful than seeing the right decision in the right section.
When the venue changes its opening time next month, the source record also tells you which sections might need updating. Keep that explanation connected to the guide, and the first version becomes easier to maintain.
Make the result easier to check
The scale of Anthropic’s mathematical result is striking. Its September 4 report describes an eleven-day effort to formalize an existing proof of Fermat’s Last Theorem in Lean, a language whose checker verifies the logical steps. This used an internal research model roughly comparable to Fable 5.1 and about six billion output tokens. It wasn’t an ordinary chat session, and Fermat’s theorem had already been proved.
The report says Lean checked the resulting formalization. An office document has no equivalent test that can establish every part of its usefulness. That limits the analogy: we can borrow the idea of making checks part of the process without pretending that a volunteer guide can be certified like a mathematical proof.
Nathaniel Whittemore makes a related point in AI Daily Brief’s discussion of agentic loops: knowledge work needs deliberately designed ways to decide whether a result is good enough. That is useful advice when an assistant can keep revising long after a normal conversation would have ended.
For the guide, ask for a separate source table. Each instruction should point to the document and section supporting it. Keep the table out of the volunteer-facing copy if it makes the guide harder to read. It exists so the person reviewing the work can quickly compare an instruction with its source.
A link alone isn’t proof. Open a few of the cited sections and check whether they support what the guide actually says. If the guide tells volunteers they may move a projector between rooms, a citation to a document that merely lists the projectors does not establish permission to move them. That small difference could disappear inside otherwise fluent prose.
Then try the guide with questions someone might ask during a workshop. What happens if the room is locked? Where does a late volunteer go? Who can approve a cancellation? A useful draft either provides an answer grounded in the documents or identifies the missing information clearly enough for you to fill it in.
Include at least one question the sources cannot answer. That tests whether the assistant can leave an honest gap. A tidy document with a visible “confirm with the organizer” note may be closer to useful than a seamless document that invented the organizer’s policy.
Some checks can be mechanical, such as confirming that every source appears in the source table or that every section has a heading. Others require judgment. A guide can pass all the mechanical checks and still bury the arrival instructions beneath two pages of background. Read it in the order a volunteer would need it, with their first task in mind.
Finally, count the cost of review. If you spend an hour fixing a document that would have taken you forty minutes to write, that particular attempt hasn’t saved time. It may still have taught you something, but you should be willing to reduce the scope, improve the inputs, or do the remaining work yourself. More revisions are worthwhile only while they are resolving identifiable problems.
Also this week
Anthropic announced Enterprise Frontier Safeguards, designed to let customers keep monitoring data in cloud infrastructure they control and route human review to their own people. The phased rollout is planned for later this fall, with an interim zero-retention arrangement for eligible customers.
This is relevant when a proposed AI project depends on internal documents. It is an enterprise arrangement with eligibility conditions, not a privacy setting every subscriber has today. For the exercise below, use documents you’re already allowed to put into your chosen tool. A model upgrade doesn’t change that permission.
Try this: finish one neglected document
Here is a suggested exercise, not a workflow I’ve personally tested. Choose a small document you’ve been postponing and gather the approved source material. A guide for volunteers works, but so does a checklist for running a meeting or an explanation of how your team names and stores its files.
Pick something you understand well enough to review. Before opening the chat, write one ordinary question the finished document must answer. That gives you a reason to reject a polished result that doesn’t help.
You can adapt this brief:
Create a practical guide for [reader] so they can [specific task] using the attached approved documents. Produce an editable draft in [format]. Use [reference] as the model for tone and layout.
Begin with one representative section about [task]. Flag conflicting instructions and missing facts. Ask me only for decisions that would change the content; record my answers with the source decisions.
After I review the sample, complete the guide. Keep a short project note with the current draft location, settled decisions, and unresolved questions. Provide a separate source table linking each instruction to its supporting document and section.
Check the finished guide against [three realistic questions]. Report anything those checks cannot establish. Make at most two revision passes, then return the draft and any unresolved issues. Leave the original files unchanged and don’t distribute the guide.
When the sample arrives, review the substance before the formatting. Fix a missing exception or confusing instruction first. Once the assistant understands that standard, let it complete the rest and inspect whether it applied your correction consistently.
Keep the best brief and the decisions you made while reviewing. If the experiment works, you’ll have a useful starting point for the next update. If it doesn’t, you’ll have a specific account of what failed, such as incomplete sources or too much rewriting, instead of a general feeling that AI was disappointing.
For the final check, give the guide to someone who wasn’t involved in creating it and ask them to find the answer to that ordinary question you wrote down. Notice where they hesitate. If they can find the answer and act on it without calling you, the document is beginning to do the job you wanted it to do.
P.S. An AI wrote these sentences from this week’s primary sources. Payton set the editorial standards and what good looks like. He wants to be transparent when AI wrote the issue.