By Dr. Kevin Shepherdson
In Part I, we discussed how low-code, no-code, and AI-powered software creation tools are changing the way applications are built. The key point was that the ability to create has been democratised. A non-technical user can now describe an idea in plain English and generate an application, workflow, chatbot, or even an autonomous agent.
But we also highlighted the central risk: Everyone can create, but not everyone can govern.
Creating an application is not the same as deploying it responsibly. Many creators may not understand the code, the architecture, the data flows, the security implications, or the downstream consequences of what they have created. This becomes especially risky when they move too quickly from experimentation to creation and deployment without developing the maturity needed to govern and manage AI responsibly.
In Part II, we went deeper into the data lifecycle. We looked at how every AI application should be assessed across the stages of Collect, Store, Report, Decide, Distribute, and Dispose. This lifecycle lens matters because an AI app is not merely a screen, form, prompt, or workflow. It is a system that collects data, stores information, generates outputs, influences decisions, distributes results, and eventually needs to be retired.
In Part III, we now turn to an even more serious development: agentic AI. This is where the risk escalates.
Low-code and no-code tools no longer only help users build applications. Increasingly, they allow users to create agents — digital workers that can reason, use tools, call APIs, search the web, write code, update systems, send messages, and perform tasks with varying levels of autonomy.
This is where many organisations may be moving from simple AI assistance to AI action before they fully understand what that means.
The Agentic AI Bandwagon: Running Before Learning to Walk
Everyone is excited about agentic AI.
The promise is attractive: instead of asking AI to merely answer a question, we can now ask it to complete a task. The agent can plan, search, analyse, draft, update, execute, and report back. For business users, this sounds like productivity at scale. For developers, it opens the door to automation across systems. For leaders, it suggests a future where digital workers can augment or even perform parts of human workflows.
But the excitement may be running ahead of understanding.
Many people are jumping onto the agentic AI bandwagon before they properly understand how large language models work in the first place. They may not yet understand hallucination, prompt sensitivity, context windows, tool-use limitations, cost escalation, data leakage, or the fact that an LLM does not “know” in the same way a human expert knows.
This is like running before learning how to walk. With a normal AI chatbot, the system usually produces an output. The user can read it, assess it, and decide whether to act.
With an agent, the system may act as part of the workflow. That changes the risk.
An agent may not only answer a question. It may search external sources, call a database, retrieve records, generate code, update a CRM, send an email, create a ticket, schedule a meeting, or trigger another workflow. In other words, the AI is no longer just producing content. It is participating in operations.
The governance question therefore changes from: Is the AI output correct? to: What is the agent allowed to do, what systems can it access, what happens if it acts wrongly, and who is accountable?
The Agentic Workflow Is Not Magic
A simple way to understand agentic AI is through the workflow:
Plan → Think → Act → Observe → Review → Improve
Many creators focus only on the exciting parts: planning, acting, and getting things done. But the governance-heavy parts are often the ones they miss: observation, review, escalation, and improvement.
Plan: What Is the Agent Supposed to Do?
The agent begins with instructions.
This is why planning is not a cosmetic step. Even tools such as Claude Code emphasise the need to plan before coding or acting. Anthropic’s Claude Code documentation describes common workflows for exploring codebases, fixing bugs, refactoring, and testing, while its best-practice guidance points developers toward disciplined context management and structured workflows rather than simply asking the agent to “just build it.” Claude Code is positioned as an agentic coding system that can read a codebase, make changes across files, run tests, and deliver committed code — which is precisely why planning matters before action is allowed.
In practical terms, this means the creator should not begin with: “Build me the app.”. A safer starting point is: “First understand the objective, inspect the relevant context, identify assumptions, propose a plan, highlight risks and edge cases, and only then proceed with implementation after approval.”
This includes the system prompt, task prompt, workflow design, tool orchestration, boundaries, rules, and objectives. In a low-code or no-code platform, the creator may simply type something like: “Research potential customers and send follow-up emails.”
That sounds simple. But from a governance perspective, it raises many questions.
Who counts as a potential customer? Which sources can the agent use? Can it scrape websites? Can it use personal data? Can it send emails directly, or must a human approve them first? What tone should it use? What claims can it make? What happens if the information is wrong?
The planning stage is where the agent’s purpose and boundaries must be defined. If the instructions are vague, the agent may improvise in ways the creator did not anticipate.
Think: The LLM Does the Reasoning
This is the part many people forget.
In an agentic workflow, the “thinking” is done by the LLM. The model interprets the prompt, reasons through the task, decides what information it needs, chooses which tool to call, and determines the next step.
This means the quality of the agent’s behaviour depends heavily on the quality of the model, the prompt, the context, and the constraints.
Some creators may try to reduce cost by using a cheaper model without realising that the reasoning step is where judgment is being exercised. If the reasoning layer is weak, the agent may misunderstand the task, call the wrong tool, rely on poor sources, skip validation, or act prematurely.
Cost control is important. But using an underpowered model for a high-risk agentic workflow can be a false economy. The governance question is: Is the model capable enough for the task, the domain, and the risk level?
Act: The Agent Uses Tools
The Act stage is where agentic AI becomes operationally serious.
This is where the agent may call tools, use APIs, retrieve documents, update systems, generate code, send messages, or trigger downstream workflows.
For example:
1. a sales agent may update a CRM;
2. a customer service agent may send a response;
3. a coding agent may modify files;
4. a finance agent may generate reports;
5. a compliance agent may flag transactions;
6. a procurement agent may approve low-value purchases.
This is no longer just AI-generated text. This is AI-enabled action.
The governance issue is not only what the agent says, but what it is permitted to do. The more authority the agent has, the stronger the control environment must be.
1. An agent that only drafts an email is one risk level.
2. An agent that sends the email automatically is another.
3. An agent that sends the email, updates the customer record, and triggers a follow-up workflow is a much higher risk.
Observe: The Forgotten Step
This is one of the most neglected parts of agentic AI. After the agent acts, it must observe whether the action worked, failed, created an exception, produced an unexpected result, or triggered unintended consequences.
Take a simple web-search agent. It is easy for a developer to allow the agent to search the web and summarise results. But governance requires more than that. The developer must define how the agent observes and validates what it found.
For example:
Did it use authoritative sources?
Are the sources current?
Did it extract the correct information?
Are there conflicting sources?
Did it confuse opinion with fact?
How many retries are allowed?
When should it stop searching?
When should it escalate to a human?
What should be logged as evidence?
If these questions are not defined, the agent may produce a confident answer based on weak information. Worse, if the agent is connected to downstream tools, it may then act on that weak information.
Observation is not optional. It is part of the control system.
Review: Who Checks the Agent?
After observation comes review.This is where many organisations invoke the phrase “human in the loop.” But this phrase is often used too casually.
A human in the loop is only meaningful if the human is qualified, informed, empowered, and accountable.
A reviewer who does not understand the domain cannot properly assess the output. A reviewer who cannot see the logs cannot understand what the agent did. A reviewer who has no authority to stop or override the agent is not a real control. A reviewer who is overwhelmed by too many alerts may simply rubber-stamp the agent’s actions.
For human oversight to work, organisations must define:
1. who owns the agent;
2. who reviews its outputs;
3. who can approve or reject actions;
4. who can pause or disable the agent;
5. who investigates exceptions;
6. who updates the agent after failures.
Human oversight must be designed. It cannot be assumed.
Improve: How Does the Agent Become Safer Over Time?
Agentic systems should not be deployed and forgotten.
Their logs, failures, exceptions, user feedback, cost patterns, and edge cases should be reviewed over time. Prompts may need refinement. Tool permissions may need tightening. Data sources may need updating. Escalation thresholds may need adjustment. Some agents may need to be retired.
This is where AI management becomes important.
The question is not whether the agent worked during the first demonstration. The question is whether it continues to behave safely, accurately, cost-effectively, and within policy once it is used in the real world.
Why Agents Increase the Governance Stakes
Agentic AI increases risk because it combines several layers of complexity.
1. First, LLMs are probabilistic. They can generate plausible but incorrect outputs.
2. Second, agents are tool-using systems. They can act on those outputs.
3. Third, low-code and no-code tools make it easier for non-technical users to create these agents.
4. Fourth, many creators may not understand the full workflow, domain context, data lifecycle, or control requirements.
This means the organisation may end up with agents that are easy to create but difficult to govern.
The risk is not only that the agent may make a mistake. The deeper risk is that the agent may make a mistake at scale, through connected systems, with insufficient visibility, unclear accountability, and no effective stop mechanism.
That is how useful automation can become runaway automation.
The Cost Problem Behind Agentic AI
There is also an economic issue. Agentic AI can become expensive very quickly.
A simple chatbot may involve one prompt and one response. An agentic workflow may involve multiple planning steps, several LLM calls, tool calls, web searches, API calls, document retrieval, retries, validation steps, and final output generation.
Behind the scenes, the agent may consume far more tokens and resources than the creator expects. Costs may rise because of:
1. long prompts;
2. large context windows;
3. repeated retries;
4. inefficient tool calls;
5. unnecessary model usage;
6. poor prompt design;
7. excessive logging;
8. multiple agents calling each other;
9. use of high-cost models for low-risk tasks.
Creators may think the agent is simply “doing the task.” But unless they can see what happens behind the scenes, they may not understand how much reasoning, searching, calling, retrying, and generating is taking place.
This creates a new governance question: Are we managing not only AI risk, but also AI cost?
In agentic AI, token usage and tool usage are not just technical details. They are part of operational governance.
Flowcharts Are Useful, But Not Sufficient
Many low-code and workflow automation tools are based on flowcharts. Flowcharts are helpful. They show triggers, steps, branches, and actions. They make automation easier to visualise.
But agentic AI does not operate only like a traditional flowchart. Inside the agent, the LLM interprets instructions, reasons through context, selects tools, responds to intermediate results, and decides what to do next. Some of that behaviour may not be obvious from the outer workflow diagram.
This is why organisations need more than visual automation.
They need transparent instructions, clear reasoning boundaries, tool-use visibility, provenance, logs, and cost tracking.
In other words, they need to see not only the boxes and arrows, but also the instructions and evidence that guide the agent’s behaviour.
The Governance Question for Part III
Agentic AI should not be approached as a shortcut to automation. It should be approached as a governed operating model.
Before deploying an agent, organisations should ask:
1. What is the agent’s purpose?
2. What process does it follow?
3. What permissions does it have?
4. What evidence does it rely on?
5. Who owns and reviews it?
6. What policies constrain it?
7. What platform controls support it?
8. What does it cost to run?
9. How is it monitored?
10. When should it stop?
These are not technical questions alone. They are governance questions.
Final Thought for Part III
Low-code and no-code tools made it easy to create AI applications. Agentic AI makes it easy to create digital workers. That is a major shift.
When AI only generates content, the main risk is whether users rely on the content incorrectly. But when AI agents act, the risk extends into systems, workflows, decisions, costs, and accountability.
This does not mean organisations should avoid agentic AI. It means they should stop treating it as a toy, shortcut, or productivity gimmick.
Agentic AI requires a maturity mindset. It requires lifecycle thinking and qualified human oversight. It also requires cost visibility and provenance. Finally, it requires governance by design.
Because in the age of agentic AI, creators should no longer just ask: Can the AI answer? The key question is: Should the AI act — and under what controls?
