Home / AI & GenAI

AI & GenAIHow-toIntermediate

Advisory: adopt an off-the-shelf copilot, extend it, or build your own assistant

Many assistant needs are covered by existing productivity copilots, low-code agent builders or features inside business applications. Compare adopting, extending and building on fit, data access, control, effort and running cost, and build custom only where the use case needs integration, control or behaviour others can't provide.

Deepak Bhardwaj3 min read

Applies toProductivity copilots (e.g. Microsoft 365 Copilot), low-code agent builders (e.g. Copilot Studio), AI features in SaaS applications (ITSM, CRM), and custom assistants on Azure AI Foundry, Bedrock or self-hosted models

Three options

Adopt Extend Build
What Use the copilot/AI feature as shipped Add connectors, plugins, agents or knowledge sources to an existing copilot Custom app on model APIs
Time to value Days–weeks Weeks Months
Control over behaviour Low Medium Full
Data access What the product indexes Your connectors within product limits Anything you integrate
Effort to run Low (licences, governance) Medium High (app, evaluation, ops)
Cost shape Per-user licences Licences + consumption Infrastructure + tokens + team

Questions that decide it

  1. Where do users work? In email/documents/chat → productivity copilot; in an ITSM or CRM tool → that tool's AI features or extensions.
  2. What data must it use? Data already in the productivity suite vs operational systems needing custom integration.
  3. What actions? Read-only answers vs actions in business systems with approvals.
  4. How much control over answers? Regulated advice, strict formats or evaluation gates point toward build.
  5. Scale and user count? Per-user licences vs per-token costs change the economics at different scales.
  6. Skills and ownership? Who will maintain a custom app for years?

Typical outcomes

Use case Often
Drafting, summarising meetings and documents Adopt
HR/IT policy Q&A for employees Extend (knowledge sources in an agent builder) or build if strict control needed
Ticket triage inside the ITSM tool Adopt the tool's AI features or extend; build if workflow is unusual (see the triage transformation post)
On-call assistant using internal runbooks and live telemetry Build or extend with custom connectors (see the ops knowledge assistant post)
Customer-facing assistant Build (brand, control, evaluation, scale)

Governance applies either way

  • Data access: adopted copilots see what users can see. Fix oversharing (permissions, sensitivity labels) before rollout.
  • Risk tiering and approvals per use case (see the responsible AI governance post).
  • Usage and quality monitoring.

Revisit periodically

Products add features quickly. A custom build from last year may now be covered by an extension, and vice versa.

Tip

Before building, prototype the use case in an existing copilot or agent builder for two weeks with real users. Build only for the gaps that prototype shows.

Checklist

  • User location, data and actions documented
  • Control and evaluation needs assessed
  • Cost compared at expected scale
  • Oversharing fixed before adopting copilots
  • Prototype with existing tools first
  • Decision revisited periodically

Related fixes