What layan.ai is actually for.

Why lumina exists, what it changes underneath, the use cases layan.ai runs for the example client tenants testing it, and what it builds on top of Laya and Jev — the decision layer underneath every agent, not the language model.

Why lumina

Freedom from one model, and from a harness that waits on your laptop.

lumina exists because tying a company's agents to one model provider, and to a harness that only runs as fast as somebody's laptop, is a business risk layan.ai chose not to carry. The harness registry already tries Layan's own Hermes, then Nous Portal, then OpenRouter, first answer wins — so no single provider's outage or price change can stop a company's agents from working. lumina takes that same freedom one layer deeper, into the runtime itself.

It would have been easy to stop at a dockerized, stripped-down Hermes running in an isolated container per company, and call that the product. lumina does more than isolate: both Hermes and the harness around it are tweaked for faster adaptation and better decision-making, not just containment. Before the language model is even asked — and often while it is still generating — every action a company's agents consider first passes through a typed decision: intent, routing, risk. That decision is answered by the Jev runner, the hosted decision engine layan.ai runs (Laya-compatible: it speaks the same typed-question wire protocol as the open-source Laya project), in the tens of milliseconds it takes to say yes, no, or which one. A hedged fast lane races a quick-tier provider against the primary one and keeps only whichever answers first. Speculative intents read the assistant's own reply stream as it forms and let the interface, and the tools it will need, warm up before the sentence is finished. None of this lets a prompt raise its own limits: policy sits outside the model, in the gateway and in the container, exactly as it does today without lumina.

Because no model — chat, voice, transcription or decision — ever runs on the container itself, the container a company runs on does not need to be a machine built for AI. It only has to reach the hosted providers over the network, which is what lets lumina put a company on something as small as a micro VM and still hand it a complete AI operating stack: Hermes, the decision layer, the browser pool and the policy engine, with the language model itself living entirely in the cloud.

lumina is priced as a subscription benefit, not a separate purchase: after three months of continuous subscription, every rate on the account — the platform fee and the credits it buys — is discounted by 10 percent, for as long as the subscription stays continuous.

Read the full lumina story →

The lumina architecture enhancement

One container per company, nothing shared that shouldn't be.

This is the buyer-facing version of a longer engineering blueprint. Nothing below is a promise of what a prompt can do — it is what the platform enforces around the prompt.

One container per company. Hermes, its tools, its memory and its browser pool all live inside a container that belongs to exactly one company — filesystem, secrets, database, browser profiles, task queue and spending limits, none of it reachable by another company. A brand lives inside its parent's container; a brand gets a dedicated container of its own only on the isolation tier, and the account that pays stays the parent company.
A managed memory service. When a company turns memory on, chat history, key points and agent notes are extracted, deduplicated and scoped per agent and per company by lumina's memory service, and they survive a shutdown. It is off by default: a company that hasn't purchased it keeps working exactly as before, it just doesn't keep chat memory between sessions.
Heartbeat, archive and restore. While anyone has the company open, the browser sends a heartbeat every 30 seconds and the container just keeps running. After seven days with no heartbeat, the session is archived, not ended — everything that can be saved is saved first, the cache is cleared, and the very next heartbeat restores it, instantly, with nothing under the archive ever deleted. Shutdown, behind a warning, stays the only way to end a session immediately instead of waiting out that window.
The Browser Control Center. Every company gets its own browser pool, and every browser in it its own disposable profile — cookies, logins and permissions never shared across companies or, unless policy says so, across agents. The default view is frames over the same SSE stream that already carries chat; a person can take control of a live session on demand and hand it back.
The panel. One screen, in every company's own dashboard, showing container status, CPU, memory and disk against the plan's limits, the browser pool, Hermes reachability, the task queue and the company's own usage ledger — sourced from the runtime's own stats stream, not modelled, and shown as unknown when the runtime can't report it.
layan.ai request path The agent gateway receives a request, the policy engine decides, and only then does the request reach one company's own container, holding Hermes with MCP tools and the browser pool. Agent gateway auth · routing · usage ledger · audit Policy engine allow · block · needs approval One company's container its own filesystem, secrets, database and task queue Hermes agent runtime MCP tool gateway Browser pool per-profile, disposable

Every request reaches the gateway, then the policy engine, before it ever reaches a company's container — and once inside, it stays inside that one company's Hermes, tools and browser pool.

