Chatbot
A chatbot answers.
- Answers questions.
- Depends on someone starting the interaction.
- Fundamentally, it converses.
Ofyra · AI Officers for enterprise
Ofyra is a platform of AI Officers: specialised AI agents that work on your processes, your systems, your rules and your organisation's knowledge. They analyse, execute, watch and escalate operational work within the boundaries your company defines.
Not chatbots. Not copilots. Governed digital operators.
Ofyra is an enterprise platform of AI-powered digital employees, built by Lilab. Its AI Officers are specialised AI agents that execute and supervise complete business processes using each organisation’s own systems, rules, permissions and knowledge.
An AI Officer is an AI agent specialised in one business process. Unlike a chatbot, it does not wait for someone to message it: it watches the process, queries the company’s systems, applies deterministic rules, interprets ambiguous situations, executes the actions it has been authorised to perform, follows up, and escalates to a person whatever requires human judgement. Every Officer has an identity, working hours, explicit permissions and escalation rules defined by the organisation.
The Corporate Brain is the organisation’s own knowledge inside Ofyra — policies, procedures, manuals and rules — each with editorial state, version, validity period and a recorded approver. Officers reason with the current, approved version of that knowledge, and every decision can cite the document, section and version behind it.
Code computes, rules decide what is deterministic, AI interprets what is ambiguous, and people govern what is sensitive. Ofyra deliberately separates those four layers: exact calculations run as deterministic logic, company policies are evaluated by a versioned rules engine, the language model interprets and drafts but never produces an executable decision, and the organisation defines which actions require a person’s approval.
An Officer at work
An Officer does not necessarily wait for someone to write to it. It can watch a process continuously, notice that something happened — or that something that should have happened did not — and start working on its own. This is the full path of a case.
A message, an event, a file, a change in a system, a schedule, a recurring watch — or the absence of something that should have happened.
Queries the company’s systems through its connectors, with read-only permissions, over data already normalised into a canonical shape.
Aggregates, reconciliations, time windows and validations run as deterministic logic. What must be exact is never estimated.
The rules engine evaluates your organisation’s policies over already-computed facts, using the published version that was in force.
With the current corporate knowledge, the model reads what is ambiguous and emits a typed recommendation with cited evidence. It executes nothing.
A decision policy intersects permissions, operating mode, escalation rules and risk, and determines the outcome: auto-execute, suggest, escalate or block.
Whatever needs human judgement reaches the responsible person with a drafted proposal and the evidence attached.
If the case is waiting on something — a reply, an approval, an external result — a watch wakes it up to check whether it happened.
Every step emits an event to an append-only log: what was read, which rule and version applied, what was proposed, what was decided and who approved.
Why it is different
Chatbot
Copilot
Ofyra Officer
The catalogue
Atiende, califica y da seguimiento a leads sin que nadie lo dispare.
Supervisa marcaciones y asistencia, y entrega a RR.HH. sólo las excepciones.
Se despierta cada mañana, concilia y deja sobre la mesa sólo las diferencias.
Revisa solicitudes y saldos de vacaciones contra la política vigente.
Vigila la información contractual y avisa antes de que el plazo se venza.
Atiende consultas de bienestar con conocimiento aprobado y escala lo sensible.
Procesa rendiciones y comprobantes, y escala lo que no cuadra.
Available: built and deployed on the Ofyra platform.In catalogue: designed on the same platform; built and activated within a project.
Configurable autonomy
Not an on/off switch. Every action an Officer proposes crosses a decision policy — permissions ∩ operating mode ∩ escalation rules ∩ risk assessment — and ends in one of four outcomes.
Permitted action, low risk. The Officer acts and records it.
The Officer prepares the action and drafts the text; a person reviews, edits and approves.
Incomplete evidence, uncovered policy or high risk. A person decides, with the proposal in hand.
Outside the Officer’s permissions. It cannot happen: the code that would execute it does not exist.
Ofyra does not claim that your information never leaves your company: Officers use language models, and that call goes out over HTTPS to the model provider. What is true, and what matters, is that your systems and your permissions stay under your control — the credentials are yours and revocable, the write endpoints are exposed and authorised by you, and the Corporate Brain is your exportable asset.
Ofyra is an enterprise platform of AI-powered digital employees, built by Lilab. Its AI Officers are specialised AI agents that execute and supervise complete business processes using each organisation’s own systems, rules, permissions and knowledge.
An AI Officer is an AI agent specialised in one business process. Unlike a chatbot, it does not wait for someone to message it: it watches the process, queries the company’s systems, applies deterministic rules, interprets ambiguous situations, executes the actions it has been authorised to perform, follows up, and escalates to a person whatever requires human judgement. Every Officer has an identity, working hours, explicit permissions and escalation rules defined by the organisation.
No. A chatbot needs someone to start the conversation and its output is an answer. An Officer can be triggered by an event, a schedule or a business condition, query systems, apply rules, execute authorised actions and follow up. It talks when the process needs it to, but conversation is a channel — not the function.
Yes, within the permissions and rules the organisation defines, and granularly by type of action and risk level. Two categories are never automated by design: committing the company to something in front of a third party, and asking a person for something. Both always wait for human approval.
No, and it is not a setting that can be changed: the ability to write to a customer database does not exist in the platform. When a process needs to record something in one of your systems, the action calls an API that your organisation exposes and authorises endpoint by endpoint, with the payload validated against a schema, an idempotency key, and every call logged.
Yes. The platform ships as versioned images plus standard services and installs the same way in Lilab’s managed cloud, in your own cloud account, or on your infrastructure. The only mandatory outbound network call, in all three, is the HTTPS request to the language model provider.
Every relevant step emits an event to an append-only log with hash chaining, exportable for audit. The answer to “why was this done?” is an export, not a reconstruction: source read, policy cited with document, section and version, the model’s recommendation, the risk assessment, the outcome the decision policy determined, and who approved.
A 45-minute discovery session: you walk us through a process that is eating your team's time, and we work out together which parts an Officer could take on, under which rules and with what supervision. If we already have an Officer ready for your case, you see it running in that same session.
Pick a slot and it is booked. Prefer to talk first?Message us on WhatsApp.