Picture a familiar failure: the report arrives in three versions.
Every Friday, an operations coordinator pulls the weekly metrics from two spreadsheets, pastes them into a slide, and sends it to the leadership team. When she's out, the sales analyst does it differently: he exports a file, reformats the numbers, and attaches it as a document. When he's out, the marketing manager does it differently still. By the time anyone noticed all three versions existed, months of data had been formatted three different ways. Nobody could say which one the vice president had been reading.
That specific failure – a recurring task rebuilt from memory every time a different person touches it – is the kind of workflow where a shared agent can actually help.
What Changed, in Plain Language
OpenAI now says workspace agents have moved from experiment to standard product in ChatGPT Business, Enterprise, and Edu. [1] A workspace agent is a shared assistant the team builds once for a recurring workflow. Instead of one person maintaining a private ChatGPT conversation they forget to hand off, the agent lives in a shared space, can run on a schedule, and gives the team one workflow to review and improve.
OpenAI says teams create agents by describing a workflow in plain language, not by writing code. [1] The agent can work inside ChatGPT or inside Slack. [1] OpenAI gives example workflows: weekly metrics reporting, lead follow-up drafting, request triage, and close preparation. [1] Reuters independently confirmed the broader ChatGPT Work launch, noting that it was designed for people who don't write code. [3]
That phrase, "designed for people who don't write code," deserves a pause. It sets an expectation that a manager can build and share a useful agent without starting a custom engineering project. That's plausible in narrow cases. The question is what "narrow" actually means for your team.
What a Bounded First Agent Looks Like
The instinct, once a tool becomes available, is to imagine the largest possible use. Resist that instinct for the first pilot. A first agent should be so bounded that if it breaks, the consequence is a minor inconvenience, not a customer problem.
Pick one recurring workflow: something the team does weekly or monthly, where the output stays internal, where no single run's failure causes real damage, and where the current process is genuinely inconsistent. The weekly expense report review is a reasonable example. The agent pulls submissions, flags anything over a threshold for human review, and delivers a summary to the manager each Monday morning. Meeting-note triage works too: after every standup, the agent reads the transcript and drafts a short set of action items for the team channel. A lead-scoring review is another candidate, if the criteria are already defined and the output stays internal before anyone acts on it.
The second requirement: name a specific owner. An agent without a named owner drifts. The owner is the person who configured the workflow description, understands what the agent is supposed to produce, and is responsible for reviewing whether it actually does. That person is not the information technology department. The department may help with setup, but the owner runs the workflow today.
The third requirement: agree on a single acceptance rule before the first run. What does a good output look like? If the agent summarizes expense submissions, the acceptance rule might be: every submission over a set threshold appears in the summary with the submitter name and category. If it doesn't, the summary is wrong. Write that rule down before the agent runs once. Without it, the first-month review has no standard to measure against.
The Controls to Request Before Sharing
Availability is not permission. Before the agent touches anything outside a read-only internal document, ask your admin to enable approval gates on outward actions. [1] OpenAI says ChatGPT Work lets users approve important actions before the agent carries them out. [2] Sensitive actions, including sending email, editing shared spreadsheets, and adding calendar events, can require a human to confirm before the action completes. [1]
Request that those gates be on by default for the pilot, not as an option.
OpenAI says Enterprise and Edu admins can control which tools and actions the agent can access, and who on the team can build or share agents. [1] Analytics show counts for completed runs and people using the agent. The Compliance API gives admins visibility into configuration changes, updates, and runs, and admins can suspend an agent. [1]
Ask your admin to lock tool access to only what the specific workflow requires. An expense-review agent does not need calendar access. A meeting-note agent does not need access to the customer database. Granting broad access because it might be useful later is how agents accumulate permissions no one can fully account for.
What Stays Manual
A shared agent running on a schedule creates a specific risk: the team stops noticing that a task is happening. Automation becomes invisible, and invisible processes stop receiving judgment.
Several things must stay manual regardless of what the agent drafts. Any communication going to a customer, client, or partner requires a human to read and approve it before it leaves the building. Any decision with meaningful financial or legal consequence requires a human who owns that consequence. Any action that, if wrong, would take more than a day to correct stays manual until the team has a long track record of the agent's accuracy.
The agent drafts. A person decides. That division has to hold.
If the team finds itself approving the agent's outputs without reading them, the approval gate has become a rubber stamp. That's the moment to pause the pilot, not congratulate it.
The First-Month Review
Schedule a review before the agent runs a single time. Put it on the calendar for a month out. Then show up to it.
The review has a specific agenda. Look at the actual runs: how many ran, how many met the acceptance rule, and what the failures were. Read the rejected outputs. If the agent produced something the owner could not accept, understand why. Was it missing data? Did the workflow description need to change? Did the acceptance rule turn out to be wrong?
Ask whether the named owner actually reviewed each output or delegated review to someone who didn't understand the acceptance criteria. Ask whether the approval gates fired, and if so, whether anyone declined an action or approved everything automatically.
Then make a decision: expand the agent to another workflow, modify the current one, or pause. That decision belongs to the manager, made with evidence from actual runs, not from assumptions made during setup.
An unreviewed shared agent does not stay still. The team builds routines around it. Processes upstream change and the agent's workflow description doesn't keep pace. People stop knowing which outputs it generated and which a human produced. Dependency forms quietly, and by the time anyone asks whether the agent is still accurate, the answer may have been no for weeks.
The operating decision is this: name one recurring workflow, name an owner, ask your admin to enable the agent with approval gates on any outward action, write down the single acceptance rule before the first run, and put the first-month review on the calendar now.
Everything else can wait for that review.