Said plainly

  • No AI runs locally, anywhere — not on the container, not on a laptop, not at layan.ai. Every model, voice, transcription and decision call goes through a hosted provider and lands on the usage ledger.
  • lumina is built last, on purpose. The policy engine, identity and the shared gateway have to exist before a container has anything to enforce or anyone to belong to.
  • Until lumina is switched on for a workspace, every lumina-only route and page — the Browser Control Center, the panel, the fast lane — stays locked and says so, rather than pretending to work.
Before anything else

Use cases from client companies.

layan.ai is tested against real workloads on a handful of example client tenants, shown here as the cards below. Bluprise is an example client testing it as a product studio and agency, BluBeds is an example client testing it as a corporate-travel company under a real workload, eLearn is an example client testing it with the strictest policy pack, and the agencies these clients bring on run their own referral tree on the same ledger. No invented metrics: a card says what policy allows without a person, and what always waits for one.

Company
Module

Showing 14 of 14

BlupriseSalesMarketingBrowser

Qualifying exhibitors at a trade show

A Research agent works the browser pool to find companies exhibiting at a trade show, qualifies them against the target list, and hands off to the Sales agent for outreach, tracked on the Marketing calendar.

Agents / modulesResearch agent (browser pool) · Sales agent · Marketing calendar
Without a personReading company sites and directories, and drafting outreach — visible, not sent.
Waits for approvalSending, within the daily limit; duplicate contact blocked for 30 days.
researched findings sourced from the browser pool
BlupriseSocialAdsMarketing

A client launch across three channels

The Content agent drafts a launch campaign for a client's product; the Social scheduler proposes posts for LinkedIn and X, and the Ads module reads performance on Meta and LinkedIn campaigns connected over MCP.

Agents / modulesContent agent · Social scheduler · Ads (Meta, LinkedIn over MCP)
Without a personDrafting posts, and reading ad performance.
Waits for approvalEvery post and every send; any ad budget change is High risk and waits too.
observed ad performance read directly from the platform
BlupriseDevSales

Auditing a prospect, then proposing

The Frontier audit and the CTO agent read a prospect's website and public repository, then the findings become a draft proposal the Sales form can send.

Agents / modulesFrontier audit · CTO agent · Sales form
Without a personReading — GitHub access stays Contents, read-only, on purpose.
Waits for approvalThe proposal is a draft until a person sends it.
observed findings from the repository and the live site, dated
BlupriseSupportPolicyUsage

Serving BluBeds as an internal agency

Bluprise's own Research agent is exposed to BluBeds as a granted MCP capability, so a BluBeds agent can ask Bluprise's agent for research without either company touching the other's data directly.

Agents / modulesResearch agent, exposed as an MCP capability · cross-company grant
Without a personCalls within the grant's own rate limit; results come back source-tagged.
Waits for approvalThe grant itself, to exist in the first place; either company can revoke it any time.
researched, with source; booked on both companies' ledgers
BlupriseAgenciesMarketingUsage

Tracking affiliate campaigns for the agencies Bluprise signs

Referral links and campaign windows for the agencies Bluprise brings on live on the Marketing calendar, next to Bluprise's own campaigns.

Agents / modulesAffiliate module · Marketing calendar · referral links
Without a personReading and reporting the campaign funnel.
Waits for approvalNothing here pays out automatically — commissions move through their own state machine, approved and scheduled for the 15th, never sent on the spot.
estimated until a commission clears the refund window, then observed off the ledger
BluBedsSalesBrowserSupport

Six rooms in a city, next month

A corporate client asks for six rooms; the Sales agent opens the quote task card at first intent, the browser pool reads live rates on hotel sites, and Support context is on hand if the client already has an open ticket.

Agents / modulesSales agent (quote task card) · browser pool on hotel sites · Support context
Without a personReading rates.
Waits for approvalSending the quote is Medium risk and logged; booking or paying is Critical and always waits for a person.
observed rates read live from the hotel site, timestamped
BluBedsSupportPolicy

A date-change ticket arrives

A traveller's date-change request lands as a ticket; the Support agent already has the booking on screen through the observed-context capability, and Laya routes it and scores the risk in the same pass.

