The Activity View: How Much Oversight Is Actually Practical?
OpenAI's Activity View lets you inspect what a dot did while you weren't watching. It's the right idea — and it runs straight into the oldest problem in automated oversight: nobody reads the log.
Give an agent standing access to your tools and let it act while you're away, and you've created a new obligation: someone has to check what it did. OpenAI's answer is the Activity View, one piece of the permission architecture covered earlier in this series alongside Custom Rules and Auto-Review. It's the interface where a human can look at what a dot has been doing — its background research, the actions it took, the decisions it made about what mattered — and intervene if something looks wrong.
It's the right feature to build, and it's the kind of detail TechCrunch's coverage of the launch treated as secondary to the bigger story of dots' capabilities. It's also the feature most likely to quietly fail in practice, for reasons that have nothing to do with OpenAI's engineering and everything to do with how humans actually behave around dashboards they're told to check "when needed."
The oversight paradox
There's a well-worn problem in every domain that pairs automation with a human review step: the review step only works if a human actually performs it, and the entire point of automation is to reduce the amount of human attention a task requires. Push that reduction far enough and the review step becomes theater — a checkbox that exists to satisfy a safety requirement, rarely exercised, because the whole appeal of the automated system was that you didn't have to watch it closely.
Dots is a sharper version of this problem than most prior automation, because a dot generates activity continuously and across multiple domains at once. A single dot might touch customer feedback channels, a codebase, and a shared doc in the same afternoon — each producing its own trickle of loggable activity. Multiply that by several dots running as a team, which OpenAI explicitly supports, and the volume of activity a conscientious user would need to review to genuinely stay on top of things starts to look less like "check in on your agent" and more like a part-time monitoring job — precisely the labor dots was pitched as eliminating.
An oversight tool that requires constant, careful use to catch problems is only as strong as the discipline of the person who's supposed to be using it — and the entire selling point of an always-on agent is that you don't have to pay that kind of attention anymore.
Where the design actually helps
To be fair to OpenAI's approach, the Activity View isn't the only safeguard doing work here, and it isn't meant to be the last line of defense against every possible failure. Auto-Review checks consequential actions before they execute, which means the highest-stakes category of mistake — an action serious enough to matter — is supposed to get caught upstream of the log, not discovered after the fact by someone scrolling through history. Custom Rules further narrow what a dot can attempt without triggering approval in the first place. And proactive research, the biggest source of continuous background activity, is constrained to read-only access — meaning most of what accumulates in an Activity View from that source is observation, not action, lowering the stakes of anything a user misses.
That layering is a genuinely sound design instinct: don't make the human-review step the only thing standing between a dot and a mistake. Put automated gates earlier in the pipeline, and let the Activity View function as a secondary, lower-stakes audit trail rather than the primary safety mechanism. If that layering holds up as designed, the Activity View's practical burden is smaller than it first appears — most of what a user would find there is context, not crisis.
Where it's still an open question
What isn't addressed anywhere in OpenAI's public materials is how the Activity View is meant to be checked in practice — whether it surfaces anomalies proactively, whether it gets summarized rather than requiring a full scroll, or whether it's simply a raw log a user has to think to open. The difference between those designs is the difference between an oversight tool that gets used and one that becomes, functionally, a compliance artifact nobody consults until something has already gone wrong and someone's asking for a post-mortem.
This is the same tension every "human in the loop" system runs into once the loop gets large enough: the loop is only meaningful if the human's attention scales with the agent's activity, and the entire commercial case for dots is that a human's attention shouldn't need to scale with what the agent does. Something has to give, and right now it's not clear from public materials whether OpenAI's answer is better tooling around the Activity View or an implicit bet that Custom Rules and Auto-Review will catch enough upstream that the log rarely needs a careful read at all.
How this compares
Meta's equivalent for Muse, described in Meta's own launch materials, is a full audit trail generated by every action Sentinel approves, blocks, or escalates — architecturally similar in spirit, with the added structural benefit that Sentinel itself is a second agent actively gating actions before the audit trail even needs consulting, rather than relying purely on after-the-fact review. Grok Bot's public materials, by contrast, don't describe an equivalent oversight interface at all in the sources available at launch — another instance of the documentation gap flagged elsewhere in this series.
The honest conclusion is that Activity View is a well-reasoned answer to a problem every always-on agent has to solve, but it's a feature whose real-world value depends entirely on habits OpenAI can't fully engineer — whether a busy person actually opens it. That's not a knock unique to dots; it's the oldest unsolved problem in human oversight of automated systems, arriving in a new, more capable form. Anyone deploying dots at scale would do well to build their own habit or process around checking it, rather than assuming the feature's existence is the same thing as the oversight actually happening.
Part 28 of 30 in the ChatGPT Dots series. Previously: Pricing the Unpriced: What Additional Dots Probably Cost. Next: Enterprise, Edu, and Healthcare: The Slow Lane for Dots. Browse more builder insights or explore AI skills at aiskill.market.