As of June 30, 2026, the practical question around ChatGPT workspace agents is no longer just whether a team can make a repeatable agent. The sharper question is what happens when that agent can reach internal tools.

OpenAI's workspace agents documentation describes agents that can work with apps, tools, files, skills and schedules. It also says write actions for apps and connectors are set to ask during an agent run by default. OpenAI's apps in ChatGPT documentation separates permission options such as asking before app use, asking before changes and allowing actions without a prompt.

That is the choice small teams need to make before the pilot feels normal: should this agent only gather and draft, or should it also change records, send messages, post updates or create tickets?

If the team cannot answer that clearly, keep the first agent read-oriented.

Start with the internal tool job

Do not start with the agent template. Start with the internal tool job.

Write one sentence:

"This agent is allowed to use this tool to do this job."

Good first jobs sound narrow:

  • collect status from a project tracker;
  • draft a weekly customer-risk note from approved records;
  • prepare a meeting brief from a known folder and calendar;
  • summarize tickets that match one queue;
  • find the current owner of a process.

Riskier first jobs sound open-ended:

  • update customer records;
  • post to a team channel;
  • file tickets automatically;
  • send external email;
  • change access, plans, billing or account settings.

The difference is not whether the agent is useful. The difference is whether a mistake stays inside a reviewable draft or becomes a system change.

Split read, draft and write actions

Treat every connected tool as three possible permissions, not one.

Read means the agent can fetch or search information. Draft means it can prepare a message, update, ticket, document or checklist without submitting it. Write means it can change something outside the chat.

Those should not have the same approval rule.

For a first pilot, a sensible pattern is:

| Tool behavior | First-pilot default | Why it matters | | --- | --- | --- | | Read a scoped source | Allowed for test users | The agent needs evidence to be useful. | | Draft a response or update | Allowed, with source trail | Drafts save time but remain reviewable. | | Post, send, edit or delete | Ask every time | The action changes the shared system. | | Change permissions or money | Keep out of scope | The blast radius is too high for a first run. |

OpenAI's admin controls documentation points admins toward app availability, permissions and action controls. Use those controls before the agent is shared, not after the first awkward run.

Test the approval moment, not only the answer

Most pilot tests check whether the agent gives a decent answer. That is not enough when internal tools are involved.

Test the moment right before an action happens:

  • Does the agent show what it is about to change?
  • Does it identify the target system, record or channel?
  • Does the approver understand the source behind the action?
  • Can the user edit the draft before approving?
  • Does the agent stop when the source is missing or conflicting?

If the approval prompt is vague, the control is weak. A user should not approve "update this" without seeing what "this" is, where it goes and which source supports it.

The approval step should feel boring. It should be clear enough that a busy operator can say yes, edit or stop.

Keep custom MCP apps on a shorter leash

OpenAI's developer mode and MCP apps documentation says OpenAI-built apps are search-only today, while custom MCP apps are the route for write or modify capabilities. That makes custom apps powerful, but also easier to over-trust.

Before connecting a custom internal app to a shared agent, answer four questions:

  • Which objects can it read?
  • Which objects can it change?
  • Which fields are hidden from the agent?
  • Which actions need human approval every time?

If the internal system has messy permissions, old records or weak audit logs, do not give the agent broad tool access first. Use a narrower search or fetch pilot, then add write actions only after the answer path is reliable.

For company-knowledge style work, the earlier AI office-search source map is still the right first step. For actions, the extra step is approval design.

Make the first agent boring on purpose

A boring first agent might:

  • read a known project board;
  • draft a weekly update;
  • cite the records it used;
  • flag missing information;
  • ask before posting anywhere;
  • leave a visible run history.

That is less exciting than an agent that "runs operations." It is also much easier to trust.

The goal is not to prove that an agent can touch every internal tool. The goal is to prove that one repeated workflow becomes faster without making the team nervous about silent changes.

If that works, expand one boundary at a time:

  • more users;
  • one more source;
  • one more draft type;
  • one low-risk write action with approval;
  • a scheduled run after the review process is stable.

Do not expand all five at once.

The approval checklist

Before publishing a workspace agent that can use internal tools, check:

  • The agent has one named job.
  • Each connected tool has a read, draft or write role.
  • Write actions ask before sending, editing, posting or deleting.
  • High-risk actions stay out of scope.
  • Test users include one person who should see the source and one who should not.
  • The approval prompt shows the target, change and source trail.
  • Someone owns the agent after launch.

If those answers are not written down, the agent is not ready for broad use.

Small teams do not need a perfect governance program to test workspace agents. They do need a clear line between "help me prepare the work" and "change the system for me." Keep that line visible until the workflow earns more trust.