Building one AI agent is no longer difficult. Turning many of them into a single system the whole business can rely on is where projects stall. These are the six decisions we made at the start that took our own platform from prototype to everyday use in weeks.
Most organisations now have several AI agents, built by different people at different times, each doing its own thing well. Building one is no longer difficult: point it at a real system, give it a clear job, and you have something to show for it within a week.
But the next step can be tricky: turning a lot of capable individual agents into a single system the whole business can depend on. That is where the real value is, and also where projects stall. Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, due to cost, unclear value and weak controls, not because of model quality.
It doesn’t have to be a long road. We built a platform for our own team on Microsoft’s stack and went from first prototype capability to something the whole business uses in weeks. This platform reads our sales pipeline, our project and timesheet data, our Jira board, our website analytics and our contracts, and it can send an email, post to Slack, create a deal or raise an issue. Our team reaches it five ways (a web app, Teams, Copilot, Slack and Claude) and every capability works the same in all of them.
We didn’t succeed because the agents were clever. We succeeded because we made the decisions below right at the start, rather than discovering them later.
1. Handling the question nobody designed for
An individual agent answers the question it was built for, and answers it well. A system has to handle the ones nobody anticipated. The demo question is always simple: what’s the status of this ticket? The questions people actually ask are not. “How are sales and marketing doing this quarter” needs the CRM, the website analytics, the project data and the delivery board, pulled together into one answer. “Give me a PDF of our top three deals and email it to me” is three jobs in a strict order. The next question is something nobody anticipated.
Configured automation handles the first kind well, because you can draw the process in advance. It struggles with the rest, because you’re drawing every route the conversation might take before anyone has taken one.
Our platform works the other way round. It reads the request and decides which capabilities are needed, then runs them together or in sequence as the question requires. Nobody drew that route beforehand. We describe the same router-and-specialists idea, applied to a client’s data, in Building an AI layer across an enterprise: what we learned building one.
The technical bit that matters. Capabilities live in a registry, not in a fixed diagram. Adding one is a registry entry and a module. The existing routes don’t get redrawn, and nothing else needs retesting. That’s why the platform has grown a capability at a time instead of in releases.
2. Meeting people where they already work
A prototype lives wherever it was built, and its users are whoever was in the room. A system has to reach everyone, which means going to them. Every organisation has a good internal tool nobody opens. Adoption happens when you’re where the work already happens. For some of our team that’s Teams, for others it’s Slack, for developers it’s the tools they’re already writing code in, and for anyone doing something deliberate it’s a proper web app with a usage view and an audit trail.
The temptation is to pick one channel and do it well. The cost shows up later, when the second channel arrives and gets a partial version of the same thing: a second set of permissions, a second set of answers, two things to maintain, and no confidence they agree.
We treated the channel as a thin front door onto one system instead. Same capabilities, same permissions, same answers, whichever door you came through.
The technical bit that matters. One workflow sits behind all five entrances, with identity carried through Entra in every case, including from outside the Microsoft estate. Adding a channel is contained work, not a rebuild, which is what makes reaching people where they are affordable.
3. Graded access, rather than all or nothing
A prototype trusts everyone who can reach it, because everyone who can reach it built it. The moment the whole business is using it, that stops being true, and this is where most agent projects get stuck between two bad options. Lock it down until it’s safe and nobody uses it, because the answer to every useful question is a request form. Leave it open and you’re one unexpected action away from switching the whole thing off.
Gartner puts it more bluntly than we would: it expects 40% of enterprises to demote or decommission autonomous agents by 2027 over governance gaps discovered only after something goes wrong, and it names all-or-nothing governance as the root cause.
Our answer is graded. A default set of capabilities is open to the whole team: reading the pipeline, checking a project, looking at traffic, searching our own proposals. Those are needed constantly, and gating them just recreates the queue we were trying to remove. The sensitive ones are granted rather than assumed: administering access itself, triggering runs, and anything a particular role shouldn’t reach.
The technical bit that matters. Permissions are enforced where the work is routed, not in the interface. A capability a role doesn’t hold is unreachable, rather than hidden from a menu, so it holds the same way in Teams, in Slack and from a developer’s own tooling.
4. Proving what it will do before it does it
Answering a question gets judged on whether it’s right. Sending the email gets judged on something else entirely: the conversation switches from “is it clever” to “what is it about to do”. That hesitation is correct, and no amount of accuracy fixes it.
So anything with a consequence can be previewed. Ask for a dry run and you’re told exactly what would happen (who would be emailed, what would be posted, which record would be created or changed) and nothing is sent.
Confidence doesn’t come from the model being good. It comes from being able to see what it’s about to do before it does it.
The technical bit that matters. The preview is enforced in the code that performs the action, not handed to the AI as an instruction to behave. A model asked to pretend it isn’t sending an email is a hope, not a control. The distinction is small to build and the whole basis of trusting the thing.
5. Knowing what each request costs
Nobody asks what a prototype costs. Everybody asks what a system costs, usually a finance director, usually two months in, and the honest answer at that point is often a shrug and a cloud bill. Runaway cost is one of the three reasons Gartner gives for agent projects being cancelled. It’s not always an obvious failure, but it becomes something that stops being defensible.
Every request on our platform is priced in real pounds, from the current rates, broken down by capability and by channel. That makes the value conversation concrete: this capability costs us about this much a month and saves roughly this. It also settles arguments about which agent to improve next.
The technical bit that matters. Detailed tracing comes with the framework rather than being built. Every step of every request is recorded, and the usage and cost views read from that. Nobody had to instrument anything by hand, which is the only reason the numbers are still accurate months later.
6. Work that happens without anyone asking
A prototype waits to be asked. Ours doesn’t. The work gets done whether or not anyone is at a keyboard, which is the biggest time saver when it’s Monday morning and that summary used to be someone’s first hour of the week.
Personal prompt libraries and individual skills don’t get you there. They live with one person, run when that person runs them, and leave when that person does. Nothing about them is managed, and nobody else can depend on them.
On our platform, an automation is defined once, owned centrally and put on a schedule. It runs against the same capabilities, the same permissions and the same cost tracking as anything a person asks for directly. Anyone can create one and see whether it ran. Firing a run on demand is restricted, because writing a job and executing it aren’t the same thing.
The technical bit that matters. Scheduled work goes through the same routing and permission checks as a live request, so an automation can never reach something its owner couldn’t. Every run is recorded with its own cost, which means one that quietly becomes expensive shows up long before the invoice does.
Where this sits on Microsoft’s own ladder
None of this is a case against configuring agents in a portal. That is where our own capabilities started, and where most should. Microsoft offers three ways to build: configure an agent, design a workflow visually, or write the orchestration yourself and let Foundry run it. Its own guidance is that most organisations end up with a mix, and the step up the ladder is a deliberate decision rather than a graduation everyone has to make.
Configure it when the agent answers questions in one domain, the process is predictable, volume is high and complexity is low, and a business team should own it without waiting on engineering. HR policy questions, IT helpdesk triage, a knowledge assistant over SharePoint. That’s the majority of interaction volume in most organisations, and there’s no prize for making it harder.
Build it when routing depends on the question, when the agent takes actions with consequences, when it has to work identically across several channels under one set of permissions, or when you need to know what each request costs.
You don’t have to get this decision right on day one. Start in the portal. If it outgrows that, the identity model, the AI models, the tracing and the infrastructure all come with you. Our own platform is built on Microsoft Agent Framework, with every capability still a genuine Foundry agent underneath.
What makes it enterprise-grade
Not the models, and not the number of capabilities. Four things: it reaches people where they already work, permissions are graded rather than all-or-nothing, anything irreversible can be previewed first, and someone can answer what it costs. Each of those is straightforward to design in at the start of the step-up, and expensive to retrofit once a dozen agents are already live.
If you want to see this pattern running, take a look at InsytesAgents, our agent workflow app built on Microsoft Foundry and the Agent Framework. And if you’re planning an AI platform on Azure, or you have a pilot that works and no clear route to production, we’re happy to talk it through.