Agents / modulesSupport agent · Laya (routing, risk scoring)
Without a personDrafting the change request.
Waits for approvalThe change itself is High risk and waits for the CS person; routing and scoring are typed decisions, never a reason to act on their own.
observed booking on screen, tagged by the sidecar's allowlist
BluBedsSalesMarketing

Weekly hotel partner outreach

The Sales agent drafts weekly outreach to hotel partners for new corporate rates, scheduled on the Marketing calendar, under the communication policy.

Agents / modulesSales agent · Marketing calendar · email
Without a personDrafting, and reading partner data.
Waits for approvalSending stays inside the policy pack's own numbers — 50 a day, 3 follow-ups per contact, 45 seconds between actions — and a person still approves the campaign as a whole.
observed counters that survive a restart, shown on the Policy page
BluBedsSupportUsage

"What did we spend on hotels in Riyadh this quarter?"

A client dashboard question, answered by the Support agent from the client's own authorised context only.

Agents / modulesSupport agent (authorised client context)
Without a personReading the client's own data and answering.
Waits for approvalNothing to approve — but anything outside the client's own data is marked unknown, not guessed.
unknown for anything outside the client's authorised data, said plainly
BluBedsAdsMarketing

Ads for the corporate travel offer

The Ads module reads performance on BluBeds' Meta and Google Ads accounts, connected over MCP, and the Marketing agent proposes changes.

Agents / modulesAds module (Meta, Google Ads over MCP) · Marketing agent
Without a personReads: campaign performance, spend, audiences.
Waits for approvalBudget and campaign writes are High risk, into the approvals queue with why, what, impact, cost and risk attached.
observed spend and audience data, read directly from the platform
BluBedsPolicyUsage

Asking Bluprise for industry research

BluBeds asks Bluprise's Research agent for research on a target industry, through the same cross-company MCP grant Bluprise offers.

Agents / modulesCross-company MCP grant
Without a personCalls within the grant's rate limit.
Waits for approvalThe grant itself, both ways — either company can revoke it any time.
researched; both ledgers booked, credits on the caller, zero-credit record on the provider
eLearnPolicySupport

A curriculum session, gated end to end

The learning-agent, playground-agent and parent-agent run a child's session inside eLearn's own container, against a curated curriculum and a curated video library, behind an allowlist that runs age, curriculum, content safety, voice, time and parent, in that order, before anything is shown.

Agents / moduleslearning-agent, playground-agent, parent-agent · Policy (strictest pack)
Without a personPresenting content already inside the age and topic allowlist.
Waits for approvalAnything outside that allowlist — new topics, more time — is switched on only from the parent dashboard, never by the agent or the child.
observed time budget, kept on a server-side clock, not a browser timer
eLearnPolicySupport

"Tell a grown-up"

eLearn's input and output filters, and its red-team prompt set, exist to catch an unsafe or out-of-scope request before it reaches the child, with a "tell a grown-up" escalation and a parent transcript view behind it.

Agents / modulesPolicy (content safety, guardrails) · parent-agent
Without a personLogging the flag and giving the child a scripted, safe response.
Waits for approvalAnything past that scripted response goes to the parent transcript view — a person decides what happens next.
observed flag on the audit log; nothing about the child is inferred or guessed
AgenciesMarketingUsage

Commission, split by policy, not by hand

A company referred through the agency tree writes one immutable referral-attribution event at signup; every payment webhook then writes one commission row per ancestor in the tree, split by a fixed ceiling — 20 percent to the tree owner, 15 to a sub-affiliate, 10 to a sub-sub, 5 to a child — where each ancestor above the direct referrer earns only the difference between its own ceiling and the one below it, so total payout on any one company never passes 20 percent.

Agents / modulesAffiliate module · Marketing calendar (referral links) · Usage (commission ledger)
Without a personComputing the split and writing the commission rows automatically from the webhook.
Waits for approvalA commission only becomes approved after the refund window closes, and payout is always scheduled for the next 15th — never on the spot; a reversal writes a new row rather than deleting one.
estimated while pending, observed once eligible off the ledger
After ours

What layan.ai builds with Laya and Jev.

Laya is ConvAI Innovations' open-source decision engine, and madewithlaya.com is the community's own showcase of what people build with it — over a hundred projects across support, security, moderation, documents, routing, multilingual work and general tooling. The cards below adapt what that community demonstrates into what layan.ai's own company containers do with the same capability: a typed decision runs first, in tens of milliseconds, and the language model only ever sees what still needs prose.

