OpenAI Agent Builder (AgentKit): add Twitter (X) data with MCP, then move to the Agents SDK

Yes, for now. OpenAI's deprecations page has an entry dated June 3, 2026: "we notified developers using Agent Builder that the product is being deprecated. ChatKit remains available." The same notice appears at the top of the Agent Builder guide and the node reference, adding that "existing users can continue using it during the transition window." The Evals platform and reusable prompts were deprecated on the same day, which matters if your workflow used Evaluate or a saved prompt.

What "AgentKit" means now. The @OpenAIDevs launch post listed four parts: ChatKit ("embeddable, customizable chat UI"), Agent Builder ("WYSIWYG workflow creator"), Guardrails ("safety screening for inputs/outputs") and Evals. With Agent Builder going, the parts that remain are ChatKit (the embeddable chat UI), the Agents SDK in Python and TypeScript, guardrails, and the Responses API's hosted MCP tool, which is the piece that actually connects to outside data.

Existing ChatKit embeds. The ChatKit guide says a ChatKit app backed by an Agent Builder workflow can keep using that hosted workflow during the transition window, and tells new apps, or anyone migrating before the shutdown, to use the advanced integration with their own server-side agent. OpenAI's pages do not say whether a published workflow ID keeps answering after November 30, so plan as if it does not.

Should you start a new workflow on the canvas? Only as a sketch. The canvas is still a fast way to lay out a multi-agent flow and test it in Preview with live data, and the export gives you working SDK code. Treat the canvas as a design tool with a deadline and the exported code as the product.

OpenAI describes a workflow as "a combination of agents, tools, and control-flow logic." You insert nodes, connect them, and each connection "becomes a typed edge": click a node to see its inputs and outputs and check that the next node receives the properties it expects. Publishing creates a versioned snapshot with a workflow ID; deploying means passing that ID to ChatKit or clicking Code to download Agents SDK code.

Typed outputs are the point. An Agent node can return structured output, and the If/else node reads it with Common Expression Language (CEL). That is how a classifier agent's intent field decides which agent runs next, without the model choosing the route on its own.

Preview and Evaluate. Preview runs the workflow interactively, with file attachments, and shows each node's execution. Evaluate runs trace graders over saved traces, but it sits on the Evals platform, which becomes read-only on October 31, 2026 and shuts down with Agent Builder.

Yes for MCP. The node reference says the MCP node can "connect with OpenAI connectors or third-party servers, or add your own server." There is no generic HTTP-request node in the reference: to reach an outside API from the canvas, that API has to be wrapped as an MCP server. This is also the difference from Custom GPTs, whose Actions took an OpenAPI schema and are being retired with GPTs on December 11, 2026; Agent Builder never used Actions.

Under the canvas, the MCP tool is the Responses API's mcp tool type, and the exported code uses the same fields. Knowing them makes the Agent Builder form and the SDK code read the same way:

Authentication. The server's own initialize response says: "Auth: paste your twitterapi.io API key as the Bearer token." A tool call without a token returns HTTP 401 with a WWW-Authenticate: Bearer header that points at mcp.twitterapi.io/.well-known/oauth-protected-resource, so OAuth-capable clients (ChatGPT developer mode, for instance) can sign in instead. For Agent Builder and the Responses API, the key in the authorization field is the simple path. OpenAI's MCP guide notes the Responses API "does not store the value you provide in the authorization field," which is why the exported code sends it on every request.

Approvals. OpenAI's safety guide for Agent Builder says to keep tool approvals on for MCP tools, "including reads and writes," and to use the Human approval node. All 12 TwitterAPI.io tools are read-only (each carries readOnlyHint: true), so the risk is the data the model sends out in a query, not an action on an account. A reasonable setup is no per-call approval on reads and a Human approval node before anything leaves the workflow, such as a digest sent to a team channel.

Run these checks before pasting the URL into any client. They show the handshake, the 401 that tells a client how to authenticate, and an authenticated call:

We listed the server's tools with the Agents SDK's own MCP client (openai-agents 0.24.0 with mcp 2.3.0, the versions pip installed this session). The listing needs no key; calling a tool does. Each tool maps to a TwitterAPI.io REST endpoint and returns the same JSON.

Allow only what the workflow needs. Every tool definition in the list is sent to the model on each turn. A monitoring agent needs get_user_last_tweets and search_tweets; a research agent adds get_tweet_replies and maybe get_tweet_quotes. Set those in allowed_tools (or the tool picker on the canvas) and leave the rest out.

