OpenAI added a June 3 update to its AgentKit announcement: Agent Builder and the Evals product are winding down, and they will no longer be available on the OpenAI platform after November 30, 2026. OpenAI recommends the Agents SDK for workflows that should continue as code and Workspace Agents for use cases better suited to natural-language prompting.

The lesson for a remodeler, builder, designer, showroom, supplier, distributor, or trades business is not that visual builders are bad. It is that the diagram on a vendor's screen is not the workflow. The durable asset is the operating record underneath it: what starts the job, which sources are allowed, what the system can do, where approval is required, how success is tested, and what happens when it fails.

A workflow is more than its canvas

Consider an AI-assisted subcontractor scope review. A project manager uploads drawings, specifications, and proposals. The system identifies missing scope, links each flag to evidence, drafts questions, and waits for approval before anything goes to a trade partner. A visual canvas may make that sequence easier to build, but the business logic lives in the inputs, source rules, output format, approval boundary, and evidence trail.

If those details exist only inside one hosted interface, changing platforms becomes a reconstruction project. If they exist in a plain workflow record, the team can compare a coded agent, a natural-language workspace agent, another vendor, or a manual fallback against the same job definition.

Separate the job definition from the tool

Write the workflow in business language before choosing how it runs. Name the trigger, required documents, data owner, allowed tools, output fields, approval step, timeout, retry rule, and final system of record. For a lead-follow-up workflow, that might mean a consented form submission starts research; approved website and CRM facts ground the draft; a staff member approves the message; and the CRM stores the final version and status.

The current OpenAI Agents SDK documentation exposes the engineering pieces teams should expect in a code-based implementation, including tools, guardrails, human-in-the-loop controls, sessions, context management, and tracing. Those capabilities matter, but they still need a product-specific definition of good. A scope-review agent should be measured on evidence coverage, missed exclusions, unsupported flags, and reviewer corrections, not a generic model score.

Do not retire the eval when an eval product retires

A vendor discontinuing an evaluation surface does not make evaluation optional. Keep a small set of representative jobs outside the orchestration layer: a clean proposal, a proposal with a hidden exclusion, a drawing/spec conflict, a missing attachment, and a case that must stop for human review. Store the expected result, source evidence, allowed actions, and pass criteria in a format the next implementation can run.

Run that set before migration, during parallel testing, and after release. Compare outputs and trajectories, not just whether both systems produced a polished paragraph. Check which sources were used, which tool calls ran, whether approval was requested, how retries behaved, and whether the final record reached the correct project or customer file.

Keep a manual lane for important work

A portable workflow also has a fallback. If the agent service is unavailable, the business should know who receives the task, where the source packet lives, which template to use, and how to mark the job complete. That is especially important for bid deadlines, change orders, purchasing decisions, client communications, and compliance-sensitive documents.

This portability record is also the part worth publishing when the workflow supports marketing. Google says visibility in AI Overviews and AI Mode still depends on useful, original, crawlable content, with no special AI-only schema required. A public case note that shows the real trigger, sources, approval gate, result, and limitation is more defensible than a generic claim that a company uses agents.

A practical workflow portability record

  • Name the business job, owner, trigger, and finish condition.
  • List every permitted source, tool, write action, and approval boundary.
  • Define typed inputs and outputs independently of the current platform.
  • Preserve prompts, versions, tool calls, source references, errors, and user edits.
  • Keep representative test cases with expected evidence and pass criteria.
  • Document export options, replacement paths, and the manual fallback.

Platforms will keep changing because the category is still young. The goal is not to predict which interface lasts. The goal is to make each important workflow understandable, testable, movable, and safe enough that the business keeps operating when the interface changes.

Sources Read

Next step, if this note maps to a problem on your desk: Discovery Call — a 1-on-1 leverage assessment for your business ($1,500 · 90 min).

Related Field Notes