A way for platform teams to say yes to agent builders

Somewhere in your company, someone has built an agent skill that saves them fifteen hours a week. It pulls numbers from a spreadsheet, checks them against the CRM, writes a summary and posts it to the team channel. They built it on a Sunday night. It works.

Every Thursday, they open a chat window, start the skill and wait for it to finish. If they're out, the report doesn't go out. They've automated fifteen hours of work but still have to show up to make it happen. All they want is for the report to run every Thursday at 8am. A cron job could do that. They just don't have anywhere to run one.

So they ask the platform team for help. The request sounds simple enough. They need somewhere to run their agent and access to a few warehouse tables. But the platform team sees a different problem. Someone outside engineering wants to give an agent access to production data. Who controls what it reads? What happens if it writes something it shouldn't? Who owns it when the person who built it leaves?

The platform team offers to build it properly. The request joins the engineering backlog, behind projects with deadlines and people waiting on them. Nobody has done anything unreasonable. The platform team is protecting production. The employee is trying to save fifteen hours a week. And next Thursday, the report still needs to go out.

What happens while they wait

The employee finds another way. Their AI tool supports scheduled tasks, so they figure out how to connect it to the warehouse and CRM, get the credentials working and schedule the report for Thursday morning. It takes some trial and error, but eventually it works. The report arrives at 8am and nobody has to watch it.

As far as the employee is concerned, the problem is solved. But getting there was harder than building the skill in the first place, and the next person who wants to automate something has to figure it all out again. That's a problem when hundreds of employees start building their own agents. Some will get them running, others will give up, and the ones that succeed will each have their own way of handling credentials, scheduling and failures.

The platform team doesn't know most of these automations exist. Nobody planned for them. There's now a credential sitting in a third-party tool, tied to one person's account. Nobody has a reliable record of what the agent can access, what it does during a run or who is responsible for it. When that person leaves, the credential might keep working. Or it might expire and the report stops without warning.

Multiply this by every department building its own agents and you get a growing collection of automations that nobody in engineering can see or manage. The platform team can shut them down, which sends people back to doing the work by hand, or leave them alone, which means accepting risks it can't even inventory, because nobody in engineering has a list of what's running, who owns it or what it can reach. The employees aren't asking for unrestricted access to production. They're asking for somewhere to run the things they've already built.

Data teams had this problem years ago

This should sound familiar to anyone who worked in data engineering ten years ago. Data scientists and engineers could write pipelines on their laptops, but getting those pipelines into production was another matter. They needed compute, credentials, scheduling, retries and monitoring. The platform team couldn't give everyone unrestricted infrastructure access, so deployments went through engineering. A pipeline that took an afternoon to write could take weeks to get running.

Tools like Prefect and Dagster helped change that arrangement. The platform team could provide shared infrastructure with defined permissions and limits, while data teams deployed and ran their own code without opening a ticket for every pipeline. Engineering retained control of the infrastructure, and the people doing the work got control of their workflows.

We're running into a similar problem with agents, except the people building them aren't necessarily engineers. They're in finance, operations, sales and support. They know the process they want to automate, and their AI tools can help them build it. What they don't have is a safe way to run it without becoming part-time infrastructure engineers.

Give people a place to run their agents

Imagine the platform team sets up an environment where employees can deploy their automations. The team chooses which models are available, which systems agents can connect to and what permissions those connections carry. The Thursday report gets read access to the warehouse tables it needs, access to the CRM and permission to post in the team channel. It doesn't get write access to the warehouse, access to every CRM record or someone's personal credentials.

Those decisions are made before anyone deploys a workflow. Once, up front. The employee can take the skill they already built and put it on a schedule. They don't need to request compute, figure out how to store credentials or ask engineering to wire up the integrations.

If the report later needs to update a warehouse table, that's a new permission request. The platform team can review that specific change without taking ownership of the entire workflow. Engineering isn't being asked to build every automation. It's being asked to define where automations can run and what they're allowed to do.

A skill is not a running workflow

There's another problem hiding inside the Thursday report. The employee has a working skill, but a skill that runs when prompted isn't necessarily ready to run unattended. What happens if the CRM is unavailable? What if the warehouse query fails halfway through? What if the agent posts the report twice?

Someone has to decide what happens when a step fails, which steps can retry and how to tell whether the run succeeded. For an engineer, these are familiar problems. For someone in finance who built their first agent last weekend, they're a reason to keep watching the chat window.

The employee shouldn't have to learn workflow orchestration to schedule a report. They should be able to describe the process: pull the numbers, compare them with the CRM, write the summary and post it. The workflow controls when each step runs, what happens when it fails and which permissions are available. The agent handles the work within those steps.

The employee can inspect the result, change the process and see whether Thursday's run succeeded. The skill becomes something the business can depend on, rather than something that works as long as its creator is around to supervise it.

Why another workflow tool isn't enough

You could solve much of this with an existing workflow tool. For one department, that might be all you need. The harder problem appears when dozens of departments start doing it independently. Finance has one automation tool, sales uses another and operations has agents running in a third. Each tool stores its own credentials and execution history.

Then the Thursday report posts the wrong revenue number. The sales team wants to know where it came from. The platform team needs to know which warehouse table was queried, what the CRM returned and what the agent did before publishing the summary. A run log might tell you that the workflow completed successfully, but that doesn't explain why the number was wrong.

This is where agent execution needs to connect with the data infrastructure companies already operate. The organization needs a record of which data an agent accessed, what it did with that data and which outputs it produced. That record needs to connect to the permissions, identities and data lineage already managed by the platform team. Otherwise, every new agent platform becomes another place to investigate when something goes wrong.

Back to Thursday morning

The report still goes out at 8am. The employee doesn't have to open a laptop, and engineering doesn't have to maintain the report. The platform team can see that the automation exists, who owns it, what it can access and what happened during its last run. If the number is wrong, there's somewhere to start investigating.

And when someone in another department builds a useful skill on a Sunday night, they don't have to choose between waiting in an engineering queue and quietly running it with their own credentials. They have somewhere to put it.