+44 (0)1482 770583
hello@systechitsolutions.co.uk
AI Agents & Agentic Apps on Microsoft Foundry
Agents that act inside your CRM, ticketing, finance and SharePoint, built on Microsoft Foundry with a written job, their own identity, and a person approving anything that matters.
The job first, then the agent
In short: We design and build AI agents on Microsoft Foundry Agent Service that take actions in the systems you already run, such as CRM, ticketing, finance and SharePoint. Every build starts with the job: what the agent does, what it may read, and what it must never touch. Actions with real consequences wait for a person to approve them. Right for organisations of 15 to 250 staff with one repeated task that crosses systems.
Copilot answers questions. An agent does things: it raises the ticket, updates the customer record, drafts the credit note. That is where the time is saved, and it is also where a mistake stops being a wrong answer and becomes a wrong action.
Who this is for
The problem
Agents have become easy to start and harder to run well. As more teams experiment, a common pattern appears: a promising prototype with broad access, no named owner and no record of what it did. That is fine in a demo. It feels very different the first time the agent touches a live customer record or an invoice. None of this is unusual. It is what happens when a new capability arrives faster than the controls around it.
What we would do
Start with one job, written down: the task, the systems it reads, the actions it may take, the ones that need a person's approval, and the things it must never touch. If that fits on a page, an agent on Microsoft Foundry is usually the right build. If it does not, the job is not ready yet, and that is worth knowing before anyone writes code.
- If a Microsoft 365 Copilot licence already does the task inside Outlook, Teams or SharePoint, buy the licence rather than building an agent.
- If the AI only needs to answer questions from your own documents and never act, our AI engineering service is the better fit.
- If you do not yet know what AI is already in use across the organisation, start with our AI assessment.
When we are not the answer: If there is no clear job yet and the brief is to 'do something with agents', we are the wrong first call. We will happily talk it through, but we would rather help you find the task than build an agent looking for one.
Before anything is built we write the agent's job down. What it does, step by step. What it reads, and under whose permissions. What it may change, which of those changes wait for a person to approve, and what it must never touch at all. That one page becomes the design, the test plan and the thing your board can read.
More on how we deliver our AI agents service
We then build on Microsoft Foundry Agent Service, Microsoft's managed platform for building, deploying and scaling agents, connecting your systems through tools and MCP servers. Each agent runs under a Microsoft Entra agent identity, is traced and tested before release, and is published where your people already work: Teams and Microsoft 365 Copilot.
Systech is founder-led by Ryan Mangan, a Microsoft MVP for Azure Virtual Desktop and Windows 365, a Chartered Fellow of the BCS (FBCS) and author of Packt's two-edition Mastering Azure Virtual Desktop.
If agents or AI services are already running and nobody holds a list of them, our AI assessment and shadow AI audit finds and classifies them first.
Where the job is answering questions from your own data rather than acting on it, see our AI engineering service.
Everything you need, managed for you
What is an AI agent, compared with Copilot?
An agent is AI with a job and the tools to do it. Copilot is very good at answering, summarising and drafting inside Microsoft 365. An agent goes further: it can look something up in your CRM, raise a ticket, update a record or prepare a finance entry, as part of a task you have defined.
That difference is why the design matters more. An answer can be read and ignored. An action changes something in a live system, so it needs a narrower scope, a clear owner and, for anything consequential, a person in the loop.
What does an agent's job description cover?
Five things, written before any build starts:
- The task, as the steps a person would follow today
- What it reads: which systems, which records, and under whose permissions
- What it may change on its own, such as adding a note to a ticket
- What waits for approval, such as sending a customer email, issuing a credit or deleting anything
- What it must never touch, such as payroll, bank details or another client's records
The never-touch list is the part people skip, and it is the most useful. It becomes a hard boundary in the design and a set of test cases the agent must refuse before it is released.
How do agents connect to CRM, ticketing and finance systems?
Through tools. Microsoft Foundry offers built-in tools such as web search, file search and code interpreter, and lets you add custom tools through functions, OpenAPI specifications and MCP servers. Toolboxes put a set of tools behind one managed MCP-compatible endpoint.
Why we give each agent the narrowest tool set that does the job
Most line-of-business systems already have an API, and an MCP server or OpenAPI tool turns that API into a small set of named actions the agent can call. We expose only the actions the job needs. An agent that updates ticket status does not get a tool that can close every ticket in the queue.
Foundry supports remote MCP servers with key-based authentication, Microsoft Entra authentication using the agent or project identity, and OAuth identity passthrough, where the agent acts with the signed-in user's own permissions. Which one is right depends on whether the agent should act as itself or as the person asking, and we decide that per tool.
How do you keep a person in control of what an agent does?
By designing approval into the workflow rather than trusting the model to ask. Any action on the approval list pauses and goes to a named person with the context they need to decide, and nothing happens until they say yes.
Alongside approvals, we build in:
- Least-privilege access, so the agent can only reach the records the job needs
- Hard limits on volume and value, so a loop cannot send a thousand emails or approve a large refund
- A full trace of what the agent read, decided and did, for every run
- A named owner and a review date for every agent in production
Foundry's content filters are designed to help mitigate prompt injection, including cross-prompt injection from documents and emails the agent reads. Agent-specific guardrails in Foundry were still in preview when we wrote this, so we do not rely on them alone.
What identity does an agent use?
A Microsoft Entra agent identity. Microsoft Foundry provisions and manages agent identities automatically. Agents still in development in a project share one identity, and publishing an agent gives it its own dedicated agent identity.
What you can see in Entra, and what needs a Microsoft Agent 365 licence
Agent identities appear in the Microsoft Entra admin center under Agent ID, alongside Copilot Studio agents and others, so you have one inventory of the agents in your tenant, with owners, sponsors and expiry. Agent ID itself is available to all Microsoft Entra customers.
Extending Entra security features such as Conditional Access and identity protection to agents requires Microsoft Agent 365. Microsoft includes Agent 365 with Microsoft 365 E7 and offers it as an add-on to Microsoft 365 E5, A5 and Business Premium. We tell you which controls your current licences cover before the design depends on any of them.
Can agents work with other agents, or other platforms?
Yes, through the Agent2Agent (A2A) protocol. Foundry supports A2A for agent-to-agent communication, and A2A v1.0 is generally available. That lets a Foundry agent call another agent, including one built on a different platform, as a tool.
We use it sparingly. Two small agents with clear jobs are easier to test and govern than one large agent that does everything, but every extra hop is another place to trace and another boundary to secure.
How is an agent tested before it goes live?
With a written test set, run before release and after every change:
- Real tasks from the job description, with the expected actions
- Cases where the right behaviour is to stop and ask for approval
- Never-touch cases the agent must refuse
- Adversarial inputs, such as an email that tries to give the agent new instructions
Foundry's tracing, evaluations and red teaming are generally available, and we use them to show the agent passes rather than assert it. Tracing integrates with Application Insights, so the record of each run sits alongside the rest of your Azure monitoring.
Where do people use the agent?
Where they already work. Publishing agents to Microsoft 365 Copilot and Teams is generally available in Foundry, so staff reach the agent from a chat they already have open rather than another portal to remember.
Some agents need no chat at all. They run when a ticket arrives or a record changes, and only surface when something needs a person's approval.
What happens after go-live?
An agent is a running system, not a finished project. Each one keeps a named owner, a review date and a trace of every run, and we watch for the things that drift: a connected system that changes its API, a model update that changes behaviour, a job that has quietly grown.
Foundry's monitoring features were in preview when we wrote this, so we pair them with Application Insights and alerting you already understand. We can run that for you, or hand over a documented agent your own team can operate.
When is an agent the wrong answer?
More often than the market suggests:
- A single Microsoft 365 Copilot licence already does the task
- There is no clear, repeated job, only a wish to use agents
- The task happens a few times a month and a checklist would do
- The data the agent would need is not in a state anyone could act on safely
In each case we will say so, and point you at the cheaper route.
| Question | Microsoft 365 Copilot | Custom AI (RAG) | AI agent on Foundry |
|---|---|---|---|
| What it does | Answers, summarises and drafts | Answers from your own data | Takes actions in your systems |
| Where the data lives | Your Microsoft 365 tenant | Documents and databases you connect | CRM, ticketing, finance, SharePoint and other systems through tools |
| Main risk | Oversharing through permissions | A confident wrong answer | A wrong action in a live system |
| Key control | Permissions and sensitivity labels | Grounding, citations and refusal | A written job, least privilege and human approval |
| Best fit | Everyday document and meeting work | Questions over data Copilot cannot reach | A repeated task that crosses systems |
Questions we hear a lot
Is Microsoft Foundry Agent Service generally available?
The core agent service is. Microsoft lists agents, toolboxes, tracing, evaluations, red teaming and publishing to Teams and Microsoft 365 Copilot as generally available. Some features, including memory, monitoring and agent guardrails, were still in preview when we wrote this. We design around what is generally available and tell you where a preview feature is involved.
Will the agent act with its own permissions or the user's?
It depends on the job, and we decide it per tool. Some actions should run as the agent's own identity with tightly limited access. Others should run as the person asking, using OAuth identity passthrough, so the agent can never reach more than they could. The job description makes the choice explicit.
Can we use Conditional Access on our agents?
Agent identities appear in Microsoft Entra, but extending Entra security features such as Conditional Access to agents requires Microsoft Agent 365. That is included with Microsoft 365 E7 and available as an add-on to E5, A5 and Business Premium. We check your licences first and design the controls around what you have.
What stops an agent being tricked by an email or document it reads?
Several layers, because none is enough alone. The agent only has the tools its job needs, consequential actions wait for a person, volume and value limits cap the damage, and Foundry's content filters help mitigate prompt injection. The test set includes adversarial inputs, so we see how the agent behaves before your customers do.
Do we need Microsoft 365 Copilot licences for staff to use the agent?
Not necessarily. Agents can be published to Teams as well as Microsoft 365 Copilot, and some agents run in the background with no chat at all. Licensing depends on how the agent is published and used, so we confirm it against your tenant before the design is fixed.
How long does a first agent take?
We scope it after the job description is written, because the variable is usually the systems the agent has to reach, not the AI. A narrow first agent with one or two tools and a clear approval step is the fastest route to something live, and it shows what the second one will really cost.
Our AI agents service is delivered UK-wide from our office in Brough, East Yorkshire, with on-site support across the county where it helps. We work with businesses in Scarborough, Bradford, Hull, Leeds, York and Sheffield and 6 more Yorkshire towns and cities, and remotely with clients right across the UK.
Talk through the job for your agent
A short call about the task, the systems it would touch and what it must never do. We will tell you plainly whether an agent is the right build and how we would keep it under control.
Technology partners
Best-of-breed technology we use to deliver our AI agents service.
See all technology partners