How X’s New Chat Bots Work for Brands.

X has released an API that lets a business create automated task accounts, bots, that answer people inside X Chat.

Social Media Today reported the launch on 27 August 2026, and X’s developer documentation carries the endpoint that creates one.

In X’s own words, “A bot is a programmatic X account created and belonging to your project. It is a real account with a user ID, an @handle, and a display name, but it has no password and no login.” Its profile carries an “automated by @owner” tag pointing back at the business that owns it.

That is real infrastructure. It is not a customer service product. X shipped the plumbing and left the building to you, which moves this out of the category of things a social team switches on and into the category of things an engineering team scopes.

What X actually shipped

The bots endpoint does one job. It creates a bot account inside your app’s project and hands back a bearer token.

• The handle is 5 to 15 characters, letters, numbers or underscores.
• The bearer token is the only way to act as the bot, because there is no password and no login.
• That token expires, and the response tells you when.
• Repeating the request for a handle you already own returns a freshly minted token and revokes the previous one.
• The default scope set is dm.read, dm.write, tweet.read, users.read and media.write, so reading and writing messages is the centre of it.

Coverage of the launch names bookings, order queries and service updates as the intended jobs. X’s API is billed pay per use against purchased credits rather than a subscription, so the volume your bot handles carries a running cost.

Examples are not a framework

X does not supply a ready-made bot framework. It supplies documentation and code examples showing how an automated account could be assembled, including a skeleton project demonstrating how one might be wired to an AI system.

Everything between “a message arrives” and “the customer got the right answer” is yours to build. Intent handling, the connection to your booking or order system, the memory of a conversation, the handover to a person, the logging, and the token rotation for when that bearer expires.

So the honest description of this feature is a development project with a social media surface. It needs a spec, a budget line and somebody who owns it when it breaks at 9pm on a Saturday.

It also needs a decision most brands have quietly avoided, because a bot has to plug into an inbox, and who actually owns the social inbox is unresolved in a lot of organisations.

X’s rules decide what your bot is allowed to do

Before the engineering question comes the permission question, and X’s developer guidelines are specific about automated accounts.

• They must carry the Automated profile label and state in the bio that they are a bot and who operates them.
• They must link to a human-managed account for accountability.
• Direct messages are allowed only after the user messages you first, with an easy opt-out.
• Opt-out requests must be honoured immediately, with keyword detection for common opt-out phrases.
• Automated welcome messages to new followers are prohibited, even when the person chose to follow you.
• Automated replies are limited to interactions the user started, capped at one reply per interaction.

Then the line most teams will skip. X’s guidelines state that deploying AI-generated replies requires prior approval from X, obtained through its Policy Support form before launch, and that shipping them without approval is a violation even if the content itself is helpful.

If the plan was to point a language model at your messages and see what happens, that plan has a gate in front of it.

What X has not said

Rollout state is the sentence worth being careful about. The endpoint is publicly documented and the launch has been reported, but neither the coverage nor the documentation states an access tier, an allowlist, a beta cohort or a market restriction.

So we do not know how widely this is available, and nobody writing about it does either. Treat availability as something to confirm on your own developer account before you scope any work, not something to assume because a headline said “launched”.

An automated agent inherits rules you have never written down

This is the part that decides whether a bot on X helps or hurts, and it has nothing to do with code.

A person on your inbox improvises. They read the room, hedge, check with a colleague, and go quiet when a message looks like trouble. That judgement is invisible, which is why nobody has ever had to write it down.

A bot cannot improvise. It answers with whatever policy you encoded, at machine speed, in public, under your brand’s name. Every gap in your escalation rules becomes a published answer.

Five questions decide the whole thing, and a team that cannot answer them is not ready to build:

1. What is the bot allowed to state as fact? Price, stock, delivery date, opening hours, availability.
2. What must it never touch? Complaints, safety issues, refunds, anything legal, anything about a named individual.
3. When does it hand over, to whom, and inside what response time?
4. What does it say when it does not know? Silence is an answer, and usually the wrong one.
5. Who signs off a change to what it says, and how is that change reviewed?

Those are approval rules. If you already run a proper one for published content, you are most of the way there. If you do not, our social media approval process template is the shortest route to writing the escalation path down before an automated account starts acting on it.

Where a bot genuinely earns its place

The case for this is narrow and real. Repetitive, factual, high-volume questions with a system of record behind them are exactly what a bot handles better than a person, because a person answering the same question forty times a day answers the fortieth one worst.

Order status. Opening hours. Booking a slot. Where a delivery is. Whether a size is back in stock.

The case against is just as clear. If your inbox is thirty messages a week and a third of them are complaints, an automated account solves nothing and adds a public surface that can be wrong. The volume has to justify the build.

What good looks like

• The bot does one or two jobs properly rather than ten jobs vaguely.
• Handing over to a person is the default when confidence drops, not the exception.
• A named human rota sits behind it during the hours it is live, and it is switched off when nobody is there.
• Its answers are reviewed like published content, because that is what they are.
• The label, the bio disclosure and the opt-out handling are built in from the start, not retrofitted after a warning.
• Every conversation is logged in a form somebody actually reads each week, so you can see what it was asked, what it said and what it escalated.

How NBK thinks about automated support on X

We are a social operations partner, so the first question about any automation is never “can we build it”. It is “what is the system this plugs into”.

An automated account is a process made permanent. It exposes whether response ownership is clear, whether escalation is defined, whether tone is documented, and whether anyone is accountable for what the brand says at 11pm. Teams with that system in place get a useful bot quickly. Teams without it get a faster way to say the wrong thing.

Which is why the work usually starts one step earlier, with the same discipline that makes a good social media approval process work: name the decisions, name the owners, and write down what happens when something falls outside the rules.

Next step

If your social process is slowing down good ideas, or you are weighing up an automated account with no clear answer to what it may say and who takes over when it cannot, NBK can help rebuild the workflow behind the content and the conversations.