Your Team Directory Is Becoming a Shadow Org Chart

The useful signal in this week’s agent news is not that another company can make another assistant. The useful signal is that agents are becoming publishable work objects inside organizations.

OpenAI’s current documentation for ChatGPT workspace agents is plain about the shape. A business user can create an agent, connect tools and apps, add custom MCPs, share it with a workspace, publish it to a team directory, put it into Slack, and run it on a schedule. The same page discusses end-user accounts, agent-owned accounts, write-action approvals, version history, and analytics. That is not a toy surface. That is an operating surface.

Anthropic is pushing the same market movement from a different doorway. Claude Cowork is framed for non-technical knowledge work: give it a goal, let it work across local files and applications, and get back a finished deliverable. Their strongest line is the shift: most AI tools are built around the prompt; Cowork is built around the outcome.

That shift matters. A prompt can be private, improvised, and disposable. A published agent is different. The moment it appears in a team directory, runs on a schedule, or acts through a shared account, it stops being an individual productivity trick. It becomes delegated work.

Delegated work needs management.

The team directory is the new org chart shadow

A team directory sounds harmless because the language is familiar. People share templates, automations, dashboards, documents, and workflows all the time. The risk is that an agent directory carries more authority than those older artifacts.

A document can inform. A dashboard can display. A template can standardize. An agent can act.

That action may be small at first. It might summarize feedback, draft a meeting note, clean up a folder, update a tracker, pull source files, or prepare a report. None of that feels dangerous in isolation. But the operational question is not whether the first use case is dramatic. The question is whether the organization can still see what work has been delegated once agents begin spreading.

A shared agent needs a roster entry before it needs applause. The roster does not have to be complicated. It should answer six questions clearly enough that a busy operator can inspect them:

• What job is this agent assigned?
• Who owns the result?
• What systems can it read?
• What systems can it write to?
• When does it run, and what triggers it?
• What evidence proves what it did?

If those questions are not answered, the team directory becomes a shadow org chart. Work is being assigned, but the assignments are not visible in the management system. Authority is being granted, but the authority is not written down in ordinary operational language. The company can feel like it is gaining capacity while quietly losing legibility.

That is how agent sprawl starts. Not with one reckless deployment. With a hundred useful shortcuts that never become managed roles.

Account choice is an authority decision

The most important phrase in OpenAI’s workspace-agent documentation may be the least glamorous one: “agent-owned account.”

That phrase should slow every operator down. It is convenient when an agent can use a shared connection so every user does not have to authenticate during a run. Convenience is not the problem. Hidden authority is the problem.

An end-user account means the agent acts through the person using it. That can preserve useful accountability, but it can also create confusion if the agent’s job is supposed to be shared across a department. An agent-owned account means the agent has its own standing authority. That can be cleaner for repeatable work, but only if the account is treated like a real operational identity with scoped permissions, owner review, and revocation rules.

The wrong version is the half-conscious middle: someone connects a personal account because it works, shares the agent because it is useful, and never revisits the authority model. The agent has now inherited a person’s reach without inheriting that person’s judgment, context, or accountability.

This is why the management decision sits before the technical decision. Before a shared agent gets a credential, the business has to decide what kind of worker it is meant to be. Is it a personal assistant? A team utility? A department function? A scheduled back-office worker? A customer-facing workflow component? Each answer implies a different access model.

The credential should express the role. It should not accidentally define it.

Write actions are where autonomy becomes real

Reading is useful. Writing is commitment.

An agent that reads a folder and drafts a summary can waste time if it is wrong. An agent that sends, edits, posts, deletes, updates, or triggers another system can create consequences. OpenAI’s documentation names this directly: use write approvals carefully for workflows that can send, edit, post, or delete content.

That warning should not be treated as a compliance checkbox. It names the point where autonomy becomes business reality.

A write-action policy does not need to strangle the agent. It needs to separate low-risk motion from consequential commitment. An agent can usually draft without approval. It may be allowed to update an internal scratchpad automatically. It should probably ask before posting publicly, deleting records, changing customer data, sending messages as a human, or triggering financial or legal workflows.

