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.

AI #AgenticAI #LLM #AIAgents #MCP #AIArchitecture #Cybersecurity #GenerativeAI #Automation #Jev