Every quoted figure below is reported by the community on madewithlaya.com, not measured by layan.ai. Quotes are kept short and linked to their source.

Routing a BluBeds ticket before the model drafts

layan.ai's Support module puts a typed routing and risk decision in front of every incoming ticket — which queue, whose SLA, what risk level — in the tens of milliseconds before Hermes drafts anything, the same shape as swapping the decision engine under an otherwise unchanged triage agent.

152 ms for the Laya-routed pass against 422 ms through the full language-model path, on a 30-ticket comparison — at lower accuracy on that particular test (10% vs 53%), which is why layan.ai keeps Jev, not raw local Laya, as the default.

Reported by the community on madewithlaya.com.

A per-company intent set, not a generic one

The community fine-tuned a Laya checkpoint on the Banking77 dataset so it recognises banking-specific intents instead of generic ones. layan.ai's decision layer takes the same shape per company — BluBeds' own intents (date-change, refund, quote) rather than a one-size classifier — through Jev's typed-question interface.

Reported by the community on the build, via madewithlaya.com.

Eight decisions, one gateway pass

A single community demo runs email triage, phishing detection, guardrails, ticket routing, RAG filtering and multilingual routing side by side — close to the shape of what layan.ai's gateway already does before Hermes ever opens a message.

99.3% spam accuracy, 98% phishing accuracy, on the demo's own test set.

Reported by the community on the build, via madewithlaya.com.

Screening a query before an agent runs it

A community benchmark runs fourteen PostgreSQL statements, seven with deliberate bugs (a fan-out SUM, an = NULL, an UPDATE with no WHERE, injection remnants) past a typed decision with schema context. layan.ai's Dev module could run the same class of check before the CTO agent executes a query, the same way the policy engine already screens browser actions.

Reported by the community on the build, via madewithlaya.com.

Scoring an indicator before the browser visits it

A self-hosted console classifies IPs, domains and hashes from threat-intelligence data across several typed-decision engines. layan.ai's Policy module could score an inbound domain the same way before a browser task is allowed to open it, feeding directly into the company's own allowed-domains list.

Reported by the community on the build, via madewithlaya.com.

Checking tone and risk on inbound messages

A community build analyses a message's tone, formality and conflict risk in real time while it is being typed. That is the shape of the prompt-injection and moderation check layan.ai runs on inbound messages before an agent drafts a reply from them.

40–110 ms per call, as reported on the build's own test.

Reported by the community on the build, via madewithlaya.com.

Flagging AI-authored content before it's trusted

A browser extension scores social posts locally for AI-generated style. An inbound support inbox could run the same kind of typed check to flag likely AI-generated spam or phishing before a person or agent acts on it.

Reported by the community on the build, via madewithlaya.com.

Fine-tuning narrows the gap, but doesn't close it

A community comparison shows fine-tuning matters, and honestly, that it isn't enough on its own — which is exactly why layan.ai's moderation checks default to Jev, and only lean on a narrow fine-tuned model where testing shows it holds up.

Banking77: fine-tuned Laya went 51.3% → 79.4% on 1,001 examples; Jev scored 80.0% on the same set.

Reported by the community on the build, via madewithlaya.com.

Extracting fields from invoices and booking confirmations

A community benchmark demos and cross-compares seven zero-shot extraction and classification families, with size, licence and cost noted for each. layan.ai's Support and Sales modules parse booking confirmations, invoices and quotes the same way — a typed extraction decision, not a full model call, for every field.

Reported by the community on the build, via madewithlaya.com.

Knowing when to stop reading a long document

A community project measures how a decision model's attention drops off on long inputs, then chunks, screens and aggregates instead of reading everything at once. A long corporate-travel contract or policy document gets the same treatment: chunk, screen with the fast decision layer, escalate only the passage that matters to the language model.

Attention drop-off measured after roughly 200 tokens, across 400 documents.

Reported by the community on the build, via madewithlaya.com.

Routing extraction to Jev, honestly

An independent community re-run found Laya's advertised win over Jev didn't reproduce on general classification. It's why layan.ai's structured extraction defaults to Jev rather than raw Laya, and reserves the local-style approach for narrow, fine-tuned, in-domain decisions.

Jev 0.793 vs Laya 0.632 on one topic-classification set; a tie on another.

Reported by the community on the build, via madewithlaya.com.

