Ollaya Ships Open-Source Decision Models

A product team can ask a large generative model to make every small call: whether a ticket needs escalation, whether a request matches a policy, whether a user belongs in a campaign. It works, until the decision layer becomes the expensive part of the product. The mistake is treating every decision as a writing problem. The better frame is to give routine decisions their own model and keep generation for the work that actually needs it.

That is the opening behind *Ollaya*, which released an open-source alternative for Ollama-style deployment of typed decision models on September 25. Ollaya describes the offering as Jev-style models, giving open-source product teams primitives for cost-optimized decision layers separate from generative models. The important shift is architectural, but the first consequence is practical: a team can consider a decision component without automatically attaching it to a larger generative model.

Give decisions a boundary

“Typed decision model” sounds more technical than the product question it answers. A type is a defined shape for an input or output. In a familiar product flow, that could mean taking a support request and returning a constrained decision such as “escalate” or “do not escalate,” rather than producing an open-ended explanation. The point is not that every workflow should become a binary switch. It is that some workflows need a reliable decision surface, not a conversational answer.

Ollaya’s release matters because that surface is now presented as an open-source, deployable primitive rather than an inseparable feature of a generative system. The evidence is deliberately modest: the launch site announces the open-source Jev-style models and the Ollama-style deployment alternative. Nobody outside the project should infer performance, coverage, or production readiness from that announcement alone. But product teams do not need those claims to see the design opportunity.

The opportunity is to split the product’s AI budget by job. A generative model might draft a reply, summarize a case, or help a user explore an unfamiliar problem. A decision layer might determine which path the product takes next. Keeping those roles separate lets a team ask a sharper question during planning: does this step need generation, or does it need a typed decision? That question is more useful than choosing one model for an entire workflow and hoping its cost and behavior fit every step.

The useful unit is not the biggest model in the workflow, but the smallest model that can own the decision.

Start with the cheap call

For a PM, this does not mean adding “model architecture” as a new research track. Start with one workflow where the product already knows the possible outcomes. Write down the decision in plain language, then define the result the rest of the system needs. If the next step only needs a route, a category, or an approval state, that is a candidate for a decision layer. If the next step needs judgment expressed in prose, keep the generative model in the loop.

The next question is ownership. A separate decision model should have a clear job in the product map: which input it receives, what decision it returns, and where that decision hands off to the rest of the experience. This is useful even before implementation. It exposes where a team is paying for open-ended generation simply because the model is already available, and where a supposedly simple decision has hidden ambiguity that needs discovery first.

Open source changes the conversation again. The team is not limited to treating the decision layer as a black box inside a larger model experience. It can evaluate the primitive as part of its own stack and decide where accessibility and cost matter most. Ollaya’s announcement does not provide the numbers needed to estimate savings, so a business case would be premature. The product case is clearer: separating decisions from generation creates a place to measure those costs instead of letting them disappear inside one broad model call.

I would put this on Monday’s planning agenda as a small exercise, not a platform initiative. Pick one high-volume workflow. Mark each AI step as either a decision or generation. For the decision steps, specify the allowed output before discussing vendors or model size. Then measure what the product actually needs from that step. Ollaya gives teams an open-source starting point for that separation, and the sharpest benefit may be the discipline it introduces: make the cheap, constrained call first, and reserve the expensive, expressive one for when the user truly needs it.