Meet support.agent: Our First Fully Autonomous Digital Employee

A colleague you will never meet

Every 30 minutes, support.agent signs in and reads the ticket queue. It picks out the tickets that look like network problems — the Wi-Fi is slow, a printer disappeared, the office lost internet for a minute — and goes to work. It pulls the current state from the wireless controller, the firewall, the switches, and device management. It checks what our monitoring remembers about that network over the past few days. It looks up which client, which site, and which hardware is involved. Then it writes what it found onto the ticket, posts a summary in Slack, and files its notes in Google Drive.

By the time a Team Member opens that ticket, the evidence is gathered, the timeline is laid out, and there is a working theory on the table. What used to be the first twenty minutes of every network ticket is already done.

Network problems were only where we started. support.agent also runs security investigations. When a sign-in looks wrong, or the endpoint-security platform raises an alert, it pulls the sign-in history, the alert detail, what the device was doing at the time, and who the person is, then lays the sequence out in one place. Assembling that picture by hand is exactly the kind of work that is urgent, tedious, and easy to do incompletely at the end of a long day.

The notes are the part that compounds. Every diagnosis and every investigation leaves a durable record for that client — how their network normally behaves, which alerts turned out to be noise, what the problem was last time and what resolved it — and later runs read those notes before they start. The second investigation at a site begins with what the first one found. The agent gets better at a given client the longer it works there, and nobody has to write that knowledge down by hand. Under the old way, the twenty minutes a person spent gathering evidence vanished the moment they closed the ticket.

support.agent is not a chatbot bolted onto the help desk. It is our first fully autonomous digital employee. It has its own identity in our directory, the same way a new hire would. It can only see the systems its role allows. Everything it does is logged under its own name. And it works on its own schedule, without anyone asking it to.

It is not a replacement for anyone, and it never acts on its own. support.agent works in service of a person: every finding lands in front of a Team Member who checks it, decides, and acts. That human in the loop is how we do quality control, and it is not optional. There may come a day when more of this runs without a person watching, but we are not there yet — and getting there safely means treating quality control and security as the whole job, not an afterthought.

Still, this is the thing all the excitement about AI has actually been about: not a better search box, but software that shows up, does real work across real systems, and hands a person the result. The rest of this story is how we got here, working backwards from the problem.

Computers could not talk to all these systems — until now

The reason nobody automated this years ago is that it was genuinely hard. Every platform has its own way for software to talk to it: different sign-in, different vocabulary, different shape of answer. Writing a program that spoke to all of them, and could reason about a fuzzy ticket in plain language, was out of reach.

Two things changed. Large language models supplied the reasoning: an AI can now read “the Wi-Fi is slow” and know what to check. And the Model Context Protocol (MCP) supplied the connection. MCP is a common language that lets an AI use outside tools instead of only answering from memory. A custom MCP server is a wrapper around one platform — a Rosetta Stone that translates that vendor’s particular dialect into the one language the AI understands, carries the actual requests, and returns the answers in a consistent form.

Few of the platforms we manage offered one, so we wrote our own for each and host them together at mcp.macktez.com. Even where a vendor does offer an MCP server, it often exposes only part of the platform, gives us little say over who can use which tools, and keeps no record of who did. Building our own meant we could cover every tool we need, decide permissions ourselves, and keep our own log. Once every system spoke the same language, an AI could reach all of them — and so could an agent.

What a digital employee is allowed to do

Giving software its own identity and access to every system is only a good idea if it is governed at least as well as a person would be. A few principles do most of the work.

support.agent only investigates. It never changes a setting, restarts a device, or replies to a client. Those decisions stay with a person, who now makes them with the evidence already in hand. The connections that exist to answer questions are built so they cannot change anything — a tool that alters a system simply cannot be added to them — and where changes are possible, reaching them takes a second, separate permission.

It uses exactly the same sign-in, permissions, and logging as any Team Member, because it uses exactly the same connections. There is no looser path for software. Where a vendor only offers shared keys, we use more than one: people with read-only access work through a key that can only read, and the separate key that can make changes is used behind the scenes only for those with elevated permissions.

We keep our own record of who did what. Some vendors let our connection sign in as the individual and log the person themselves. Many others cannot tell who is using a shared key, so we log every request through every connection against the Team Member or agent who made it. We can answer who did what on every platform we manage, including the ones that were never built to tell us.