Run your agents where IT can already see them

Ask a CIO how many AI agents are running in their company right now. I’ve yet to hear a confident number.

No one’s hiding them. Agents are just easy to build. Someone wires a model to a few APIs over a weekend, it works, and the team starts relying on it. It runs on a spare service, with an API key in an environment variable and its memory in a database someone set up for the purpose. Multiply that by every team that has an idea, and you have agents all over the company that IT never saw ship.

Each one worked in its demo. The trouble starts when someone has to account for them.

The agents you can’t find

Gartner has a name for where this ends. In its 2027 strategic technology trends, it predicts that “by 2027, the enterprise phantom agent crisis will force an 80% rollback of autonomous AI deployments, rendering unmanaged agents untraceable and derailing automation investments.”¹

Read the cause in that sentence: untraceable. The agents in it get pulled because no one can say what they’re doing.

Gartner’s instruction is the obvious one: “Inventory all AI agent identities: Discover, map and manage all sanctioned and unsanctioned AI agents across your organization.” It also says why that’s hard. “Poor visibility will make it nearly impossible for security teams to enforce least-privilege access or maintain accurate audit logs.”¹

Before turning any agent on, the same research asks three questions: “What is its role or purpose? What is it allowed to do? Where is it allowed to operate?” For an agent running on a spare service, the honest answer to all three is “ask the person who built it.”

Agents go dark because of where they run

An agent built as its own service brings its own hosting, its own credentials, its own memory and its own way of changing. None of that is anywhere IT looks. So the inventory becomes a hunt, and the hunt is always behind, because Gartner is right that “you are deploying autonomous agents faster than you can secure them.”

I think the fix is structural. Most useful agents serve an app, like the request app IT already runs or the deal app sales lives in. So put the agent inside that app. Define it in the app’s code, and ship it in the app’s deploy.

Then the agent gets everything the app already has. It runs on the same managed runtime. It uses the app’s credentials, which IT already manages. Its changes go through the same deploy, which already leaves a record. Inventory stops being a project, because deploying is what puts the agent on the list.

This is the same move Gartner recommends for AI governance in general. The AI Value Gap Is Really an AI Risk Gap warns that “when it comes to generative and agentic AI, pilots lie,” and tells CIOs where the controls belong:²

An agent defined in code, in an app that deploys through a governed path, is that idea applied. What it can do is in the code. Who changed it, and when, is in the deploy.

That includes the few actions that need a person. Gartner recommends “explicit human approvals or guardian agent oversight for high-risk operations.”¹ In code, that rule sits on the tool itself and only fires above the line you set, so a person signs off on the risky call and the routine work carries on.

Use a workflow when you can

A fair question at this point: if so much of this is code anyway, why have an agent at all?

Often you shouldn’t. If every access request arrives as a form with the person, the app and the role already picked, a workflow with one branch does the job. It’s cheaper, and it does the same thing every time.

Agents earn their keep when the request is a sentence. “Dana starts Monday in FP&A, can she have what Sam has?” Someone has to find both people, read what Sam has, and decide which of it Dana should get. That judgment is the part you hand to a model.

What that looks like in Helix

That was the design goal for agents, now in Tray Helix. A team defines an agent in its app’s code: the model, the instructions and the tools. The agent ships in the app’s deploy, and any function or schedule in the app can call it.

Helix runs it. It drives the model, runs the app’s actions against its connected services, and keeps each conversation. The model key is managed by Helix and never sits in the code. And because every new Helix project already teaches the AI assistant how to write agents, Claude can build one from a prompt.

IT sees it. Every live agent shows on its project’s Agents tab with its model and its tools, and every run, down to each tool call, is in the project’s logs. An agent only changes when the app deploys, and every deploy that adds, changes or removes one lands in the organization’s activity trail. Any tool can be set to wait for a person’s approval, every time or only above a line the team chooses.

The access-request example, start to finish, is in Build agents where your apps already live.

Where this leaves IT

Your company will run agents built by people who have never thought about inventories or audit logs. That’s fine if the agents live where IT already looks.

Then Gartner’s three questions have answers you can show. What’s the agent for? It’s in the code, next to the app it serves. What is it allowed to do? Its tools, listed on the Agents tab. Where does it operate? Inside that app, on the platform IT already manages. And when someone changes any of that, the deploy says so.