The script below is the listing we ran, with its output pasted as comments. The schema at the end is what the model reads for search_tweets, trimmed only where marked. The description fields do the prompting for you: the model learns the search operators and the Latest versus Top choice from them, which is why short agent instructions work.

The workflow in the diagram above takes one request, such as "what did @OpenAIDevs post this week" or "what are developers saying about the Agents SDK," decides whether it is monitoring or research, runs the right agent with the X tools, and stops for approval before anything is shared. The settings below follow OpenAI's node reference; menu wording on the canvas may differ slightly.

1. Start. Keep the default chat input, which exposes input_as_text. Add a state variable such as accounts (a list of handles) if the workflow always watches the same accounts.

2. Guardrails (optional). Put a Guardrails node after Start with jailbreak and PII checks. Whatever the user types becomes part of an X search query, so this is the earliest point to stop junk.

3. Classify agent. Instructions: "Decide whether the user wants new posts from accounts or a topic (monitor) or an analysis of a discussion (research). Extract the accounts and the topic." Set structured output with fields intent (monitor or research), accounts and topic. No tools on this agent.

4. If / else. One condition in CEL on the classifier's intent field equal to "monitor"; the else branch goes to research. Pick the variable from the node's input picker rather than typing the path, since that is where the typed edge shows the exact name.

5. Monitor agent + MCP. Add the MCP tool with the URL and key from the previous section and allow get_user_last_tweets and search_tweets. Instructions: summarize what is new in at most eight points with each post's URL, and say so when a tool returns nothing. The URL instruction matters: it lets a reader check every claim.

6. Research agent + MCP. Same server, allow search_tweets and get_tweet_replies. Instructions: search with queryType Top, read replies under the two most-engaged posts, report the main arguments and the like and view counts seen. Ask it to name organizations only, never private individuals.

7. Transform (optional). If a later node only needs a list of URLs and counts, reshape the agent output here so the next agent does not reread the whole tool output.

8. Human approval, then End. Approval before anything leaves the workflow. Then test in Preview with two requests, one per branch, and watch which tool each agent calls and what it costs.

What one run costs. Each tool call returns at most about 20 posts per page. A monitoring run that reads two accounts and one search page returns up to about 60 posts, or $0.009 at $0.15 per 1,000; the same 60 post reads at $0.005 each on X's pay-per-usage card cost $0.30. OpenAI model usage is billed separately by OpenAI.

OpenAI's migration guide has two paths. Agents SDK: open the workflow, select Code, choose Agents SDK, pick TypeScript or Python and copy the export into your app. ChatGPT Workspace Agents: for Business, Enterprise or Edu workspaces, paste the export into a new workspace agent and let the builder convert it. The guide is blunt that "this process does not convert your workflow graph or guarantee that every behavior transfers unchanged," and that workflows with strong determinism may not migrate faithfully to a workspace agent.

The code below is the X workflow written directly for the Agents SDK. HostedMCPTool keeps the connection on OpenAI's side, exactly like the canvas did; the tool_config dict "mirrors the JSON you would send to the REST API," per the SDK docs. We did not run this agent with an OpenAI key for this page; the MCP side was checked separately (the tool listing below and the unauthenticated 401 probe above).

If you need the model to stay deterministic about routing, replace the triage agent with ordinary code: call the classifier, read its structured output, and run the monitor or research agent yourself. That is the closest match to the If/else node.

Option B: connect from your own process. HostedMCPTool only works with OpenAI models that support the Responses API's hosted MCP integration, and the calls happen on OpenAI's servers, so your code never sees them. If you want to log each tool call, filter tools with a callback, or run the same agent on another model, use MCPServerStreamableHttp instead. The SDK docs recommend sending credentials in an Authorization header rather than the URL, as the listing script in the tools section above does.

Which one to pick. Use the hosted tool when you are moving an Agent Builder workflow and want the same behavior. Use the local client when you need control or observability. Both reach the same 12 tools at the same prices. For more on trimming raw tool output in your own process, see our Agents SDK guide: in its study a raw 20-post page was about 33,709 tokens and a trimmed function-tool result about 3,010.

To see how builders treated Agent Builder from launch to deprecation, we pulled the top-ranked X posts for ("agent builder" OR agentkit) openai (reposts excluded) for every month from October 2025 to October 2026: 440 posts, up to 40 a month. Top-ranked means X's engagement ranking, so this is a sample of the most visible posts, not a count of all posts.

