The Agent Is the Easy Bit: What Needs to Be in Place Before You Connect AI to Your Business?

AI agents are becoming surprisingly easy to build.

With tools such as Microsoft Copilot Studio, Azure AI and modern development frameworks, it is now possible to create an agent that can understand a request, reason about what to do next, search for information, call APIs and perform actions.

The technology is moving incredibly quickly.

But in a real business, the agent is often the easy bit. The surrounding business architecture is where the real work is.

Before an AI agent can safely do anything genuinely useful, it needs reliable access to the right data, appropriate permissions, secure authentication, well-defined integrations and clear rules around what it is — and is not — allowed to do.

It also needs to operate within the reality of an existing organisation.

That might mean SQL Server, Dataverse, SharePoint, Microsoft 365, Power Platform, bespoke applications, third-party platforms and legacy systems that have evolved over many years.

This is why successful AI agent projects are rarely just AI projects.

They are usually data, integration, security and software architecture projects with AI sitting on top.

Getting those foundations right is often the difference between an impressive demonstration and an AI agent that can genuinely be trusted in production.

Moving Beyond the Chatbot

For many organisations, the first experience of generative AI was conversational.

Ask a question.

Get an answer.

Generate some content.

Summarise a document.

That remains useful, but an AI agent can potentially go much further.

An agent might be able to:

• find information across company systems;

• identify a customer or client;

• retrieve their recent activity;

• analyse documents;

• update a CRM record;

• create a task;

• prepare a report;

• call an internal API;

• trigger a workflow;

• recommend a next action;

• or perform that action itself.

That is a significant change.

The moment AI moves from answering questions to performing actions, architecture becomes much more important.

An incorrect answer from a chatbot may be inconvenient.

An agent incorrectly updating a customer record, sending a communication, approving something or triggering a business process can have considerably greater consequences.

The question therefore stops being simply:

“Can the AI do this?”

It becomes:

“Under what circumstances should we allow the AI to do this?”

Start With the Data

Most useful business agents depend on company data.

That sounds obvious, but it immediately raises some difficult questions.

Where is the information?

Is it in Dataverse?

SQL Server?

SharePoint?

A line-of-business application?

Several systems?

Is the information current?

Is there a reliable way of identifying the same customer, employee or transaction across those systems?

Which system is the authoritative source?

Can the data be accessed through an API?

And perhaps most importantly: can you trust it?

Giving an AI agent access to disorganised or inconsistent information does not magically make that information better.

In some cases it simply allows the organisation to access bad data more efficiently.

Before introducing an agent, it can therefore be valuable to improve the underlying data architecture first.

That might involve creating better APIs, consolidating information, introducing clearer data models, improving master data or establishing which system owns which information.

AI tends to expose these architectural weaknesses very quickly.

Identity and Permissions Matter

An agent should not automatically have access to everything simply because it is technically capable of accessing it.

The same security principles that apply to normal business applications should apply to AI.

If an employee asks an agent about a customer, should the agent be allowed to retrieve every document associated with that customer?

Should everybody be able to see salary information?

Commercial information?

Board documents?

Personal data?

Financial records?

If a user cannot normally access something, using an AI agent should not become a way of bypassing that restriction.

This means understanding identity and permissions properly.

In a Microsoft environment, that may involve Microsoft Entra ID, Dataverse security roles, SharePoint permissions, application identities, API permissions and the security models of individual systems.

An agent also needs its own identity when communicating with other services.

Those permissions should normally be limited to what the agent genuinely needs.

Giving an agent unrestricted administrator access because it makes the initial integration easier is not a sensible production architecture.

Give the Agent Tools, Not Unlimited Access

One of the most important architectural decisions is how an agent interacts with business systems.

There is a significant difference between giving an AI model unrestricted access to a database and giving it a carefully designed tool that performs a specific operation.

Consider an agent working with customer information.

Rather than allowing it to construct arbitrary database commands, the system might expose controlled capabilities such as:

GetCustomer

GetRecentInteractions

CreateFollowUpTask

UpdateCustomerAddress

RequestDocument

Each capability can then have its own validation, security rules and audit trail.

