AI and automation built for people, agents and workflows

The right starting point depends on the work. Copilot is usually the sensible first option for general Microsoft 365 productivity, document support, meeting support, search and summarisation, but only after permissions and data exposure are understood. Automation is usually the better first step when the problem is a repeatable process: intake, approvals, reporting, notifications, handovers, document routing or exception handling.

A custom agent on Microsoft Foundry makes sense when you need a specific data source, tighter containment, a link into a business system, or a workflow Copilot can't handle well. The decision should follow the work, the data and the risk, not the licence.

Start with the users, the work they want to improve and what a useful result would look like. Review SharePoint, Teams and OneDrive permissions, external sharing, sensitive content, labels, data loss prevention and audit visibility for the planned pilot.

Define which users and use cases are in scope, provide practical guidance, agree where human review is needed, and assign support ownership. Review the pilot results and any access or governance issues before expanding.

To test where Copilot is useful with real users and real work, start with Copilot in 30.

Copilot can be safe when Microsoft 365 is properly governed. It operates within the Microsoft 365 service boundary, respects existing permissions and can be supported by audit, compliance and information protection controls.

The practical risk is usually internal oversharing. Copilot may surface files, chats or documents that users already had access to but may not have found manually. That makes permissions, information architecture, external sharing, labelling and audit visibility important before rollout. The tool isn't the whole risk. The surrounding Microsoft 365 governance model is what determines whether the rollout is controlled.

Copilot suits everyday Microsoft 365 work, and Copilot Studio suits agents that business teams can build and maintain. Microsoft Foundry is the right platform when an agent needs a specific model, multi-step logic, integration with business systems, stronger data containment or its own identity and private networking. Many solutions use more than one: a Foundry agent can be published into Teams and Microsoft 365 Copilot, so people use it where they already work.

Yes, where it makes sense. Foundry Local runs models on your own devices or servers for sensitive or offline scenarios, and Foundry agents can run on private networking without public internet exposure. The decision follows the data and the workload.

Automation is usually the better starting point when the work is repeatable and structured. Examples include request intake, approvals, reporting packs, notifications, exception handling, handovers, evidence capture and document routing. These problems usually need a better workflow before they need intelligence.

AI is useful where the work involves interpreting, summarising, classifying, drafting, searching or triaging information. Many good solutions use both, but adding AI to a messy manual process often creates faster output inside a process that still has no structure. The strongest approach is often to fix the workflow first, then add AI where it clearly improves the result.

Power Platform is used to build structured internal applications, workflow automation and reporting improvements inside the Microsoft ecosystem. Power Apps can provide the user interface, Power Automate can handle workflow and integration, Dataverse can provide the data layer, and Power BI can support reporting where required.

The platform is strongest when the process is internal, structured, permission-aware and connected to Microsoft 365 or business systems. It still needs proper engineering: Power Platform environments, DLP policies, data design, testing and someone to support it after go-live. Low-code should not mean unmanaged.

The first use case should be frequent, visible, painful and contained. It should solve a real operational problem without becoming a whole transformation programme. Strong candidates include request intake, approval workflows, reporting packs, document handling, knowledge retrieval, service-desk triage, finance administration and compliance evidence capture.

OT changes the risk profile. In business IT, automation usually affects documents, approvals, reporting, service workflows or Microsoft 365 processes. Near OT, the work can touch production systems and sensitive site data, so we apply tighter access and security controls.

On operational sites, we introduce AI for a specific job, with clear limits. We check each use case for safety, availability, segmentation, logging and vendor support before anything touches a live system.

Often the best first step is simpler: better reporting, workflow or knowledge retrieval around the site.