What problem is worth solving?
OpenAI’s May 2026 Deployment Company announcement describes engineers working with leaders and frontline teams to select valuable workflows, integrate systems, and build, test and deploy them, with field learning feeding product teams.
Move from model access to sustained operational use while reducing repeated implementation work.
- WORKING ROLES
- Business owner, frontline users, customer IT, FDE and core product engineers
How does an FDE turn symptoms into a solvable problem?
The following is an FDE exercise inspired by the case, not a claim about undocumented project events. Reported team actions appear in the context above.
Observe a complete job
For the exercise, observe audience selection, policy lookup, execution and review. Record systems, spreadsheet handoffs and exception owners; separate information gathering from judgment.
Find the adaptation boundary
Replay duplicate identities, conflicting campaign rules and timeouts. Classify failures as configuration, tenant adaptation or a core product gap before changing prompts.
How does the solution enter the workflow?
- 01
Select
Select one bounded job, such as a verifiable re-engagement proposal for one store, with an owner and sample.
- 02
Build a thin slice
Connect data, business objects, read tools and cited advice in one complete path before widening coverage.
- 03
Integrate with work
Observe accepted, edited and abandoned suggestions; turn reasons into tests rather than tracking logins alone.
- 04
Feed the product
Keep mappings in adapters, reproduce common faults for core engineering and package stable task templates with owners.
Which decisions make the solution reliable?
When to stop custom work?
Keep customer-specific behavior in adapters. Consider core changes when distinct schemas reproduce the same problem; demonstrate reuse through migration tests.
Advice or execution first?
Start with advice while definitions and data are unstable. Enable writes after scope, recovery and outcome queries are testable.
One member, two identities
Synthetic exercise: two CRM exports use member_id=M-17 and loyalty_id=L-92 without an authoritative mapping.
- Tenant adapter
- Unknown mapping → no merge or outreach; the data owner supplies a versioned mapping.
- Product feedback
- Reproduce duplicate candidates with two records and propose an identity invariant test.
- Domain asset
- Package identity-conflict rules and rerun the same tests on a second synthetic CRM.
What should you do and deliver?
Choose one workflow and two exclusions
- OUTPUT
- Fit memo + fit/gap
- PASS CONDITION
- Each gap has evidence, an owner and a test
Adapt and quarantine two CRM schemas
- OUTPUT
- Adapter + conflict fixtures
- PASS CONDITION
- Unknown identities cannot silently merge
Separate three asset layers
- OUTPUT
- Tenant extension / core change / template
- PASS CONDITION
- A peer reproduces behavior on new data
How do you prove completion and reuse the work?
Acceptance checks
Review task completion, fault-localization time and second-adaptation effort, with unresolved issues and maintenance ownership.
Reusable assets
Reuse diagnosis, contracts, tests and product feedback mechanisms; keep customer rules specific.
Further reading and original sources
- OpenAI Deployment Company ↗OpenAI · 2026-05-11