Part 1: Decide What to Build

"Can I share it?" sounds simple.

It is not. There are at least five different things people mean when they ask that question.

This is the real difference between productivity tooling and internal product building.

A prompt helps a person repeat a thought process. A skill helps a team reuse a method. An agent helps colleagues invoke a capability. An app helps an organisation run a process.

Those are different jobs.

Microsoft's advantage is distribution.

If your company already lives in Teams, Outlook, SharePoint, Word, Excel and PowerPoint, Microsoft is not just selling an AI model. It is selling an AI layer over the existing work graph.

That matters. With Copilot Studio, agents can be published to channels such as Teams, Microsoft 365 Copilot, SharePoint, websites, mobile apps and Azure Bot Service channels. Microsoft's publishing lifecycle also makes the enterprise route explicit: test the agent, publish it, configure channels, make it available in Teams or Microsoft 365 Copilot, then roll out more broadly after testing.1

For internal use, authentication is the important bit. Microsoft describes no authentication, Microsoft authentication and manual authentication options for Copilot Studio. It also warns that no authentication means anyone with the link can chat with the agent, while Microsoft authentication uses Entra ID and unlocks Teams and Microsoft 365 channels.2 The practical takeaway is straightforward: anonymous access is for public-style scenarios; internal and user-specific agents need identity and permissions aligned to the organisation.

It also creates the first big trade-off.

A Teams bot is not a case-management system. A Copilot response is not a review queue. A chat transcript is not a proper audit trail. A published agent is not automatically a product.

That does not make Copilot Studio weak. It means it has a centre of gravity. Its centre of gravity is governed productivity inside the Microsoft estate.

Claude feels different.

Microsoft is strongest when the work graph is the product. Claude is more interesting when the work tips into craft: reasoning, writing, analysis, coding, reusable expertise and agentic work that still sits close to files and code.

The important piece here is Claude Skills. A Skill is a reusable capability package built around a SKILL.md file. It can include instructions, supporting files, scripts and resources, and Claude loads it when relevant instead of forcing you to paste the same procedure into chat every time.3

The sharing model is also more developer-friendly than many productivity tools. Claude Code skills can live at enterprise, personal, project or plugin scope. Project skills can sit in the repo. Plugin skills can be namespaced and distributed through plugin structures. Claude Code settings also have user, project, local and managed scopes, which matters when a team wants repeatable behaviour without giving up organisational control.34

That is less like "publish a bot to the company app store" and more like "package this expertise so it can be reused across projects, teams and codebases".

For AI solutions engineers, that matters. A consultancy method can become a Skill. A delivery checklist can become a reusable instruction pack. A document transformation workflow can become a versioned capability. A coding standard can become part of the project context.

But once you build a serious custom agent, you are back in software-engineering land: persistence, scaling, observability, authentication, secrets, concurrency, cost and multi-tenant isolation. Claude can help you build the thing. It does not remove the need to own the thing.

The market is not just Copilot versus Claude.

OpenAI has moved further into programmable agent workflows, with documentation that treats agents as applications with orchestration, tools, state, guardrails, human review, observability and evaluation loops.5 Gemini belongs in the broader comparison when the organisation is Google-heavy. Then there is the practical middle layer: tools like Retool and Streamlit.

Retool is useful when the thing should feel like an internal app quickly. It has real concepts for apps, resources, workflows, agents, RBAC and permission groups that control access to objects across the organisation.6 That makes it sensible when chat is too loose but a fully bespoke React app is too much.

Streamlit is useful when the fastest route to value is a Python-first app: analyst workbenches, evaluation dashboards, RAG prototypes, model comparison tools and internal demos that need to become usable quickly. Streamlit supports user authentication with OpenID Connect providers such as Google, Microsoft Entra ID, Okta and Auth0, but its documentation is clear that OIDC provides authentication, not authorisation.7

That last point is the giveaway. The moment you say "authorisation is something we need to design", you are no longer just playing with a productivity tool. You are building a product boundary.

Here is the practical test I would use.

The clearest warning sign is when people start building process around the agent: a spreadsheet to track requests, a Teams channel to chase approvals, a manual checklist to validate outputs, a folder full of prompt versions, or one person who knows how it all works only because they built it.

That is usually the moment to ask whether the agent has become the wrong container for the work.