Uber is giving 30,000 employees an AI agent. Measure finished work, not logins

THE SIGNAL IN ONE SENTENCE

Uber is about to run a very large workplace experiment. The awkward part is that the experiment will not look like one. OpenAI announced on October 22 that Uber is rolling out ChatGPT Work to more than 30,000 employees across its global workforce. The deployment expands an initial pilot of 1,000 employees and gives teams an agent inside ChatGPT Enterprise that can take on multi-step work. According to the announcement, the agent can connect with tools including Google Drive, Gmail, Google Calendar and Slack. OpenAI says employees can use it to research information, prepare meeting briefs, create presentations, analyze data and complete workflows across applications. Uber is supporting the rollout with approved integrations, an internal AI skills library and dedicated employee training. That is a real change in scale. It is also a measurement trap. Thirty thousand available seats do not tell us whether the system helped anyone. Login counts do not tell us whether the work was correct. Prompt volume does not tell us whether employees saved time, spent more time reviewing errors or quietly stopped using the tool after a bad week. The plain signal is simple: measure finished work, not AI activity. Every serious agent deployment needs an outcome ledger. For each task, the ledger should connect what the employee intended, what data and tools the agent touched, what it produced, how much human work followed, what went wrong and whether the result survived contact with the real business. Start with the task. “Used ChatGPT Work” is not a unit of work. “Prepared the weekly regional operations brief from six approved sources and delivered it before the meeting” is. So is “compared three marketing concepts against the campaign brief,” “reconciled a finance variance,” or “turned a product discussion into a reviewed decision record.” Define the task before the agent begins. Name the owner, deadline, authorized sources, required output and conditions that make the work complete. If the definition changes halfway through, record that too. Otherwise the organization will confuse a fluent draft with a completed assignment. Then preserve the input boundary. An agent connected to files, mail, calendars and chat can be more useful because it sees the context employees already use. The same connections increase the blast radius of a mistaken request, excessive permission or malicious instruction hidden in a document. The ledger should show which connectors were enabled, which systems were actually queried and which records contributed to the result. It should not copy sensitive contents into an analytics warehouse merely to prove that the agent touched them. A reference, permission record and retention rule can establish provenance without building a second shadow archive of company conversations. Least privilege matters here. A meeting-brief task may need a calendar event, a named folder and a short set of messages. It does not automatically need every email the employee can read. Access should be limited by task, time and purpose, with separate approval for actions that send, edit, delete or submit information. Next, record the agent's work in a form a person can inspect. That does not mean dumping an unreadable activity stream on the employee. A useful receipt identifies the plan, sources, tool calls, transformations, unresolved questions and final artifact. The raw trace can remain available for authorized investigation, while the everyday view explains what happened in plain language. Now count the human work. This is where many productivity stories become suspiciously tidy. If an agent creates a slide deck in ten minutes and an employee spends two hours checking numbers, repairing citations, restoring missing context and calming the typography, the organization did not save the full drafting time. It moved labor from composition into review. The finished-work ledger should record active review minutes, corrections, approvals and escalations. It should distinguish a cosmetic edit from a factual repair, a policy violation or a data exposure. Five corrected commas and one invented customer metric are not six equivalent edits. Error severity needs a shared scale. A harmless formatting mistake belongs in one category. A wrong internal date belongs in another. A fabricated financial figure, an unauthorized message or a disclosure of restricted information belongs somewhere much higher. Teams should record near misses as well as incidents, because a human catching a serious error before delivery is evidence that the control worked and that the system almost failed. Completion itself needs several states. Completed means the assigned result was accepted and used. Reworked means the agent output required material correction. Abandoned means the employee stopped and finished another way. Failed means the workflow could not produce the required artifact. Escalated means a person or specialist system had to take control. Those labels reveal more than a green “done” badge. A workflow can show high use and low completion. It can save time on ordinary cases while creating painful failures on unusual ones. It can produce many drafts that nobody trusts enough to ship. Measure the downstream result too. A brief is not valuable because it exists. It is valuable if the meeting starts with the right facts and reaches a decision faster. An analysis is not valuable because it contains a chart. It is valuable if the figures are correct, the assumptions are visible and the team can reproduce the conclusion. A presentation is not finished when the file is generated. It is finished when the responsible person approves it for its intended audience. For each repeated workflow, choose a small set of outcome measures. These might include cycle time, accepted completion, review effort, correction rate, severe-error rate, rework after delivery and cost per accepted result. Compare those measures with a recent non-agent baseline and with a control group when feasible. Do not compare a carefully supported agent rollout with last year's messiest week and call the difference intelligence. Cost belongs on the same page. The bill includes more than model tokens or software seats. It includes connector work, identity controls, security review, evaluation, training, support, incident response and the employee time spent supervising the system. It may also include duplicated work when people keep a private manual process because they do not yet trust the official one. Savings should be attached to accepted outputs, not generated ones. A cheap draft that never ships is still waste. A more expensive workflow that reliably prevents a costly error may be a bargain. The internal skills library deserves its own ledger. A skill can package instructions, examples, scripts and tool behavior for a recurring task. That makes good practice reusable. It can also spread a bad assumption across thousands of people with admirable efficiency. Every skill should have an owner, version, purpose, approved data sources, required permissions, evaluation set, change record and retirement rule. Employees need to know whether a skill is experimental, recommended or mandatory. Security teams need to know whether it can execute code, reach the network, alter records or invoke another tool. When a source system, policy or model changes, somebody should be responsible for retesting the skill before the old instructions keep marching through new work. Training should cover refusal and correction, not only adoption. Employees need practice recognizing a task that should stay with a person, narrowing a connector's scope, checking sources, challenging an unsupported claim and reporting a near miss without being blamed for slowing the rollout. A company cannot learn from hidden failures if workers believe that every correction makes them look uncooperative. Worker control also belongs in the outcome ledger. Is the agent optional for the task? Can the employee see what it accessed? Can they stop an action before it sends or changes something? Can they correct the record? Is use data being evaluated as product telemetry, as a performance signal about the worker or both? Are employees with disabilities given accessible alternatives and enough time to learn the system? Those questions are not decorative culture work. They affect data quality. People will route around a system, conceal mistakes or avoid difficult cases if the measurement program feels like surveillance. A trustworthy evaluation separates learning about the tool from ranking the employee wherever possible, publishes the purpose of the data collection and limits who can use it. Break results down carefully. A global workforce does not have one standard workflow. Tool access, privacy law, language, network quality, job design and local management differ. A company-wide average can hide a region where connectors are unavailable, a function where review work doubles or a group whose tasks are poorly represented in the skills library. Report outcomes by task family, function, region and accessibility need when sample size and privacy permit. Use aggregation and minimum group sizes so measurement does not become a map of individual behavior. The goal is to find where the system needs repair, not to manufacture a new leaderboard of who typed the most prompts. Rollout gates should follow the evidence. Begin with bounded, reversible tasks. Establish the baseline. Test the workflow on ordinary and adversarial cases. Require human approval for consequential outputs. Expand permissions only after accepted completion, error severity and review load meet a written threshold. Pause a skill or connector when a serious incident, drift pattern or policy change crosses its stop condition. Keep the system of record outside the agent unless the organization explicitly moves that responsibility. A generated meeting summary can help, but the approved decision record should remain the authoritative artifact. An agent can prepare a finance analysis, but the controlled ledger and responsible approver still decide which figures count. OpenAI's announcement is clear about what has begun. It says Uber is expanding from 1,000 pilot users to more than 30,000 employees, connecting the agent to common workplace tools and supporting people with integrations, skills and training. It also says the companies plan to share adoption, use cases and measurable outcomes as the rollout progresses. That future tense matters. The announcement does not publish adoption rates from the pilot, accepted-completion results, time saved, review effort, error rates, worker satisfaction, accessibility findings, data-governance details or independent evaluation. It is a joint company announcement about a deployment, not evidence that the deployment improved work. The rollout may produce genuinely useful changes. An operations team may assemble a brief without chasing ten tabs. A finance analyst may spend more time testing a conclusion and less time reformatting a workbook. A product manager may leave a meeting with a decision record that people can actually find. Good. Put those finished results in the ledger. Record the task, access, trace, review, correction, severity, cost and downstream outcome. Include the abandoned attempts and quiet failures. Give workers a way to challenge the measurement. Publish aggregate evidence after the novelty wears off. Thirty thousand employees can generate a spectacular amount of activity. The number that matters is how much trustworthy work reaches the other end of the line, and how clearly the company can explain what it cost to get there.