Proaction’s Problem Was Not Demonstration, but Demonstration Capacity
OpenAI’s September 25, 2026 case study profiles Proaction, a company that provides software for fleets of cars, trucks, and construction equipment. Because every fleet differs in its vehicles, workflows, and operating practices, a generic slide deck is not enough to show how the product would fit. Proaction co-founder and COO Colin Knudsen previously had to involve engineers to build customized demonstrations, while the engineering team lacked the capacity to create one for every prospect.
Knudsen now gives Codex call recordings from Granola, customer emails, and spreadsheets shared by prospects. Codex uses that context to produce an interactive HTML environment that resembles Proaction’s product while reflecting the customer’s own vehicles and workflows. Knudsen creates four to six such demos each month, spending roughly 30 to 45 minutes on each. The important change is not simply that a webpage is generated faster. A sales conversation can now become an artifact that the customer can interact with and engineering can continue to use.
The Demo Shifts from Showing Capability to Co-writing Requirements
In a conventional sales process, the demo is usually something the product team has already built, and the customer can only comment on the existing interface. Proaction reverses that sequence. Once prospects see their own vehicles, equipment, and operating patterns, they can point out what needs to change and work with the seller toward a solution. The demo therefore becomes more than visual sales material. It also performs part of the requirements-clarification process.
That is why the main saving may come from shortening the clarification chain rather than from reducing coding time. Knudsen estimates that an engineer would need about 10 hours to produce a comparable demo, which implies 40 to 60 engineering hours saved each month for four to six demos. Proaction also says that the share of deals moving from initial contact into solution development rather than nurture increased by 50% to 60%, while sales increased by 60%. Those figures show the direction of the change, but they are estimates and attributions from the company. They do not by themselves establish that Codex caused all of the improvement.
The Execution Layer Is the Continuous Link between Context and Action
If Codex only generated demos, it would still be a faster prototyping tool. The more consequential part of Proaction’s account is that Knudsen connects Codex to Granola, Gmail, Slack, Linear, GitHub, and HubSpot. He uses it to retrieve call and email history, prepare follow-ups, create Linear issues, and update HubSpot opportunities. Proaction has also configured a scheduled automation that reviews recent calls and prepares sales updates for the team.
Codex consequently becomes a cross-system execution layer for the founder rather than merely a coding assistant. Knudsen handles 15 to 20 distinct tasks a day and estimates that Codex saves him 25 to 33 hours each month, in addition to the 33 hours reported as founder time saved in the case study. For a technical leader, the source of this value is not just the intelligence of an individual model response. It is the ability to preserve context and complete the next action across several systems. Tool use, context management, and sustained execution are closer to production value than code generation alone.
The Boundary Moves Earlier, from Sales Blueprint to Engineering Delivery
Proaction gives engineers the customized demo as a visual reference for the customer solution, with the goal of reducing questions and back-and-forth about what needs to be built. The company has also built a customer solution center where prospects can log in, explore workflows tailored to their business, and review sales materials. Non-engineering teammates can use those conversations to produce clearer requirements before engineering becomes involved.
This is an organizational change that technical leaders should take seriously. Previously, the boundary between sales promises, product design, and engineering implementation was more visible, with engineers acting both as builders and interpreters of complex requirements. Non-engineering roles can now produce highly specific interactive outcomes, which means more problems may surface earlier, but more unreviewed commitments may also reach customers sooner. Teams need to distinguish exploratory demos from delivery commitments and apply different review and rollback mechanisms to each.
Efficiency Does Not Automatically Produce an Accountability Chain
Proaction also uses GPT-Live-1 to build voice agents for fleet operations and GPT-6 Astra to accelerate the construction of agent experiences. The case describes a product direction that extends from recording and managing fleet information toward handling concrete workflows such as maintenance. For fleet software, that means AI may gradually participate in executing customer operations rather than simply offering suggestions inside an interface.
There is still an accountability chain between a customized demo and a real maintenance workflow, and the demo cannot conceal it. The material does not quantify customer-data permissions, the long-term maintenance cost of generated demos, or the intervention process when an agent fails. It also does not establish that Astra’s computer-use advantage will reproduce reliably across different tasks. The actionable position is to keep demos bounded as sales and requirements tools, record the data and promises they contain, and define human takeover, audit trails, and ownership for every agent workflow that reaches production. Saving more than 75 hours may justify investing in an AI execution layer. It does not justify skipping those controls.