The agent can decide which tool it needs to use, while traditional software remains responsible for making sure that tool behaves safely.

This combination can be extremely powerful.

AI handles the interpretation and reasoning.

Normal software handles deterministic business rules.

That separation is important.

Not every decision needs AI.

In fact, wherever a rule can be expressed reliably in normal software, it is often better to keep it there.

Your Existing APIs Become Increasingly Valuable

Businesses that already have well-designed APIs are often in a much stronger position to introduce AI agents.

An API effectively provides a controlled contract between the agent and the underlying system.

The agent does not necessarily need to understand how an application works internally.

It simply needs an approved way of asking it to do something.

That could be:

“Find this client.”

“Retrieve their portfolio.”

“Create an activity.”

“Calculate this figure.”

“Generate a quotation.”

“Schedule a review.”

This is one reason we believe traditional software engineering becomes more important rather than less important as AI develops.

AI may change how users interact with systems, but those systems still need secure and reliable ways of exposing their capabilities.

Modern approaches such as the Model Context Protocol (MCP) are making it easier for AI systems to discover and work with tools.

But the underlying principle remains familiar.

A well-designed interface between systems is valuable.

Business Rules Still Belong Somewhere

Businesses often contain years of accumulated knowledge in their software.

A customer may only be eligible for a particular product under certain circumstances.

A transaction above a certain value may require approval.

A workflow may behave differently depending on the client's status.

A calculation may depend on several pieces of information.

These rules should not simply disappear into an AI prompt.

Where rules are important, repeatable and deterministic, they should generally remain within normal application logic.

The agent can decide that a calculation needs to be performed.

A trusted service should perform the calculation.

The agent can decide that a workflow should be initiated.

The workflow should still enforce the organisation's normal rules.

AI is excellent at dealing with ambiguity.

Software is excellent at enforcing certainty.

Good agent architecture uses both.

Decide Where Humans Remain in Control

One of the biggest design questions is how much autonomy an agent should have.

There is no single answer.

The appropriate level depends on the action being performed.

An agent that summarises internal information might need very little human intervention.

An agent preparing a draft email may simply require the employee to review it before sending.

An agent proposing changes to a client record might require confirmation.

An agent initiating a significant financial transaction should probably have considerably stronger controls.

A useful way to think about this is as a progression:

Inform → Recommend → Prepare → Approve → Act

The agent might initially only provide information.

Later it could recommend an action.

Then it could prepare that action for a human to approve.

Only when the organisation has sufficient confidence in the process might the agent be allowed to act autonomously.

AI adoption does not need to jump directly from chatbot to autonomous business process.

Gradual autonomy can be a much more sensible route.

What Happens When the Agent Gets It Wrong?

This is one of the most important questions in any production AI system.

Not:

“Will it ever make a mistake?”

But:

“What happens when it does?”

A production architecture should assume that errors will occasionally occur.

That means thinking about auditability.

What did the user ask?

What information did the agent retrieve?

Which tools did it call?

What actions did it perform?

What changed as a result?

Can those actions be reversed?

Can somebody investigate what happened?

Traditional business systems have spent decades developing concepts such as logging, transaction histories, permissions, approval workflows and audit trails.

AI systems need the same level of operational thinking.

An agent should not become an invisible layer performing actions across an organisation without leaving a clear record of what happened.

Monitoring Matters Too

An AI agent is not something that should simply be deployed and forgotten.

Its behaviour needs to be monitored.

Are people using it?

What are they asking?

Which questions does it struggle with?

Which tools is it calling?

Where does it fail?

Are there recurring requests that suggest a missing integration?

Is it producing useful outcomes?

Is it creating unnecessary work?

The answers can help improve both the agent and the wider business systems surrounding it.

Interestingly, AI agents may also highlight weaknesses in existing processes.

If an agent repeatedly struggles to find the correct information, perhaps employees struggle too.

If three systems need to be searched before a simple customer question can be answered, perhaps the real problem is the architecture rather than the agent.

AI can become a useful lens through which to examine the organisation itself.

Not Everything Needs an Agent

There is understandably a great deal of enthusiasm around AI agents.

