OpenAI's internal tools ship inside Slack and chat, not new dashboards

The tools OpenAI put in front of its own employees

On September 29, 2025, OpenAI launched a series called 'OpenAI on OpenAI,' introduced by Chief Commercial Officer Giancarlo Lionetti, showing how the company runs parts of its own business on its APIs. The post names five internal systems and, notably, their internal tool names.

They are GTM Assistant, DocuGPT, Research Assistant, Support Agent, and Inbound Sales Assistant. Each is described by the problem it solves and the workflow it sits inside — sales prep, contract review, support ticket analysis, support operations, and lead handling.

What stands out when you read for the interface, rather than the model, is where these tools live. OpenAI didn't describe a suite of standalone apps. It described tools embedded in the places work already happens.

Slack is the frontend for GTM Assistant

The clearest interface detail in the post is that GTM Assistant is 'a Slack-based tool that centralizes account context and expert knowledge.' The company chose the chat surface its sales teams already use rather than asking them to open a separate research portal.

That choice matters for adoption, and the post says so plainly: deployments 'often outpace the change needed for organizations to leverage this technology.' Meeting people inside Slack removes one of the largest sources of that lag — the cost of learning a new place to go.

The remaining tools follow the same conversational pattern. Research Assistant 'turns millions of support tickets into conversational insights,' and the Inbound Sales Assistant 'personalizes responses for every lead' and 'answers product and compliance questions instantly.' The interface is a question and an answer, not a new screen to master.

DocuGPT and Support Agent point at a different surface: structured data and agents

Two of the tools describe something other than a chat box. DocuGPT 'converts contracts into structured, searchable data' for finance teams. Here the output is a queryable dataset — the frontend is search over structured records, not a conversation with a document.

Support Agent is described as 'an operating model built on AI agents, continuous evals, and dynamic knowledge loops.' The post frames its effect on the people using it: it 'positions reps as system builders rather than ticket handlers.'

It turns every interaction into training data, raises quality, and positions reps as system builders rather than ticket handlers.Montana Labs

That reframing is a frontend statement in disguise. The human is no longer the end user of a form; the human is tending the loop. The interface a rep touches is the eval and the knowledge base, not just a reply field.

What the surface choices tell teams building on the same APIs

OpenAI says its goal is 'to share patterns companies can adapt,' and the most transferable pattern here is not any single model call. It is the decision to route frontier capability through interfaces employees already inhabit — Slack, search, and agent loops — rather than building destinations people must be trained to visit.

The post claims these teams 'deliver changes in weeks instead of quarters.' If that speed is real, part of it comes from not designing new frontends from scratch each time. Embedding in existing tools is a shortcut past the adoption gap the piece names as its central tension.

For teams building on the same APIs, the implication is concrete: the hard problem revealed by OpenAI's own tools is less about the model and more about picking the surface where expertise gets captured and returned. Start with where the work already lives — a Slack channel, a search field, an eval loop — before building anything new to look at.