The practical frame is simple: decide what the agent may prepare, what it may propose, what it may commit, and what it must escalate.

That distinction makes the agent more useful, not less. Humans do not want to approve every microscopic action. They also do not want to discover after the fact that a scheduled helper made a consequential change nobody reviewed. The art is putting the review gate at the commitment point.

Approval is not anti-autonomy. Approval is how autonomy earns a larger lane.

Portals solve discovery, not ownership

Cloudflare’s recent MCP architecture post makes the enterprise direction obvious. Their MCP server portals centralize discovery, logging, policy enforcement, and data-loss-prevention controls. Administrators can see who logged into what MCP portal, decide which tools different groups can access, and govern remote MCP servers instead of leaving every user to run local tool bridges on their own machine.

That is the right infrastructure move. Local, unvetted tool bridges are a losing game once agents begin touching corporate systems. Central portals make the tool surface visible. They create a place for authentication, policies, and logs to live.

But discovery is not ownership.

A portal can show which tools are available. It cannot decide which business outcome an agent owns. It cannot know whether the agent’s job is worth doing. It cannot judge whether the schedule matches the rhythm of the team. It cannot decide whether a draft is good enough to send, whether a customer exception deserves escalation, or whether a workflow should exist at all.

That is the operating layer. The portal provides the controlled road system. The business still needs traffic rules, drivers, dispatchers, incident reports, and lane closures.

Palo Alto Networks made the risk side of the same point in its May 12 post on MCP data access: without centralized visibility and governed access controls, security teams are blind to which resources agents are actually accessing. Akeyless sharpened it further in a May 12 survey release: AI agents are not breaking in, they are being invited in with real credentials and broad access.

That sentence is worth keeping. It names the modern agent failure mode. The agent does not need to be malicious to become risky. It only needs legitimate access that no one is governing in real time.

The agent publishing checklist

The management protocol for a publishable agent can be smaller than most teams think. Start with the same discipline used for assigning human work, then add the pieces humans carry implicitly and agents do not.

Before an agent is published to a team directory, added to Slack, or placed on a schedule, write down:

1. Job: the specific work product the agent is responsible for.
2. Owner: the human accountable for the agent’s result and maintenance.
3. Public: who is allowed to use it.
4. Inputs: the files, systems, channels, or data sources it may read.
5. Authority: the actions it may take without approval.
6. Commit gates: the actions that require approval before they happen.
7. Account model: end-user account, service account, or agent-owned account, with a reason.
8. Schedule: when it runs, why that cadence exists, and what should happen if a run fails.
9. Evidence: where logs, outputs, and decisions can be reviewed.
10. Stop rule: the conditions that make the agent pause, escalate, or shut down.

This is not bureaucracy. It is the minimum shape of managed delegation.

The checklist also protects adoption. People trust agents faster when they can see the boundary. Skeptical staff do not need a lecture about transformation. They need to know what the agent can touch, what it cannot touch, when a human reviews it, and who is responsible if the work is wrong.

Clear boundaries create confidence. Confidence creates usage. Usage creates evidence. Evidence tells the business which agents deserve more authority.

Stephen’s operating view

The market is going to keep making agents easier to create and share. That is good. The easier creation gets, the more valuable operating discipline becomes.

The companies that win with agents will not be the ones with the longest directory. They will be the ones whose directory behaves like a managed workforce: every agent has a job, an owner, a scope of authority, a review path, a visible record, and a way to stop.

That is the difference between prompt culture and agent operations.

Prompt culture asks, “Can I make the model do this?” Agent operations asks, “Should this work be delegated, under what authority, with what evidence, and with which human still accountable for the outcome?”

The second question is less exciting. It is also the one that makes agents actually work.

Bottom line

Publishing an agent is not the end of setup. It is the beginning of management.

Once an agent is shared, scheduled, connected to tools, or allowed to write into business systems, it becomes part of the operating structure. Treat it that way. Give it a roster entry. Give it an owner. Bound its authority. Log its work. Review its commitments. Write down when it must stop.

The button is not “more agents.” The button is managed work that survives contact with the business.

Stephen Nickerson.
Built for operators who need agents they can test, trust, and improve.