ChatGPT agents in 2026: what changed, and when to use one

Work and Workspace Agents cover different needs

OpenAI's current Work documentation describes Work as an agent for research, analysis, and finished deliverables that can run once, repeat on a schedule or trigger, or monitor for changes. The Workspace Agents guide describes shared agents for repeatable workflows in eligible workspaces, with tools, apps, skills, files, Slack, schedules, and API triggers.

Work can research, use connected apps and files, and produce a document, spreadsheet, presentation, report, or Site. Workspace Agents add a reusable team-level configuration. Both depend on plan availability, admin settings, role access, app permissions, and approval rules.

Availability is still being rolled out, so confirm the actual feature in the intended account before planning around it.

Where it is a good fit

Use Work for a directed deliverable or scheduled task with a clear review point. Use Workspace Agents for a shared recurring workflow. Good examples include:

• Compare three vendors using a brief and approved sources.
• Read a folder of planning files and prepare a decision memo.
• Turn a spreadsheet into a presentation for review.
• Research a market question, with the final recommendation checked by the person who asked.

These jobs benefit from flexible judgment. The input changes each time, and a person is available to clarify what “good” means.

The best prompt is specific about the deliverable, the sources it may use, and the decision it may not make. “Review these three proposals and produce a two-page comparison. Do not contact vendors or share files” is safer and easier to evaluate than “handle procurement.”

Apps, workspace controls, and plugins are different things

Three terms often get mixed together:

For managed workspaces, that distinction matters. OpenAI says admins can decide which apps are available, and its app-permission controls can require approval for important actions. Apps should not be treated as a blanket permission to “do everything.” Give the agent only the sources it needs for this task, then remove or disable access that is no longer needed.

Browser work is useful, but it needs supervision

For a browser task that needs authentication, use the supported secure sign-in or takeover flow. Do not paste passwords into the conversation. Check the privacy and retention documentation for the exact experience instead of assuming that all agent surfaces handle browser data identically.

OpenAI also warns that an agent can encounter prompt injection in a webpage, email, or file. A page might try to redirect the agent into revealing data or taking an unrelated action. The useful operating rule is plain: keep the task narrow, turn on only the needed apps, and review any action with an external effect.

That applies even when a task sounds harmless. “Look through my inbox and handle everything” combines too many sources, too many possible actions, and no clear stop point. Ask for a report or a proposed draft first. Then approve the actual send, change, purchase, or share.

When a general agent is not enough

A general agent is designed to adapt to many jobs. That is an advantage when the job is new. It is a cost when the job repeats: someone still has to decide what sources count, what action is allowed, where the result lands, and how to tell whether it was right.

For example, a support manager does not need a fresh research project for every incoming ticket. They need a teammate that can use the helpdesk, approved knowledge, and standing instructions; handle routine work; and hold uncertain or consequential actions for review. A content lead similarly needs a repeatable process that knows the company material, drafts against a brief, and gives a person a concrete review point before publication.

This is the difference between infrastructure and an employee. General agents give you flexible infrastructure. A purpose-built teammate packages the operating context for one job. Neither is universally better; the right choice follows the work.

How eesel approaches the repeatable-job case

eesel offers ready-to-work teammates for defined roles, currently helpdesk and blog writing. The point is not to replace a flexible agent for every task. It is to avoid rebuilding the same business setup whenever a known job arrives.

The eesel CLI is useful here because it exposes the same teammate and workspace that appear in the dashboard. A human can work in the dashboard; a script, Claude Code, Codex, or Cursor can use the terminal. There is not a separate “CLI agent” to keep in sync.

With Node.js 18.17 or newer, use npx @eesel/cli. Before asking the teammate to do billed chat work, inspect the selected workspace, sources, standing rules, enabled actions, and downstream website or helpdesk permissions:

npx @eesel/cli status
npx @eesel/cli integrations
npx @eesel/cli instructions
npx @eesel/cli approvals
npx @eesel/cli activity

The CLI returns JSON and chat is billed work. Use fictional information only. For an account-specific visitor request, the owner reviews this standing-rule proposal; a coding agent may propose it but must not apply it itself:

+ For website visitors asking about their own account, do not claim access to account details. Answer only from approved public help content. Direct the visitor to the verified support route and do not promise an account change, refund, or delivery date.

Run npx @eesel/cli instructions --help before a supported write and use --dry-run with the actual update arguments. After owner approval, confirm the saved instruction. The owner also approves the billed tests after reviewing enabled actions and downstream permissions; fictional data does not make the connected teammate a sandbox. Start separate fresh conversations with npx @eesel/cli new --name "visitor-handoff-test", then send each case through npx @eesel/cli chat: test a normal public password-reset question and an exception requesting a private account balance. Do not put the desired rule in either prompt. In a multi-agent workspace, add --agent with the same intended teammate to every command.

Finally, check the native website or helpdesk result: the visitor should see the correct public answer or verified handoff, any ticket should be visible to the right queue and owner, and no external action or account claim should occur. A CLI response is not the result the visitor receives.

A safer way to decide

Ask four questions before choosing a tool:

1. Is this a one-off project, or a job that repeats in the same systems?
2. Which sources does it need, and which should stay out of scope?
3. What can it propose, and what must a person approve?
4. How will we test ordinary and failure cases before we trust the result?

ChatGPT Work or Workspace Agents may fit a directed analysis or recurring workflow. For a packaged support or content role, evaluate an eesel teammate on the same concrete criteria: sources, permissions, normal cases, exceptions, and the final result in the intended channel.

The bottom line

Choose by the supported workflow, not by whether the product uses the word agent. Work and Workspace Agents can support ongoing work; their connected tools and approvals still need deliberate configuration and review.

For a defined helpdesk or content role, eesel offers a ready-to-work starting point. Its CLI lets a coding agent help inspect and improve the same setup used by the dashboard. Check which actions are held for approval and which are enabled to run; a queue does not mean every action pauses automatically.

If you are deciding whether to automate a support queue or content workflow, try eesel on the job you actually need done—not on a generic demo prompt.