Before You Agentify the Workflow, Define the Work

The newest AI-agent mistake is not giving the model a bad prompt. It is giving the model a bad job.

That mistake is easy to miss because the demo still looks impressive. The agent reads a thread, checks a document, drafts an email, updates a CRM field, or moves a task from one column to another. Everyone can see the motion. What they cannot see is whether the business ever defined the work well enough for that motion to be useful.

That is why a phrase from an indexed Reddit discussion stood out this morning: "most of these founders haven't defined their processes well enough to automate them in the first place." That is not anti-AI cynicism. It is the practical objection underneath a lot of agent fatigue. If the workflow is fog, the agent does not clear the fog. It just moves faster inside it.

A useful agent starts after the work is visible. Not after the tool is chosen. Not after the team finds a clever integration. After someone can say, plainly, what job needs doing, what information is allowed in, what decision must be made, what output counts as done, and where a human must approve the business event.

"Agentifying" is not a strategy

There is a reason the word "agentifying" is starting to sound a little ridiculous. It often means taking a messy process, sprinkling autonomy on top, and hoping the result feels modern. The old version was "let's automate this." The new version is "let's give it an agent." The failure mode is the same.

Another indexed Reddit snippet captured the sharper version: businesses can "automate without thinking through what actually needs a human in the loop." That is the line to pay attention to. "Human in the loop" is not a compliance decoration. It is an operating decision. It asks where error becomes expensive.

If an agent drafts a customer reply, the human approval point is probably before send. If it prepares a refund recommendation, the gate is before money moves. If it summarizes a medical note, the gate is before the record changes. If it reviews a legal form, the gate is before submission. The useful question is not whether a human is somewhere nearby. The useful question is which action cannot happen until a responsible person says yes.

Most agent projects skip that question because the team is focused on capability. Can the agent read this? Can it write that? Can it call the API? Can it run every morning? Capability feels like progress. But capability without a named approval point is how a helper becomes a liability.

The enterprise market is saying the same thing in harder language

This is not only a small-business problem. The enterprise security market is now saying the same thing with bigger vocabulary.

VentureBeat reported on May 11, 2026 that Cisco President Jeetu Patel described a wide production gap: many enterprises are running agent pilots, but very few have reached production. The article framed the gap as a trust problem and named the first questions any CISO will ask: "which agents have production access to sensitive systems, and who is accountable when one acts outside its scope?"

That sentence is useful because it strips away the hype. Production access is not a technical checkbox. It is authority. Accountability is not a meeting note. It is ownership. Scope is not a vague intention. It is the boundary between useful work and dangerous drift.

Michael Dickman, Cisco's SVP and GM of Campus Networking, put the principle even more plainly in the same VentureBeat piece: "Trust actually is one of the key requirements. Just table stakes from the beginning." That is the correction. Trust is not what you add after the agent proves it can act. Trust is part of deciding whether it should be allowed to act at all.

OpenAI's public Codex safety language points in the same direction. Security teams need to govern "what they can access, when human approval is required, which systems they can interact with, and what telemetry exists to explain their behavior." That list is not just for coding agents. It is the basic shape of agent operations: access, approval, system boundary, explanation.

Once you see the pattern, the practical answer gets simpler. Before an agent gets connected to live work, make the work explicit enough to govern.

Start with the workflow map

The first artifact should not be an agent. It should be a workflow map.

A workflow map does not need to be fancy. It needs to show the path from trigger to finished product. Something happens: a form is submitted, a client emails, an invoice arrives, a lead books a call, a support ticket opens, a document changes, a deadline approaches. The business responds through a sequence of steps. Some steps gather information. Some classify. Some draft. Some decide. Some execute. Some notify. Some record the result.

That map tells you where an agent belongs. It also tells you where it does not belong yet.

A good first agent job is usually not "run the workflow." That is too broad. A good first job is narrower: classify the inbound request, prepare the client brief, check the file for missing fields, draft the response, assemble the options, compare the record against the policy, or create the review packet. These jobs create capacity without pretending the agent owns the business outcome.

The map also makes the human approval point obvious. If the next step sends money, changes a record, issues advice, contacts a customer, deletes data, files a document, or commits the company to a position, the agent should probably stop and ask. Not because agents are useless. Because that is where the business event happens.

Then write the job card

After the workflow map, write the agent's job card. This is the missing middle between a prompt and a production system.

The job card should answer seven questions in plain language:

1. What exact job does this agent do?
2. What event, schedule, queue, or request wakes it up?
3. What information may it read?
4. What tools may it use?
5. What output must it produce?
6. Who owns review and correction?
7. What conditions stop the agent and escalate to a human?

Those questions look boring. Good. Boring is what makes an agent usable by a business instead of just impressive to a builder.

If the team cannot answer them, the project is not ready for autonomy. It may still be ready for discovery. It may be ready for a manual process cleanup. It may be ready for a simple checklist, template, queue, or deterministic automation. Those are not lesser wins. They are often the exact foundation an agent needs before it can do real work.

This is where Stephen Nickerson's practical frame matters. The goal is not to worship agents. The goal is operating capacity. Sometimes the right answer is an agent. Sometimes the right answer is a smaller workflow, a clearer owner, a better intake form, or a human approval gate placed in the right spot. The agent should serve the work, not become the excuse for avoiding it.

Give access last

Access should be the last step in agent design, not the first reward for a promising demo.

The order matters. Map the workflow. Define the job. Name the owner. Set the approval point. Decide what evidence the agent must leave behind. Then grant the smallest access that lets the agent do that job.

That sequence prevents the common drift. The agent starts by reading a harmless document. Then it gets email. Then calendar. Then CRM. Then billing. Then a shared drive. Then a production system. Each addition seems reasonable in isolation, but nobody stops to update the actual job. The business ends up with a worker whose authority expanded faster than its accountability.

The better pattern is to make every new permission earn its place. If the agent needs a new system, say why. If it needs a new tool, say what output improves. If it needs direct execution, say what risk is controlled and where the log lives. Access is not a vibe. It is a design decision.

The practical test

Here is the simplest test before you agentify a workflow:

Can a competent human read the workflow map and job card, then predict what the agent will do, what it will not do, when it will stop, and who is accountable for the result?

If the answer is no, do not give the agent more tools. Make the work clearer.

If the answer is yes, the project becomes much more interesting. Now the agent is not floating around the business as a clever assistant. It is assigned to a post. It has a product. It has boundaries. It has a review line. It has a way to improve without quietly collecting more authority than anyone meant to give it.

That is the difference between AI theater and agents that actually work.

Sources

• VentureBeat, "AI agents are running hospital records and factory inspections. Enterprise IAM was never built for them," May 11, 2026: https://venturebeat.com/security/cisco-dickman-agentic-ai-trust-identity-governance-microsegmentation
• OpenAI, "Running Codex safely at OpenAI," indexed May 2026: https://openai.com/index/running-codex-safely/
• The Hacker News, "Your AI Agents Are Already Inside the Perimeter. Do You Know What They're Doing?", May 6, 2026: https://thehackernews.com/2026/05/your-ai-agents-are-already-inside.html
• WAV Group, "The Autonomous Agent Problem: Who Is Governing the AI You Already Authorized," May 11, 2026: https://www.wavgroup.com/2026/05/11/the-autonomous-agent-problem-who-is-governing-the-ai-you-already-authorized/
• Public indexed Reddit snippets from r/AI_Agents and r/Entrepreneur, May 2026. Direct Reddit pages returned verification blocks, so snippets were used as public-index signals only.

Stephen Nickerson.
Built for operators who need agents they can test, trust, and improve.