The launch was the peak. October 2025's top posts drew 16,906 likes in total, and 11,226 of those were the @OpenAIDevs post "Introducing AgentKit" (2,999,227 views). No later month came close; October 2026's top posts drew 607, 96.4% less than the launch month.

OpenAI's own accounts went quiet. Searching @OpenAIDevs and @OpenAI for "agent builder" or "agentkit" returned 6 and 1 posts. All are from October 2025 except one year-in-review post in January 2026; we found 0 posts from either account using those words after January 2026, including none around the June deprecation. Developers learned about the shutdown from the docs and email, not X, which helps explain why many still ask whether Agent Builder exists.

The recent stream is small and international. The latest 200 matching posts span 111.4 days, about 1.8 a day. 62% are in English, followed by Chinese and Japanese.

We tagged each post by keywords in its text (the patterns are in analyze.py) and compared the 267 top posts from launch through May 2026 with the 173 from June 2026 on.

MCP is a constant. About one top post in seven or eight mentions MCP in both periods (13.9% and 12.7%). Connecting outside tools was part of the Agent Builder conversation from the start, and it is the part that survives the shutdown, because the same MCP server works in the Agents SDK, ChatGPT and other clients.

Migration talk nearly doubled, from a low base. Posts about the shutdown or migrating rose from 4.9% to 8.7%, and "workspace agents" went from almost nothing (0.4%) to 4.6%. Comparisons with n8n, Zapier and Make held at about one post in eight in both periods (11.6% and 12.1%).

What this sample cannot show. Keyword tags miss posts that discuss a theme in other words or in other languages, and a top-ranked sample overweights popular accounts. Read the shares as direction, not as precise rates.

How we collected this. The paragraphs below describe the method, sample, cost and limits of the study behind both charts.

Question. How did X attention on Agent Builder / AgentKit change from launch to the scheduled shutdown, and what did builders discuss alongside it?

Queries. ("agent builder" OR agentkit) openai -filter:retweets through /twitter/tweet/advanced_search: two pages with queryType=Top per calendar month from October 2025 to October 2026, plus ten pages with queryType=Latest. Official accounts: from:OpenAIDevs (agentkit OR "agent builder") and the same for from:OpenAI.

Sample. 659 posts returned across 41 requests, collected in 2026: 440 unique top-ranked posts in monthly buckets, 200 latest posts, and 7 posts from the two OpenAI accounts. One December request came back empty and was repeated.

Cost. 659 tweets at $0.15 per 1,000 is about $0.10 for the whole study. The same reads at $0.005 per post read on X's pay-per-usage card would cost about $3.30.

What it cannot show. Total post volume (Top pages are ranked, not exhaustive), anything in private groups or other networks, or why engagement fell. Theme shares rely on English keywords.

Privacy. Aggregates only. Only organization accounts (@OpenAIDevs, @OpenAI) are named or quoted. Raw search pages were not kept; the published sample has no IDs, URLs, text or handles.

The MCP tools bill exactly like the REST endpoints behind them. Tweet tools (search_tweets, get_user_last_tweets, get_user_mentions, replies, quotes, tweets by ID) cost 15 credits per tweet returned, $0.15 per 1,000 tweets, with a minimum of 15 credits per request, so a search that finds nothing costs $0.00015 and a full 20-post page costs $0.003. Profiles cost $0.18 per 1,000; follower and following lists cost 1 to 3 credits per user returned.

The X figures are from the rate card at docs.x.com/x-api/getting-started/pricing, read this session; X also gives $20 in credits on a first saved card and purchase, and matches a first auto-recharge up to $50. Per 1,000 posts that is $5 against $0.15, about 33x.

Scheduled monitoring. Agent Builder has no scheduler; a monitor runs when someone sends a message. If you move to code and poll, a check that finds nothing costs $0.00015, so checking one query every 60 seconds for a month (43,200 checks) costs $6.48 if nothing ever matches, and every 5 minutes about $1.30.

Getting a key. New accounts that pass the automatic bot check get up to $1 of free credits (at most 100,000 credits, no card, one per person or network, expiring after 31 days). Purchased credits never expire; $1 = 100,000 credits. Before the first payment the limit is 0.2 requests per second, enough for testing a workflow in Preview; after a payment it is 20. Subscriptions start at Starter $29 a month; see the pricing page. No X developer account is needed for reads.