An Agent With the Password Is Not a Publishing Stack

This week, Q4 and 2027 stack reviews are filling with the same live demo. A ChatGPT agent, a Gemini computer-use session, or a Copilot Studio flow logs into Instagram, Facebook, or TikTok, drafts a caption, and clicks Publish. The room applauds. The scorecard has a line for writing quality. The deal is being framed as a seat license that can replace Hootsuite, Sprout, or an agency retainer.

That demo is not a publishing architecture. It is a remote employee with a browser. If you fund it because the caption sounded good, you are buying unbounded UI control and calling it operations.

The axis everyone is scoring is the wrong one

The bake-off conversation is stuck on generation. Can it write in brand voice? Can it localize a caption? Can it remix a reel description faster than a coordinator? Those are real questions. They are also the questions a vendor wants you to ask, because they are visible in fifteen minutes.

They do not survive the week after credentials land in production.

An agent with a session cookie can do anything the native app allows: change a password, alter two-factor settings, reply in DMs, delete a post, charge the wrong payment method, accept a brand partnership, or publish a claim a licensed trade is not allowed to make. Caption quality does not constrain that surface. The session does not know which actions are licensed, which assets are original, or who authorized the adaptation. It only knows how to operate the interface.

That is the difference between an operating layer and a session. An operating layer accepts a bounded job, records the decision, and publishes through a scoped credential. A session inherits the owner's full UI. One of those is a stack. The other is a login with a model attached.

We already argued, in X Opened Its Algorithm. Can Your Stack Explain Reach?, that inspectable ranking does not help you if your workflow only stores the final caption and the impression count. This week's demos fail a prior test. If the agent generated the copy, clicked Publish, and left no record of who authorized which original asset was adapted, you cannot explain reach because you cannot explain the post.

Origin labels do not forgive a live login

Platforms are tightening origin labels, reuse rules, and meaningful-contribution tests at the same time vendors are selling generate-and-post from a live dashboard. X's original-content rules, Meta's labeling requirements, and TikTok's authenticity checks all ask versions of the same operational questions:

• Who created the media?
• Was this an authorized adaptation or a scraped asset?
• What changed between the original and the channel version?
• Can the publisher prove why this went out today?

A pipeline that invents a caption inside a logged-in browser will fail those checks in two ways. First, it cannot produce a chain of custody. The model saw a prompt, not a first-party source event. Second, when it fails, blast radius is the entire account. The same cookie that posted a caption can alter settings, harvest DMs, or keep publishing after you think you revoked access.

Offboarding is the tell. If the vendor's answer to "we are leaving" is "change the Instagram password," you never had a publishing stack. You had a shared login. Password rotation is not credential revocation. It is an incident.

The test that survives the demo

Do not score the fifteen-minute publish. Score whether publish can happen without handing the vendor, or the model, the keys. Put these on the RFP before September planning freezes the budget for a year.

1. Intake is push, not scrape. The owner sends original photos, video, or voice intent into a dedicated channel. The system does not wander the native app looking for something to post. If intake requires the agent to browse Stories, download a competitor's reel, or operate Meta Business Suite as the owner, stop the evaluation.

2. Authorization is explicit and attributable. Every outbound item names who approved it, which source asset it was adapted from, and which claim was allowed. "The agent decided it sounded on-brand" is not authorization. If you cannot reconstruct that record 90 days later, you cannot answer a platform takedown, a licensing complaint, or a customer who says the photo was of someone else's job.

3. Credentials are scoped and revocable. OAuth tokens with limited publish scopes beat stored passwords. App passwords beat owner passwords. A kill switch that invalidates the token without rotating the human's login is table stakes. Ask to see the revocation path in the vendor's own environment, not in a slide.

4. The model cannot operate the native app. Computer-use against Instagram, Facebook, or TikTok is the anti-pattern, even when the caption is excellent. If the product requires a session cookie, a saved password, or an unattended browser profile, it is unbounded UI control. Treat that as a disqualifier, not a feature.

5. Blast radius is named in writing. What can this integration read? DMs? Payment methods? Follower export? Password-reset email? Two-factor codes? If the answer is "whatever the logged-in user can see," you have not bought a publishing API. You have bought a remote pair of hands.

Capture quality is not the scarce system. We made that point when The Pixel 11 Solves the Wrong Content Problem moved the bottleneck from the camera to the operating layer. Generation quality is the same trap in a different costume. Better captions do not create governance. They increase the rate at which an ungoverned session can ship.

What to do this week

If you are in a bake-off, change the scorecard before the next demo. Ask the vendor to publish without a password, without a session cookie, and without the model driving the native UI. Ask them to show the authorization record for a single post: source asset, adapter, approver, destination, timestamp. Ask them to revoke access while you watch, then confirm the owner's login still works and the vendor's path is dead.

If they cannot do those three things, you are not evaluating a stack. You are evaluating a browser with a model attached.

Constrained, owner-pushed intake is the control plane we actually run: original media and intent enter a dedicated channel, adaptation is attributable, and distribution uses scoped publishing credentials rather than a live dashboard login. That is an operating layer. Browser takeover is not.

Take the five questions above into the next bake-off. If a vendor cannot answer them in the product, not in the pitch, do not fund the session.