The Best AI in Your Company Will Not Have a Screen

You integrate AI with your existing business systems by deciding where it sits relative to them. There are three positions: beside the system, on top of the system, or behind it. That one decision drives your cost, your adoption rate, and whether anyone is still using the thing in six months. It matters more than which model you picked.

The decision often gets made by default. A tool is purchased, it arrives with its own screen, and the position is settled before anyone has weighed it.

The scale of the problem is documented. Salesforce's MuleSoft benchmark, an annual survey of 1,050 IT leaders, found that the average enterprise now runs 957 applications and has integrated only 27 percent of them.¹ Salesforce sells integration software, so weigh the source accordingly. The direction of the finding is not seriously in dispute, and the mid-market version is harder, because the integration budget is smaller and the systems have been in the building longer.

Where should AI sit relative to the systems you already run?

Three positions are available, and each one supports a different outcome.

Beside the system. The AI lives in its own window. Your team works in the system of record, switches to a chat interface, asks a question, and carries the answer back by hand. This is the cheapest to buy and the fastest to demo. It also asks a person to perform the integration themselves, with their own attention, every single time. Adoption fades quietly here, because one day they stop bothering.

On top of the system. The AI gets its own interface layered over the system of record, and your team is asked to work there instead. This can be genuinely excellent. It is also a retraining project competing against a screen your people already know cold, and it inherits every change management problem that implies.

Behind the system. The AI reads from and writes to the system of record, and the person's screen barely changes. The work simply appears where the work was always going to appear. This costs the most to build, and in my experience it is the one that survives contact with a real workday.

Ask whose screen has to change. That one question predicts more about an AI deployment than the model behind it.

What does it look like when AI runs behind the system?

It looks like nothing, which is the point: the work arrives in the system your team already uses, and no one is asked to go somewhere new to collect it.

Start with the pressure. In the convenience store industry, average store employee turnover typically tops 100 percent a year.² At that rate, recruiting stops being a project with an end date and becomes a permanent load on the business. Friction removed from it does not save you once. It saves you continuously, for as long as you operate.

Proxigee Services, a Pittsburgh advisory firm that helps small and midsize companies put AI into the systems they already run, worked with a regional convenience store operator with more than 70 stores that had exactly this problem. Recruiters were spending their days on scheduling mechanics instead of on candidates.

They ran UKG. UKG stayed the system of record, and it stayed the interface employees used. Nothing about that changed, and nothing about it needed to.

What changed sat behind it. Agents were triggered by activity inside UKG. When a candidate reached a defined point in the process, an agent took a narrow, well-specified task, scheduling an interview, and completed it. The output went back into UKG and onto the recruiter's calendar. The recruiter was never asked to open a new tool, learn a new screen, or check a second queue to find out what had happened.

Recruiters who had been running 10 to 15 interviews a week moved to 55 to 80.

That reads like a productivity gain, and in this particular market it does something more valuable than that. A candidate for an hourly retail role is applying across many postings at once, and the employer who puts a confirmed time and date on that person's calendar first is very often the employer who gets the interview at all. Every hour between an application and a locked appointment is an hour another operator can use. Scheduling speed is the competitive act here, and treating it as administrative overhead is how good candidates end up somewhere else.

The agent committed the booking itself. No recruiter confirmed each one. What kept that inside the lines was the narrowness of what it was permitted to do at all. The agent had three tasks: schedule, reschedule, cancel. Any other topic a candidate raised went to the recruiter's email, untouched.

That constraint is the part worth copying. Those three actions form a closed loop. Every failure the agent can produce is a failure the agent can also repair, since the remedy for a bad booking is a reschedule or a cancellation and both were already on its list. The company was not wagering that the agent would be right every time. It was wagering that being wrong was cheap and recoverable, which is a far smaller bet and a much easier one to govern.

Autonomy is safe to grant when the inverse of the action sits inside the agent's own scope.

The pattern is not limited to companies our size. Deloitte's 2026 technology research describes Toyota using agents to deliver information out of legacy mainframe systems so that people no longer work across 50 to 100 mainframe screens to assemble it.³ Different scale, different decade of technology, same move. Leave the system of record where it is and change what reaches the person in front of it.

Why not just use the AI built into the software you already pay for?

Because your software vendor is building for its entire customer base at once, and the part of this that creates value for you is the part that does not generalize.

