"AI agent" has become the name for almost any system with a model in it. That is more than a vocabulary problem. When everything is an agent, nobody can say which component was allowed to do what, and after an incident nobody can say which one got it wrong.
Jev is a useful test case because it is so clearly not an agent. It does not pursue a goal. It does not loop. It does not call tools. It answers a typed question and stops. That makes it a good partner for an agent, provided everyone is clear that the answer is advice, not authority.
This part separates the components and shows how Kloofvale's software team uses a decision signal inside its coding workflow. Kloofvale Local Municipality is fictional, and its systems and figures are illustrative. This is an independent CloudNala analysis, checked against public documentation on 13 October 2026.
Five components, five jobs
| Component | Main job | Should it execute tools? |
|---|---|---|
| General-purpose language model | Interpret, plan and generate language or code | Only through the harness that controls it |
| Agent | Pursue a goal through a loop of model calls and tool use | Yes, within the permissions it has been granted |
| Jev decision model | Return a bounded, typed judgement | No |
| Harness or orchestrator | Supply tools, state, limits and feedback to the agent | It mediates every execution |
| Application policy | Decide what is allowed after the signal | It deterministically controls the action |
TypeSafe's documentation is explicit about the difference. Coding agents, it says, rely on a language model "that streams text, calls tools, and edits files… Jev does none of that."
That leaves a question about the Jev AI Agent Skill, which sounds as though it might blur the line. It does not. The skill is a package of instructions that teaches a compatible coding agent how to prepare state, call the decision API and interpret the answer. Jev AI lists "Codex, Claude Code, Cursor, and other environments that support the skills installation workflow." It is installed with npx skills add jev-ai/jev-agent-skill and configured with an API key and optional settings for language, base URL and model. Jev AI is careful to say what it is not: the skill "does not create tools, grant authority, intercept shell calls, or replace your application's permission system." TypeSafe publishes a separate skill of its own for its API.
So an agent with the skill installed can ask Jev a question when it chooses to. Nothing makes it ask, and nothing makes it obey the answer. Those guarantees, where you need them, have to come from somewhere else.
Kloofvale's coding agent
Kloofvale's digital services team builds Fix-It with Claude Code, using the BMAD Method to structure larger changes (Part 5 covers that side). The tech lead had a specific worry. The agent is fast and usually careful, but every few weeks it proposes something with a larger blast radius than the request implied. The memorable example was a clean-up script to merge duplicate reports, which the agent offered to run against the shared staging database that the call-centre team also used for training.
Nothing bad happened, because the agent asked first. The team wanted a more systematic version of "asked first" for a small class of actions, without turning every command into an approval prompt.
A safer coding-agent loop
The loop runs like this. A developer asks the agent for a bounded change. The agent inspects the code and plans. Before any step in a defined risky class (anything touching a shared database, deleting files outside the working branch, or changing deployment configuration), it asks Jev a typed question about the proposed action and passes the answer, together with the action, to a policy gate. The gate allows the step, asks a person, or denies it. Only then does the tool run.
The gate is the important part. At Kloofvale it is two things the team already controls: the coding agent's own permission settings, which require approval for a defined list of commands, and a rule in the team's review checklist that any change to shared environments is approved by the tech lead. The Jev signal does not replace either. It is used to make the approval request clearer ("high probability this affects shared data") and to catch risky actions that do not match a simple command pattern.
Four useful patterns
Tool-risk gate
Before a destructive or broad action, ask whether the action needs human approval. A Noul such as "Could this action change data that other people or systems rely on?" works well, with criteria spelling out what counts. The real permission system remains authoritative. If the signal says low risk and the permission system says ask, the agent asks.
Completion check
Given the objective, the files changed, the test results and the known gaps, classify the work as complete, needing more verification, or incomplete. This supplements deterministic evidence; it does not replace it. A failing test is a failing test, whatever the probability says.
Model routing
Choose among an approved list of models based on the shape of the task. The application still checks context limits, availability, cost policy and the data boundary before making the call. A decision model can suggest which model suits a task. It cannot decide that a model is allowed to see the data.
Evidence sufficiency
Before an agent reports success, ask whether the evidence it has gathered actually supports the claim. A low or uncertain answer sends the work back for verification. This is particularly useful against a failure covered in our Agent Evidence Layer series, where a tool fails but the answer still looks complete.
The authority rule
Kloofvale's tech lead wrote one line into the team's project context:
The agent may propose. Jev may judge. Policy decides. An authorised tool acts.
The value of the rule shows up after something goes wrong. A wrong action can now be traced to one layer. Did the agent propose the wrong thing? Did the decision model misjudge a clear case, perhaps because it read the action too literally? Was the policy rule too loose, or written for a world that has since changed? Or did the tool have wider permissions than it needed? Each of those has a different fix and a different owner. Without the separation, every incident ends with "the AI did it", which tells you nothing about what to change.
The same reasoning applies to the tools themselves. A gateway that brokers an agent's tool calls is a useful control point but not a trust boundary, and a decision signal is useful evidence but not a permission. In both cases the authority has to sit in something you own and can test.
Where this matters beyond coding
Kloofvale's team met the pattern in its own tooling first, but it applies anywhere an agent acts on a business's behalf. A customer-service agent that proposes a refund, a procurement agent that proposes an order, a banking assistant that proposes a payment: in each case a decision model can usefully classify the proposed action, and in each case the identity checks, limits and approvals of the underlying system must stay in charge. Part 6 looks at several of these in South African settings.
Key points
Jev answers; it does not act. It does not stream text, call tools or edit files.
The Agent Skill teaches, it does not enforce. It grants no authority and intercepts nothing.
Permission lives in the gate you control. Agent settings, review rules and system permissions stay authoritative.
Use signals to sharpen approvals, not to skip them. A clear risk reason makes a person's decision faster.
Separation tells you which layer failed. Propose, judge, decide and act each have their own fix.
Previous: Part 3, State in, signal out, code acts. Next: Part 5, Jev and BMAD together. All parts are on the series page.
How CloudNala can help
We help teams draw the authority lines in agent systems: which component may propose, which may judge, where the real permission sits and how each decision is recorded. For coding agents that usually means a short list of risky action classes, a gate built from controls the team already has, and project context that states the rule plainly enough for both people and agents to follow.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Decision Review or write to us at consult@cloudnala.co.za