What did Michael Preuss do for Blaxel's OpenAI Agents API launch?

I wrote Blaxel's launch article draft and supporting company, founder and engineering social copy. I connected the explanation to the cookbook and specified the visual, link, destination and approval requirements for each piece.

How did the Blaxel launch writing explain the integration?

The Blaxel draft explained how OpenAI managed the agent session, a Blaxel Sandbox ran the work and Agent Drive kept files available across runs. It distinguished retained files from a live session or conversation, then directed developers to a cookbook with explicit access prerequisites.

What did the Blaxel launch cookbook demonstrate?

In Blaxel's documented cookbook handoff, one agent writes summary.md. The script deletes that agent's OpenAI session and Blaxel Sandbox, then starts a fresh pair that reads the saved file and writes review.md. It checks source and handoff markers in the files. This path requires Agent Drive access.

Did Michael Preuss write the final published Blaxel launch article?

My documented contribution to Blaxel's launch was the article draft, supporting social copy and release preparation. The final published article carries Michael Stolarz's byline and is linked separately as the published launch reference.

Blaxel Product Launches

Make the integration concrete

For Blaxel's OpenAI Agents API launch, I wrote the article draft and supporting company, founder and engineering social copy. My job was to make Blaxel's role clear and give a developer something useful to try after reading the announcement.

The explanation centred on a concrete task: give an agent a computer, let it produce a file, and show how that file could remain useful after the session ended. OpenAI managed the agent session. A Blaxel Sandbox ran the work. Agent Drive could keep the files available for a later run.

That distinction shaped the writing and its connection to the OpenAI Agents API cookbook. The draft explained the integration; the cookbook gave readers a way to inspect it.

Show what survives the next run

The persistence claim needed a clear boundary. Agent Drive could retain files, including reports, notes and tool output. It didn't automatically transfer a live OpenAI session or conversation to the next agent.

The cookbook's optional handoff makes that distinction visible. One agent writes summary.md. The first session and Sandbox are deleted. A fresh pair then reads the saved file and writes review.md.

OpenAI Agents API + Blaxel Agent Drive

A report carried into a fresh agent session

Follow the cookbook's optional file handoff.

The first agent creates a report

First run Running the task

OpenAI session

Blaxel Sandbox

Read the source file and write summary.md.

Writes the report

Persistent files

Agent Drive

summary.md

Saved files stay available to the next run.

The cookbook checks that summary.md contains an exact marker copied from the source file.

Cookbook command ./run.sh --handoff

Read the cookbook

An illustration of the cookbook's documented handoff, with Agent Drive enabled. Files carry forward; a live OpenAI session or conversation isn't transferred.

The example checks the contents as well as the file's existence: the report must carry a marker from its source, and the review must carry that original marker plus a new handoff marker. That gives a developer something specific to verify. The README also states the access prerequisites, including Agent Drive for the handoff.

The social package gave each author a different way into the integration. The company draft introduced the product connection and pointed to the cookbook. The founder draft explained why an agent system needed compute, storage and networking. The engineering draft followed the session connection and the separate lifecycle of the files.

The underlying claim stayed consistent. The entry point, level of detail and planned visual changed with the person sharing it.

Launch social / Working draft

Three ways into the same launch

Company / X launch thread

OpenAI built the harness. Blaxel gives it a computer.
OpenAI manages the session, tools, approvals, and turns. The executor connects outbound from a Blaxel Sandbox, so the sandbox needs no inbound port.
Agent Drive keeps files available after temporary compute is cleaned up. Another sandbox can pick up the report, tool output, dependency cache, or notes in a later run.

Planned visual: Approved launch visual or architecture diagram
Destination: Launch article or cookbook
Before release: OpenAI approval and a public cookbook

Selected lines from my working social draft, with condensed visual and review notes. These are draft excerpts. View the three openings together.

I specified the visual, destination and approval requirements alongside the copy. For the company LinkedIn version, for example, the brief called for a short demo showing the session, sandbox execution and resulting artifact. That piece depended on an approved demo, public cookbook and approved OpenAI wording. Those dependencies were part of the release preparation.

My part in the launch

My contribution was the article draft, supporting social copy and release preparation. The article Blaxel published carries Michael Stolarz's byline. I link it as the published launch reference, separately from my draft work.

I used the same approach in the customer-story program: write the product explanation, connect it to an example a developer can inspect, and prepare the copy and visuals for the people who would share it.