I recently came across an interesting problem while thinking about AI agents.
Imagine an enterprise agent with 100+ tools:
- Search Wazuh
- Query Microsoft Sentinel
- Check DNS
- Check IP reputation
- Query EDR
- Search AWS CloudTrail
- Query PostgreSQL
- Search OpenSearch
- Create Jira ticket
- Send email
- Restart service
- Block IP
- Get user information
- Get asset information
- And many more...
Now a user asks:
"Investigate this suspicious login from 10.20.30.45."
How does the agent decide what to do?
The obvious solution is:
Send all 100 tools to the LLM and let it choose.
But this creates a practical problem.
The larger the tool catalog becomes, the more information we have to put into the agent's context.
More tools → more tokens → more latency → more chances of selecting the wrong tool.
So I started looking at a different architecture.
Don't ask the big LLM to make every small decision
Instead, separate the problem into two layers.
Layer 1 — Reasoning
The LLM understands the user's objective:
"The user wants to investigate a suspicious login."
Layer 2 — Decision
A small decision engine determines:
"Which of these available tools is relevant?"
For example:
User Request
|
v
Reasoning LLM
|
Understand intent
|
v
Decision Layer
|
+-------------+-------------+
| | |
Wazuh EDR DNS
| | |
+-------------+-------------+
|
v
Execute Tool
This is where Jev becomes interesting.
Jev is designed for bounded, typed decisions such as Choice, Score and Noul, rather than generating a paragraph of text. The current Jev ecosystem contains examples for tool routing, model routing, guardrails and agent workflows.
A practical example
Let's say our agent has these candidate tools:
tools = [
"search_wazuh",
"query_edr",
"check_ip_reputation",
"query_dns",
"query_cloudtrail",
"create_jira_ticket"
]
The agent has already understood the user's intent.
Now instead of asking the main LLM:
"Which tool should I call?"
we can formulate a bounded decision:
Which tool is most relevant?
1. search_wazuh
2. query_edr
3. check_ip_reputation
4. query_dns
5. query_cloudtrail
6. create_jira_ticket
The decision layer returns something like:
search_wazuh: 0.82
query_edr: 0.11
check_ip_reputation: 0.05
query_dns: 0.01
query_cloudtrail: 0.01
create_jira_ticket: 0.00
Our application can then apply its own policy:
if confidence > 0.75:
execute(selected_tool)
else:
ask_llm_for_more_context()
Notice something important.
The decision engine does not execute anything.
Our application still controls execution.
That separation is important for enterprise systems.
What happens when we have 100 tools?
We can take this further.
Instead of:
100 tools
↓
LLM
we can use a two-stage approach:
100 tools
↓
Decision layer
↓
10 candidate tools
↓
LLM reasoning
↓
1 selected tool
↓
Execution
Or even:
100 tools
↓
Jev
↓
20 relevant tools
↓
Jev
↓
3 candidates
↓
LLM
↓
Final selection
This is particularly interesting for MCP-based agents, where the number of available tools can grow rapidly.
The Jev project ecosystem already includes examples of discrete tool pruning and routing for large tool catalogs.
Why not just use rules?
A fair question.
We could write:
if "login" in request:
use_wazuh()
elif "endpoint" in request:
use_edr()
elif "ip" in request:
use_ip_reputation()
This works initially.
But enterprise requests are rarely that clean.
Consider:
"A user logged in from an unusual location and shortly afterwards accessed a sensitive server. Can you investigate?"
Now the decision depends on the meaning of the request, not just keywords.
This is where a semantic decision model can be useful.
The application still owns the hard rules.
The decision model handles the fuzzy part.
Another important separation: Decision ≠ Policy
I think this is one of the most important architectural ideas.
Don't do:
Jev says BLOCK
↓
Immediately block the IP
Instead:
Jev
|
Risk = HIGH
|
v
Policy Engine
|
+---------+---------+
| |
Allowed Approval
| |
v v
Execute Human review
The model provides a decision signal.
The application provides the policy.
That makes the system easier to audit and control.
The same architecture works outside cybersecurity
Once you see the pattern, many use cases appear.
Customer support
Customer message
↓
Decision
↓
Billing / Technical / Sales / Security
Model routing
User request
↓
Decision
↓
Small LLM / Coding LLM / Reasoning LLM
RAG
50 retrieved documents
↓
Decision
↓
Top relevant candidates
↓
LLM
AI governance
AI wants to perform an action
↓
Risk decision
↓
Low risk → execute
High risk → human approval
DevOps agent
Incident
↓
Decision
↓
Logs / Metrics / Kubernetes / Cloud / Database
The common pattern is:
LLM for reasoning.
Decision model for bounded choices.
Code for execution.
Policy engine for control.
The architecture I find most interesting
For an enterprise AI platform, I would consider:
User
|
v
AI Agent / LLM
|
Understand task
|
v
+----------------+
| Decision Layer |
| Jev |
+-------+--------+
|
+------------+-------------+
| | |
Routing Risk Tool
Decision Decision Selection
| | |
+------------+-------------+
|
v
Policy Engine
|
+------+------+
| |
Allow Approval
| |
+------+------+
|
v
Tool / API
|
v
Result
This gives us something different from simply putting an LLM in front of every API.
It gives us a decision architecture.
The bigger question
I don't think the interesting question is:
"Can Jev replace an LLM?"
That's the wrong comparison.
The more interesting question is:
"Why should a large generative model make every small decision inside an AI agent?"
For complex reasoning, keep the LLM.
For bounded decisions, routing, scoring, classification and verification, a specialized decision layer may be a better architectural fit.
That separation could become increasingly important as AI agents move from simple chat interfaces to systems with hundreds of tools, APIs and autonomous workflows.
I'm currently exploring this architecture:
LLM → Decision Layer → Policy → Tools → Execution
rather than:
LLM → Everything
And I think this is a pattern worth experimenting with.