Decisions to Jev, prose to the fast lane

A community router matches a much larger model's routing accuracy at a fraction of the latency and cost. That's the same split layan.ai's harness registry makes on every reply: the typed decision — which tool, which risk level — goes to Jev, and only the prose generation goes to a language model on the fast lane.

Matched accuracy, 35x faster, on a 180-request test, as reported.

Reported by the community on the build, via madewithlaya.com.

A cascade that resolves most decisions before the model is asked

A community stack runs rules, then Laya, then Jev, then a larger model, escalating only when confidence is low. layan.ai's policy engine and Jev run the same cascade shape: most routing and risk decisions resolve in the fast lane, and only the uncertain ones escalate.

85% at 27.8 ms on the fast tier; 14 of 20 test decisions resolved before reaching the slower tier at all.

Reported by the community, via madewithlaya.com.

Guardrails as a typed decision on every trace

A community library evaluates tool choice, grounding, scope, prompt injection and sensitive data in one typed request, runnable on every trace. It's the same idea behind layan.ai's own sensitive-field detection — password, card, CVV, IBAN, destructive verbs — which raises an action's risk level regardless of what the model said about it.

Reported by the community on the build, via madewithlaya.com.

Arabic and multilingual intent for the Gulf

A community checkpoint fine-tunes Laya for Arabic natural-language understanding on standard NLU benchmarks. BluBeds and eLearn both serve Gulf families in Arabic first, and this is the same shape of intent classification that runs ahead of the translation step in layan.ai's voice chain.

Reported by the community on the build, via madewithlaya.com.

Where a dialect still needs the fallback path

A community zero-shot test on informal Moroccan Arabic (Darija) sentiment is the kind of case layan.ai's own voice chain plans for: when the speech provider's own translation doesn't cover a dialect well, the transcript falls back to a hosted translation model instead, exactly as the wisp-only view for eLearn already does.

Reported by the community on the build, via madewithlaya.com.

Jev stays the default outside its trained languages

On a Japanese business-judgment benchmark, generic multilingual Laya trailed Jev by a wide margin. It's why layan.ai keeps Jev as the default typed-decision runner across languages, and only reaches for a Laya-class local approach where a checkpoint has actually been tuned for that language.

Jev 97.6/100 vs Laya (multilingual, FP16) 36.9/100, on a 40-question set.

Reported by the community on the build, via madewithlaya.com.

A Jev-compatible server behind every typed decision

A community library sends typed decisions to Jev, Laya, or an AI gateway behind one interface. layan.ai's own /api/decide route does the same fallback: Laya first, then the language model, then a heuristic, reporting which engine actually answered.

Reported by the community on the build, via madewithlaya.com.

A local decision-maker driving a browser agent

A community browser agent uses a typed decision model to drive Playwright/CDP navigation and clicks, drop-in for the same tooling layan.ai's own browser workers use. The Browser Control Center runs the same shape of decision per action — navigate, read, click, type — just hosted per company inside the container instead of on a laptop.

Reported by the community on the build, via madewithlaya.com.

Dependency-free runtimes, the same discipline as this stack

Several community ports run Laya with no Python, no torch and no BLAS dependency at all. layan.ai's own front end and API are dependency-free too — the decision layer keeps the same discipline as the rest of the stack it runs inside.

"No Python, torch, or BLAS dependencies," as reported on the build.

Reported by the community on the build, via madewithlaya.com.

Laya versus Jev. Laya is ConvAI Innovations' open-source decision engine: a small classifier, weights you can run yourself, free to fine-tune and free to run wherever you host it. Jev is the hosted runner layan.ai actually calls in production — the TypeSafe-built service behind decisionEngine: 'jev' in admin config, speaking the same typed-question wire protocol Laya speaks, so a company can be moved between them without touching a single agent. layan.ai defaults to Jev, not local Laya, because "no local AI, anywhere" is a decision taken for the whole platform, not just the language models — and because, as the community's own side-by-side benchmarks above show, Jev leads on most general classification and multilingual tasks, with Laya's edge showing up mainly on narrow, fine-tuned, in-domain questions. Either way, the reason the decision sits here at all, outside the model, is the same reason the policy engine does: a typed answer in tens of milliseconds is auditable, cheap and impossible for a prompt to talk its way around, which a paragraph from a language model never quite is.