OpenAI published a new view of the work people bring to ChatGPT this week. The data covers 165 work activities across nearly 100 countries, from preparing instructional material to analyzing business data. It is a much more useful level of detail than asking whether someone is an active user. [1]
Two other releases move in the opposite direction. ServiceNow is bringing business context and workflow actions into ChatGPT. Microsoft is offering a managed harness that runs the agent loop, tools, files, sandbox, and bounded delegation around a task. [2] [3]
One set of news helps us see the activity. The other two make it easier for AI to reach the systems where that activity happens.
The missing step is redesign. A faster interface can remove searching and copy-paste work. It can also accelerate an approval nobody needs, produce another report nobody reads, or update a record before the underlying decision is clear. The useful question is not simply where AI can enter. It is which part of the work should become different once it does.
01 / THE ACTIVITY
Start with the work people actually bring.
OpenAI Signals connects work-related ChatGPT messages to 165 Intermediate Work Activities, a set of categories tied to the O*NET framework for occupational work. The release is quarterly, from the first quarter of 2025 through the third quarter of 2026, and lets researchers compare activity mixes across countries and over time. [1]
This is closer to the level where a team can make a decision. “Analyze business data” or “prepare instructional material” describes work. “Adopt AI” does not. An activity gives you something to observe, bound, and compare with the way the job happens today.
The limits are just as useful. The dataset covers individual ChatGPT plans, not enterprise messages or Codex use. In the U.S. comparison, about 43% of the employment-weighted mapped task mix falls into an Other category outside the individually reported activities. OpenAI also controls the classification method and the underlying product data, though it publishes a methodology and downloadable aggregate files.
So this is a map of activity brought to one tool, not a map of all work and not proof of value. A frequent activity might be important. It might also be easy to attempt and hard to use. The next question belongs inside the workflow: what decision receives the output, and what happens after it arrives?
02 / THE WORKFLOW
The chat window is reaching the system of record.
The ServiceNow announcement makes that next step tangible. An IT team member will be able to find similar incidents, assess the risk of a change, and update a ServiceNow record without leaving ChatGPT. Customers choose which capabilities are available, and ServiceNow says its existing business rules and permissions still apply. [2]
Consider a routine incident review. Today, someone may read an alert, search past tickets, copy details into a new record, ask another person about the affected service, and wait for a decision. Bringing context and actions into one interface could remove several of those handoffs.
It does not tell the team which handoff deserves to disappear. The pause before a change may be wasted navigation, or it may be the moment when an owner notices that the affected service is more important than the ticket suggests. The useful redesign preserves the decision while removing the clerical path around it.
Availability also needs plain language. The ServiceNow MCP plugin is available now, with enhanced capabilities expected later in 2026. Voice, security, and Codex integrations carry dates in 2027. This is a mix of present access and announced direction, not evidence that the connected workflow is already complete.
The integration creates an opportunity to redraw the path. It does not supply the drawing.
03 / THE DESIGN
Managed plumbing does not choose the better process.
Microsoft's Copilot harness in Foundry Agent Service moves another layer out of the team's way. In public preview, the managed system combines reusable skills, connected tools with configured authentication and approvals, file and code execution, bounded subagents, and source-controlled agent definitions. Microsoft runs the agent loop and sandbox. The customer supplies the knowledge, procedures, tools, and limits. [3]
That division can be valuable. A team working on the incident example may not need to build its own file handling, context management, tool coordination, and execution environment before it can test the work. Less plumbing means the team can spend more time on the assignment and the result.
Microsoft's resilience guidance shows where ownership returns. Foundry can restart interrupted work with the original input, but the application must save progress and intermediate state. If the agent updates another system, the workflow must prevent the same action from happening twice. Conversation history alone is not enough to restore the job.
Those are workflow questions wearing technical clothes. What counts as progress? Which action can be repeated safely? Which external change needs an idempotency key, a review, or a rollback? A managed platform can provide the mechanism. The team still has to define the work.
The complication is speed. When integrations and harnesses remove setup effort, a weak workflow becomes easier to automate before anyone asks why it exists. The answer is not to rebuild every layer yourself. It is to make the decision, handoff, action boundary, and evidence visible before the new path becomes routine.
What this week's sources do not establish
They do not prove that activity-level usage creates business value, that the announced integrations improve outcomes, or that a managed harness makes every workflow reliable. The usage data excludes enterprise and Codex messages. ServiceNow's announcement mixes available and future capabilities. Microsoft's harness is in public preview, and its customer outcomes are vendor-reported. The practical test is one bounded workflow compared with the way the work happens now.
04 / PUT IT INTO PRACTICE
Redraw one workflow before connecting anything.
Choose one recurring activity that ends in a decision, update, or deliverable. Map the current path from request to result, including searches, copy-paste steps, waits, approvals, corrections, and the person who uses the output.
Draft one changed path. Remove or alter a single handoff, define what the system may read, prepare, or update, and keep a person at the consequential decision. Run a small sample against today's baseline. Compare cycle time, handoffs, rework, review effort, and errors. Stop if the new path hides evidence, expands access, or makes recovery harder.
One activity. One handoff worth changing.
Build: A one-page before-and-after workflow brief with the decision, changed handoff, permitted system action, baseline, and review owner.
Look for: A short trial reduces a handoff or cycle time without increasing errors, rework, review effort, or access, and the owner can explain what changed in the final decision.
Keep the change small enough to compare. If the handoff disappears but the decision gets harder to explain, the workflow did not improve.