What OpenAI published

OpenAI’s case study on Localiza describes a mobility company that reorganized work around four layers at once: ChatGPT Enterprise for day-to-day work, the OpenAI API for products, Codex for engineering, and more than 60 specialized agents for repeatable tasks. The stated goal is not “use AI somewhere” but “build AI-native mobility experiences” - which is a reorganisation claim, not a tooling claim.

The public summary is deliberately thin on numbers: it does not publish per-agent adoption, hours saved, or which teams own which agent. Treat it as a description of an architecture, not a benchmark.

The stack, layer by layer

Reading the four layers as a design, each one answers a different question:

  • ChatGPT Enterprise answers “where do people ask questions?” It is the general surface, the place where an employee types something once and gets an answer.
  • The OpenAI API answers “how does this get into our product?” It is the embedded layer, invisible to staff.
  • Codex answers “who writes and reviews the code?” It is scoped to engineering, with repository context.
  • 60+ specialized agents answer “which repeatable tasks run themselves?” Each one owns a narrow job.

That last layer is the interesting one. Sixty agents is not sixty chatbots. It is sixty narrow scopes - each with its own inputs, its own outputs, and ideally its own permission boundary.

Why many narrow agents beat one broad agent

A single agent that can do everything is easy to demo and hard to govern. You cannot answer “what is it allowed to touch?” because the answer is “anything”. You cannot audit a run because every run looks different. You cannot roll back a mistake because you do not know which step caused it.

Narrow agents invert all three:

  1. Scope is declarative. “This agent reconciles supplier invoices” tells you exactly which files it needs and which system it writes to.
  2. Runs are comparable. Two runs of the same narrow agent should produce the same shape of output, so a diff means something.
  3. Failure is contained. A broken invoice agent cannot send customer email, because that is a different agent with different permissions.

None of this requires sixty agents. It requires that each agent you do build has one job.

What to copy on a Windows desktop

If you run an agent on your own machine, the same split applies at a smaller scale:

  • One general assistant for ad-hoc questions, with no write access.
  • Three to five narrow routines for the jobs you actually repeat weekly - renaming and filing, reconciling a spreadsheet, drafting a recurring report.
  • Explicit folder scope per routine. The routine that touches D:\invoices should not be able to open D:\contracts.
  • A per-run log you can read in a minute. If you cannot tell what an agent did last Tuesday, it is too broad.

The local advantage is that you can enforce this with the filesystem itself. A narrow agent pointed at one folder is a permission boundary you can verify by looking at the drive, not a promise in a system prompt.

That is also the model MOOGH is built around: tasks are scoped to what you hand over, each run shows the files and commands it intends to use, and nothing executes before you approve it. Download MOOGH if you want to try the narrow-routine pattern on your own PC.

FAQ

Is this a customer case study or a benchmark?

A case study. OpenAI publishes it as an illustrative example of internal-style adoption, not as a controlled measurement. There are no published before/after cycle times.

What is the first agent a small team should build?

The one whose output is easiest to check. Invoice reconciliation or file renaming beats “research assistant”, because you can verify the result in seconds and the scope is a single folder.

Does this require ChatGPT Enterprise?

No. The architecture - general assistant plus narrow scoped routines - works with any model provider. Enterprise plans mainly change identity, data handling and admin controls.