But not every business process needs one.

If a process is completely predictable, a conventional workflow may be faster, cheaper and safer.

If something always happens when a record changes, Power Automate may be the correct answer.

If a complex calculation needs to be performed reliably, a .NET service may be appropriate.

If users simply need better reporting, Power BI may solve the problem.

Agents become particularly interesting when the task involves ambiguity.

Understanding what someone is asking.

Gathering information from several places.

Choosing between different tools.

Interpreting documents.

Applying context.

Recommending what should happen next.

The objective should not be to insert AI into every process.

It should be to use AI where it adds something that traditional software struggles to provide.

The Best Agent Architecture Is Usually Hybrid

In practice, a useful business agent will often sit across several technologies.

Imagine an employee asking:

“Can you prepare everything we need for Sarah's annual client review?”

Behind that relatively simple question, quite a lot might happen.

The agent may identify the correct client in Dataverse.

A .NET API might retrieve information from a specialist business application.

Documents might come from SharePoint.

Financial information might sit in SQL Server.

A Power Automate flow might create internal tasks.

The agent may summarise recent correspondence and identify missing information.

A reporting platform might provide additional analysis.

Finally, the employee receives a concise summary and a list of proposed actions.

To the user, it feels like one intelligent assistant.

Behind the scenes, it is an architecture.

And that architecture is what makes the agent useful.

Before You Build an Agent, Ask These Questions

Before connecting an AI agent to your organisation, it is worth asking:

• What business problem are we actually trying to solve?

• Where does the agent need to obtain its information?

• Can we trust that information?

• Which systems does it need to interact with?

• Do those systems have suitable APIs or integration points?

• How will users and the agent authenticate?

• What should each user be allowed to see?

• Which actions can the agent perform?

• Which actions require human approval?

• Which business rules must remain deterministic?

• How will actions be logged and audited?

• What happens when something goes wrong?

• How will we monitor whether the agent is actually creating value?

Those questions are considerably less exciting than asking which AI model to use.

But they are often much more important.

AI Agents Make Good Architecture More Valuable

There is an interesting consequence to the rapid development of AI.

As agents become easier to build, the quality of the systems surrounding them becomes increasingly important.

A business with structured data, modern APIs, well-defined permissions, sensible integration patterns and clear business processes can experiment with AI relatively quickly.

A business with fragmented systems, inconsistent data and unclear ownership may discover that the agent itself is the least of its problems.

That does not mean everything needs to be modernised before an organisation can start experimenting with AI.

It does mean the experiment should help identify the architecture that will eventually be required.

Start small.

Give the agent access to a clearly defined set of information.

Introduce a small number of useful tools.

Keep humans involved in important decisions.

Monitor what happens.

Then expand its capabilities as confidence grows.

The Agent Really Is the Easy Bit

Creating an impressive AI demonstration has never been easier.

Creating an AI capability that employees can rely on every day is a different challenge.

That requires much of the same thinking that has always gone into good business technology:

data architecture;

security;

identity;

permissions;

integration;

APIs;

business rules;

monitoring;

governance;

and good software engineering.

AI does not remove the need for those disciplines.

It makes them more important.

The organisations that gain the most from AI agents are unlikely to be those that simply deploy the largest number of them.

They will be the organisations that connect AI intelligently to the data, software and processes that already make their business work.

The agent may be the exciting part.

But the architecture around it is what turns it into a business system.

How Irvine-David Can Help

At Irvine-David, we help businesses look beyond the AI demonstration and consider the wider technology required to make AI genuinely useful.

That can include reviewing existing applications and data, designing APIs and integrations, working with Microsoft Power Platform and Dataverse, integrating SQL Server and SharePoint, developing bespoke .NET services, implementing AI agents and establishing the security and governance required around them.

Because our work spans software development, Microsoft technologies, data platforms, AI and technology strategy, we can look at the agent as part of the wider business architecture rather than as a standalone tool.

If you are considering introducing AI agents into your business, a useful first step is not necessarily deciding which agent platform to use.

It is understanding what you want the agent to do — and whether the systems around it are ready to let it do it safely.