Give the vendors their due first. Gartner projects that 40 percent of enterprise applications will feature task-specific AI agents by 2026, up from less than 5 percent in 2025.⁴ Your platform vendors are not asleep on this. They are racing, and some of what they ship will be good and will cost you nothing extra.

Now look at what they are racing toward. A workforce platform can reasonably build a candidate-facing chatbot that answers common questions, because roughly every customer wants roughly that. What it cannot build for you is your delegation of authority. Which requisitions are open to this. How far into the process a candidate has to be. Whose calendar, and which slots inside it. What makes a booking legitimate at your company rather than at the median company on the vendor's customer list.

Those rules are the value. They are also precisely the part that has to be different for every customer, which is why a product built to serve all of them lands on the average of them.

So the vendor's built-in AI takes some of the annoyance out of scheduling. My rough characterization, from watching this happen, is that it gets maybe 40 percent of it, and it leaves behind the part that actually costs your recruiters their day. The distance between the 40 and the 100 is the entire business case.

This is where position stops being the only variable. Specificity to your business is the other one, and a vendor's embedded AI is the case that proves position alone is not enough. It sits as deep behind your system of record as anything could, and it still cannot know your rules. The same argument sits underneath why owning your AI capability beats renting it: general intelligence knows everything about nothing in particular.

When is a new interface the right answer?

When there is no incumbent screen worth protecting. The case for putting intelligence behind your system of record assumes a system of record exists and that your people live inside it. Sometimes they do not, and then the calculus inverts.

Proxigee worked with an energy and industrial service provider in the Appalachian Basin that wanted to widen its reach on two fronts at once, new business and new hires. That work was spread across six social channels and a company website. Six native interfaces, six posting habits, and no single place to see whether any of it was working.

We deployed an AI portal that runs all of it from one login: intelligence on what their audiences are actually looking for, a create-and-schedule process that makes consistent publishing realistic for a company with other work to do, and performance measurement sitting in the same place as the publishing.

That is the "on top of" position, and it was the right call. A single interface replacing six does not add a screen to anyone's day. It removes five.

So the rule is simpler than the frame makes it sound. Count the screens your people work in today. One dominant system of record, and the intelligence belongs behind it. Half a dozen tools with no center of gravity, and a layer on top is the thing that consolidates them.

What do you have to decide before you connect anything?

Four things, and they are all answerable before you sign anything or write a line of code.

The read path. What is the AI allowed to see, and can your system actually expose it? A real API, a scheduled export, or nothing at all are three very different projects. Deloitte's 2025 survey found 48 percent of respondents citing data searchability and 47 percent citing reusability as obstacles to their AI automation strategy.³ Those are read-path problems, and they surface early or they surface expensively.

The write path. Does the AI propose, or does it commit? Proposing is safer and slower and puts a human in every loop. Committing is faster and is the version that actually removes work, and it obligates you to the next two answers.

Identity and permissions. Give the AI its own identity. The exception is narrow: if you are typing into a chat window and the answer comes back only to you, acting as yourself is fine, because nothing is written and nothing leaves the conversation. Anything past that, anything that writes to a record, touches a queue, or acts while you are not watching, should run under its own service account.

What you give up otherwise is worth being blunt about. When an agent acts as a person, its actions are indistinguishable from that person's in the audit log, and you lose the ability to answer the first question anyone asks after a mistake: did someone do this, or did the agent? You also hand the agent that person's full access, which is almost always wider than the task requires, and you tie its permissions to an employee who may change roles or leave the company. A separate identity is scoped to the task, auditable on its own, and revocable without touching anybody's account.

The audit trail. What can a reviewer reconstruct six months from now? The question is whether a person can sit down and answer why a specific action was taken on a specific record, which is a higher bar than whether the system wrote a log line.

Where this goes wrong

Gartner predicts that more than 40 percent of agentic AI projects will be cancelled by the end of 2027, and legacy systems that cannot support modern AI execution demands are among the named reasons.⁵ I have written before about the pilot that succeeds and still goes nowhere, where the integration nobody scoped turns out to be the whole project, and about how much of an implementation timeline is spent on work no one planned for. These are the same failure viewed from different ends.

The way through is unglamorous. Pick one task with a clean boundary. Decide the four connection points referenced above. Put the intelligence behind the system your people already use, and let their screen stay simple.

The best AI you deploy this year should be the one nobody mentions, because it adds no screens, or consolidates several into one.