VOGO® eBS AIAO
You draw the process, decide who gets what and by when, and the rest runs by itself — with people, systems and AI agents in the same flow.
EUIPO EUTM 019103505VOGO® eBS AIAO — Enterprise AI Automation and Orchestration is the platform through which an organisation puts its processes to work: the internal request, the approval, the contract, the petition or the invoice follow the same path, drawn once, and every step knows who carries it out, within what time and on the basis of which data.
People, systems and AI agents work in the same flow. One step asks for a signature, another queries an external system, another lets an agent read the document and propose the reply. Whatever is not certain goes up to a person, with everything the agent proposed next to the decision.
One drawn process. The same rules for everyone. Nothing lost between two steps.
Steps are dragged from the palette onto the canvas: triggers, control — decision, parallel branch, join, wait, sub-process —, tasks for people and system operations. The flow has versions, is validated before publishing and is exported to BPMN 2.0.
Classifying the document, extracting the data, summarising, drafting the reply and signing electronically are steps like any other. When the agent is not certain, the step goes to a person — the decision stays where it belongs.
Text, numbers, dates, choices, a table with its own columns, signature, map, file. Every field has its own width on the row and a stable code under which its value is read further on in the process. A form has a draft, a published version and an archive.
A task step receives the form a person fills in, and the data goes straight into the process variables. There is no second place in which to keep the same fields.
The theme changes with one button, for each user. The same fields, the same properties, the same layout — only the contrast changes, for the eye that spends all day in the application.
Where the process takes shape: steps are dragged from the palette, linked to one another and configured in the panel on the right. Nothing that follows requires code.
Every flow has its own versions; one is in progress, another is published.
The flow is checked before publishing, and anything that cannot start is flagged on the spot.
The definition is exported to BPMN 2.0, the standard format for processes.
A process goes live only once it is published, not while it is a draft.
The form is where the process receives its data. It is made of fields dragged onto the canvas, each with its own properties, without a line of code.
Single-line text, paragraph, drop-down list, multiple choice, checkbox, numbers, name, e-mail, phone, address, map, date and time, time, hidden field, rich text, HTML, camera, signature, CAPTCHA and table.
You say in words what the person has to fill in — “leave request: period, leave type, number of days, replacement, remarks” — and the agent proposes the fields, with the type and label of each.
The form is worked on without affecting the processes that are running.
The version people fill in within their tasks.
A form taken out of use remains, for the older records.
Font and colours inherited from the application or set per field.
Every item below is a step type or a property you configure in the designer, not an intention on the roadmap.
Start, end, decision, parallel branch, join, wait and sub-processes. Conditions are evaluated on the server, and the engine chooses the next step.
Task with a form, approval and assignment. A task goes to a person, a group, the head of a unit or the initiator’s unit.
Every task has days until due, a warning threshold and the calendar by which days are counted — working or calendar days.
Classification, data extraction from a document, summary, content generation, with escalation to a person when the answer is not certain.
HTTP request, sending e-mail, register number, document generation, electronic signing, archiving and setting values.
Roles and rights, audit log, idempotent retries and tenant isolation. The flow runs locally, with no dependence on an external service.
Every flow has its own versions; one is in progress, another is published.
The flow is checked before publishing, and anything that cannot start is flagged on the spot.
The definition is exported to BPMN 2.0, the standard format for processes.
A process goes live only once it is published, not while it is a draft.
An approval flow moves a document from one person to another. Orchestration holds people, systems and AI agents together: one step asks for a signature, another queries an external system, another lets an agent extract the data from a document, and the process knows at any moment where each instance is.
No. Steps are dragged from the palette, conditions are written as rules and forms are made of fields. Code is left for special cases, not for everyday work.
It is chosen when the step is defined: a person, a group, the head of a unit or the unit of whoever started the process. Assignment follows the org chart, so it does not have to be rewritten with every staff change.
The step escalates to a person. The agent proposes, the person decides, and the decision stays in the process log next to what the agent proposed.
Yes. Definitions are exported to BPMN 2.0, the standard format for business processes, and every published version stays in the history.
It runs wherever the organisation chooses, including entirely on premises. The engine needs no external service to execute a process.
In a demo we start from a process you already run on paper and draw it together: the steps, who gets what, the deadlines and the points where AI takes over the repetitive work.
VOGO® eBS AIAO
Part of the VOGO Enterprise Business Suite · runs on premises too, with no dependence on an external
service.
Note: The services are provided in line with the European DNSH principle – “Do No Significant Harm”, in accordance with Article 17 of Regulation (EU) 2020/852 on the establishment of a framework to facilitate sustainable investment and with the European Commission’s technical guidance on the application of the DNSH principle, C/2023/111.
