In my previous post, I explained why we aren't adding Jev or Laya to the Cortrix core right now.
We don't think Jev or Laya should be responsible for finding candidates in Semantic Storage, the underlying system where semantic data persists. But give them an organized state, the relevant results, and a defined set of options, and they can do what they're good at: make a fast decision.
Retrieval and decision-making are different jobs. Putting a decision model inside storage doesn't give storage an understanding of the business. Put it in the Agent that uses Cortrix for a concrete business task, though, and Jev and Laya become interesting.
The diagram below shows the Agent workflow I have in mind.
Cortrix retrieves material first. The Agent combines those results with source information and current state from business systems into an evidence input. It then decides whether the evidence is sufficient, whether records conflict, and whether a problem calls for another lookup, a different route, or a human. Jev or Laya could help at each of these points.
These steps don't need another generated answer. They need a decision with a clear scope.
The refund hasn't arrived. Now what?
Suppose a customer contacts support again today. Last week they were told their refund had been processed, but the money still hasn't arrived. They're angry, want it fixed now, and say they'll file a complaint and take the story to the media if it isn't resolved.
This is no longer just a support ticket. The relevant information is scattered:
- What did support promise the customer last time?
- Is the refund status in the order system correct?
- Does the finance system show an actual payment?
- Which refund rules applied when the customer bought the product?
- What changed later, and are there precedents for exceptions?
- How were similar problems handled before?
The Agent uses Cortrix for semantic retrieval, then combines the results with current state from support, orders, finance, and policy into an evidence input. The retrieved material and business records supply what each item is, where it came from, when it happened, and how it relates to the issue. The Agent puts them in one context.
Then the conflict shows up.
Support says the full refund has been processed. The order system says a partial refund has been initiated. The finance record says the payment channel rejected the transaction. The process has started, and none of these records is wrong. They describe different stages.
If the Agent picks just one record and generates a reply, it can easily tell the customer, again, that the refund has been processed. The support record backs that statement, but the actual business outcome doesn't.
Cortrix's job is to retrieve relevant material. The Agent combines it with current business state into an evidence input. That is where Jev or Laya can help the Agent make its next decision.
First, the evidence has to be sufficient
The Agent shouldn't treat “I found something” as “I can answer.”
If I were designing the data structure for this refund, it might look like this:
state:
customer_promise: full_refund_processed
order_status: partial_refund_started
payment_status: rejected_by_channel
applicable_policy: original_purchase_policy
decision:
- evidence_is_sufficient
- more_finance_evidence_needed
- policy_owner_review_needed
- human_escalation_requiredJev or Laya isn't receiving an open-ended task like “solve the customer's xx problem.” It would receive what the Agent assembled from Cortrix retrieval results and business system state, along with the paths the Agent is allowed to choose.
That distinction matters. A decision model can flag insufficient evidence, but it can't invent a payment record. It can recommend escalation only if escalation is among the options it was given. A confident answer doesn't authorize it to approve a new compensation payment.
Evidence, permissions, and business facts stay in their existing systems.
Flag conflicts. Keep the evidence.
Many RAG pipelines try to end with one most relevant answer. That's a dangerous habit when something has gone wrong in a business process.
The support commitment, order status, and payment failure aren't interchangeable answers. Together, they describe the refund's path from commitment to execution to failure. Drop any one of them and the Agent gets only part of the story.
A better role for Jev or Laya is to annotate the candidates:
support:
- customer service marked a full refund as processed
conflict:
- order status says partial refund
- payment status says rejected
missing:
- no successful settlement recordThose annotations help the Agent organize its next step, while the original evidence stays intact. The decision model's output is an annotation, not an action that deletes other evidence.
This is the boundary between a semantic data layer like Cortrix and a decision layer. Cortrix retrieves relevant material, and the Agent keeps source information in the evidence input. Jev or Laya assesses what that evidence means for the action under consideration. The Agent can always return to the sources instead of seeing only secondhand information filtered by a model.
The refund failed. What should the Agent do next?
Back to the example: the refund Agent checks the payment channel again, and the transaction is still rejected. It has several possible next steps:
choice:
- retry_same_channel
- use_authorized_fallback
- ask_finance_owner
- escalate_to_humanThis is a useful place for a typed decision. The business workflow and permission system have already defined the candidate paths. Jev or Laya only needs to assess which one fits the current state. Code still enforces the hard limits: how many retries the same channel allows, whether a fallback is available for this order, and which amounts require human approval.
The model handles the ambiguous judgment. Code holds the boundaries that can't be ambiguous.
Cost savings have to show up across the whole workflow
A cheap call doesn't automatically make the whole Agent workflow cheaper. Jev can be called as a lightweight service, and Laya can run locally. But if the Agent has already done several retrieval rounds, called an LLM, and written the reply before asking Jev whether that reply can be used, the expensive work has already happened.
The useful decision points come earlier:
- Before generating a customer reply, check whether the evidence is sufficient.
- Before querying the same system again, decide whether to take another route.
- Before entering an automated compensation path, flag conflicts and route the case to human approval.
- Before running more enrichment, identify the specific kind of evidence that is missing.
The decision cost plus the fallback cost has to be lower than the work this layer actually avoids. That's how we can show a net benefit to the system.
The benefit is more than an API bill. Pointless retries consume customer patience. A wrong route can create rework. Premature generation can turn conflicting evidence into a reply that sounds certain even though the evidence isn't sufficient. Helping the Agent avoid one wrong round and handle the business problem correctly matters more than saving tokens.
Jev and Laya put the runtime boundary in different places
In this architecture, Jev and Laya could sit behind a common DecisionProvider interface. The two options imply different operating models.
Jev is the hosted path. The Agent sends the prepared state and candidates to a service and receives a choice, score, or another typed decision. The team doesn't have to run the model. Network behavior, service availability, and the data boundary become part of the system instead.
Laya is the local, open-weight path. The team can keep the evidence input in its own environment and manage inference resources, versions, and fallbacks itself. It also takes responsibility for model loading, runtime cost, language performance, and maintenance.
Cortrix doesn't need to make that choice for the Agent.
The more natural interface starts with the Agent organizing Cortrix retrieval results and business system state into a consistent evidence input. The Agent can then use Jev, Laya, ordinary rules, or a generative model according to its latency, privacy, cost, and operational requirements.
Different providers can evaluate the same business state, but they must receive the same evidence and options and remain subject to the same permission constraints. That makes the decision layer replaceable, instead of turning it into a second set of business facts hidden inside the Agent.
How Jev and Laya fit into the Cortrix ecosystem
Cortrix addresses how an Agent finds material relevant to its current problem in persistently stored information, while preserving a path back to the sources.
Jev and Laya address how an Agent can make a bounded decision quickly once it has the state.
The connection between them can be straightforward:
Cortrix retrieval results
+
business system state
↓
Agent-built evidence input
↓
DecisionProvider
Jev / Laya / rules / LLM
↓
Agent policy and state machine
↓
business action or human reviewCortrix doesn't approve actions on behalf of business systems. Jev or Laya doesn't recover facts Cortrix failed to retrieve. The Agent doesn't turn probability into permission. That lets ordinary code stay simpler: it enforces the business boundaries without encoding every ambiguous judgment in an ever-growing pile of if statements.
My previous post was about why Jev and Laya don't belong inside the Cortrix core.
This one is about where they belong once they're outside it.
I'd put Jev or Laya after the Agent has received Cortrix's retrieval results and assembled its evidence input, but before it takes action.
Public references: