From access to skills to processes: how AI agents arrive in a company
Nobody decides to adopt agents
Ask a company when it decided to put AI agents into production, and the honest answer is usually that it didn't. It bought ChatGPT, Claude or Copilot seats, published a usage policy and went back to work.
The agents arrived anyway. In one finance team, a skill that explains month-end variances runs at 7am on a cron job. Some mornings it stops partway through, and the analyst who wrote it reruns it by hand before anyone asks. Other mornings it finishes with a wrong number that nobody spots until it shows up in someone else's report.
That's an agentic workflow, even though nobody approved it or owns it. It's still built like one person's shortcut. To see why it breaks, separate the skill from the process. They can be the same file. The difference is who depends on it.
Skills are job descriptions, processes are commitments
A skill tells an AI what good looks like for one kind of task, such as explaining a variance or triaging a ticket. Think of it as a job description. Whoever wrote it runs it and reads the output, so it's allowed to be wrong now and then.
A process is closer to a commitment. It takes a defined input, runs known steps and produces a defined output whether or not anyone is watching. Other people plan their day around that output, and when it goes wrong someone has to explain what it did and why.
Payroll and the month-end close are processes, and they hold up because of two properties. They're deterministic, so the same input gives the same output and a failure points to the step that caused it. They're also durable, which means a failed run resumes from the failed step and keeps the work already done. On-call rotations and audit trails are built on both.
An agent breaks the first property, because the same input can produce a different answer on every run. That raises the stakes on the second. If a rerun won't reproduce the first attempt, starting over from step one stops being a safe default.
No one would add a step like that to payroll on purpose. In most companies it gets added gradually, through decisions that each made sense at the time.
Access, skills and reach
In our conversations with platform and data teams, the stages show up in the same order. Most teams can name the stage they're in. What they tend to miss is that usage runs a stage or two ahead of what's been governed.
The first stage is access, meaning the seats and the usage policy. For a while there's little else to manage.
Skills come next. Heavy users get tired of retyping the same instructions and save them as SKILL.md files, Cursor rules or custom GPTs, which teammates copy out of Slack and edit. After a few months nobody has a full list. Nobody asked for one.
Then the skills need reach. A skill limited to whatever you paste into it stops being useful, so the data or platform team starts getting tickets for MCP servers, API keys and service accounts, often from people who have never filed a ticket with them before. Once access is granted, the only thing keeping the skill from emailing a customer is a line in the file asking the model "please don't."
If one of those stages describes your company, your governance probably stops a stage or two earlier.
None of it required a budget or a vendor, which is why IT and security tend to hear about it late. At this point the main safeguard is still the author of each skill, who reads the output before anyone else does.
Agentic workflows: the skill becomes a process
Nobody announces the fourth stage. A working skill keeps growing, and each addition is another step: check this system, match against that one, never do this. After a few months, the skill reads like a runbook.
Take a customer success manager who writes a skill to summarize changes in accounts renewing this month. Over a quarter it picks up six more instructions. It pulls usage from the product database, matches accounts to CRM records, skips churned customers, adds open support tickets, leaves pricing out and posts to the team channel by 9am. His manager asks for it every Monday, so it moves to a GitHub Action. By then, two teammates have written their own versions.
The team is now running three versions of one process, and none of them was designed as one. Every step assumes the system it calls will answer the way it did yesterday, every "don't" in the file is a request the model is free to ignore, and when you stack ten of those steps on top of each other you get what we call prompting and praying.
Here's a simple test. If someone would notice when it doesn't run, it's a process.
That's good news. The people closest to the work usually find the right process first. What they don't have is a way to make their version the team standard and run it with the same rigor as payroll. Until they do, it depends on one laptop and one person's credentials.
It breaks
The first failure is quiet. One Monday the renewal summaries don't arrive. The run died at step six, after pulling usage and matching about half the accounts, so the only option is to start again from the top. Because a model sits in the middle, the rerun doesn't match the first attempt. This time it includes a churned customer and quotes a price.
Then people who never cared how the skill was written start asking questions. The manager wants to know why the numbers changed, and security wants to know who granted it CRM access. Someone else asks whether last month's summaries were right. Nobody can say, because nothing recorded what the agent did or why.
The teams we talk to describe this stage in similar words: "I can't let it run on its own yet." "It failed and we had to start over." "Show me how it got to that answer." "IT won't let me run this."
The usual reaction is to add more instructions to the skill. It doesn't help. The skill already does what it says. What's missing is the structure a process normally has around it, including a way to resume, a record of each decision, access limits the model can't argue its way past, and a person who approves the steps that need it. Blaming the author or switching the skill off are the other common reactions, and both discard the part that worked. Someone figured out a process their team wants to use.
What each stage needs
Each stage needs one thing, and it's cheaper to put in place before the next stage starts.
For access, decide which systems and data an AI may touch, and who approves requests for more. That takes one meeting now. Later it means unwinding whatever people built on the wrong answer.
Skills need a home, with one copy of each skill and a named owner, in a place everyone can see. Skills over MCP, a finalized MCP extension, lets a server serve skills alongside its tools. FastMCP already serves skills as resources, and support for the extension is in progress.
Reach needs an MCP gateway. Every MCP server sits behind it with its own credentials, read-only by default, so access is granted in one place. Without a gateway, each request to the data team ends in a refusal or a favor, and each favor is another agent running on someone's personal credentials. That's how agent sprawl starts.
Agentic workflows need to be built as processes. The skill stays as the description of how the work should be done, and a workflow defines what runs, in what order and with what access. The workflow adds four things the skill never had. It's durable, so a failure at step six resumes at step six instead of at step one, each step gets only the access it needs to do its job, and a ledger records every decision along with what the agent saw and why it chose what it did, which gives each output provenance. Approval points bring a person in where one is needed, usually before an action that can't be undone. When something breaks, fix whichever of the four the incident exposed first. This work tends to land with the platform or data team, since they already run jobs that have to finish.
The people building these skills know their own work better than anyone else in the company. A governed place to build lets the hours they save add up across teams. Without one, those hours go into cleanup later.
Score it on outcomes
Once a workflow is rebuilt, someone will ask whether it can run unattended. A run count doesn't answer that. "It ran 40 times" says nothing about quality, while "31 approved, 6 denied, 3 escalated to a person" shows whether it's doing the job and where it still needs a human.
Build that scoreboard during the rebuild and read it from the ledger. Each week adds evidence, and the decision to give the workflow more autonomy can rest on that record.
Where to start
Ask each team one question this week: which AI-driven task would someone notice if it didn't run tomorrow? Every answer is a process, and most will have no owner and no record of what they've done.
For each one, name an owner and answer three questions. What happens when it fails halfway? Who can see what it did? Who approved what it's allowed to touch? If nobody can answer, it isn't ready to run unattended, however good its output has looked so far.
Then ask the opposite question: which process would they love to automate with AI but haven't yet, and why not? The why-not tells you what's missing. Usually it's access to a system, a place to build it or someone willing to approve it.
Prefect Agentic Workflows gives you a deterministic process for non-deterministic work. Agents decide how, and your workflow decides what must be true. Every decision is recorded with the data behind it, each step gets only the tools it needs, and people review the exceptions while durable runs pick up where they stopped. Start with one process.