SenAi
What SenAi is and what it is for
SenAi is a system under development for collaboration between people and artificial intelligence agents, intended to carry out knowledge-based tasks and processes. It combines AI models’ reasoning with persistent data, recorded operating rules, execution tools and user control.
Its purpose is to take a task from an identified need to a verified result: establish what needs to be done, gather the necessary information, prepare a course of action, perform authorised operations and present the outcome together with an account of the work.
The fundamental idea behind SenAi is to reverse the traditional approach to implementing information systems. Rather than people learning to operate a system and adapting their processes to it, SenAi learns from people: their ways of working, knowledge, experience and the rules governing their organisation.
A system that learns about the enterprise
SenAi is installed in an initial form, without knowledge of the enterprise, its organisational structure, documents, products, customers or business processes.
This knowledge is acquired gradually during everyday use.
Employees perform their regular duties in collaboration with AI agents. Through this collaboration, SenAi learns about tasks, documents, dependencies, procedures, decision rules and ways of solving problems.
The system does more than store information. Its role is to recognise its meaning, relationships and potential for reuse. Acquired knowledge is recorded, verified and made available for subsequent tasks.
In this way, SenAi gradually becomes an electronic representation of the enterprise — its knowledge, processes, experience and ways of operating.
This is neither a static database nor a model of the organisation prepared just once. It is a structure that develops alongside the enterprise’s activities, incorporating new information, organisational changes and employees’ experience.
SenAi is therefore not a ready-made electronic model of an enterprise. It is a mechanism that gradually builds such a model through everyday collaboration with people.
Processes developed during work
One of SenAi’s central design principles is the ability to create business process scenarios while those processes are actually being carried out.
In a traditional approach, implementing a process requires prior analysis, documentation, solution design, software development and testing.
In SenAi, the starting point is the user’s actual work.
An employee carries out a task with AI agents, explains decisions, identifies required information and approves subsequent actions. The system analyses the workflow and recognises recurring activities, dependencies and operating rules.
It can use this information to propose a process scenario which, once verified and approved, can be reused for similar tasks.
A process scenario need not be created before work begins. It can emerge while the work is being performed, based on employees’ actual experience.
Across successive executions, SenAi can recognise deviations, identify opportunities for improvement and propose changes to existing scenarios.
Every employee can participate in developing the system in this way. An accounting employee contributes knowledge of accounting processes, a salesperson of sales processes, and a logistics specialist of logistics processes. This does not require programming skills or knowledge of SenAi’s internal architecture.
Radically reducing process implementation and maintenance costs
Implementing SenAi does not require taking employees away from their daily duties for lengthy interviews, process descriptions and analytical documentation, followed by programmers translating that documentation into code, testing it and correcting the software.
SenAi learns processes while they are actually being carried out. Employees perform their regular tasks while the system, working with them, gathers knowledge about workflows, decisions, documents and applicable rules. It uses this knowledge to prepare scenarios that can be reused after approval.
This approach is intended to radically reduce the time and cost of analysing, implementing and subsequently maintaining business processes. It also reduces the enterprise’s dependence on large teams of analysts, programmers and testers.
Crucially, SenAi is intended to recognise process changes during everyday work.
If an employee begins carrying out a task differently from the existing scenario, the system can detect the deviation, establish its cause and propose an update to the process.
Once the change is approved, the new scenario becomes available to other authorised SenAi users. There is no need to organise lengthy workshops again, recreate documentation from scratch or commission code changes, provided the change is within the capabilities of the existing execution tools.
As a result, the enterprise and its electronic representation in SenAi can develop in parallel. Changes in the real organisation can be continuously recognised, verified and reflected in the system.
In traditional systems, a business process change often requires a software change. In SenAi, it may primarily require updating knowledge and an operating scenario without modifying the system’s code.
This represents a move away from software that must periodically be adapted to a changing enterprise towards a solution that continually learns how the enterprise operates and can adapt its scenarios accordingly.
The economic benefits are therefore not limited to initial implementation. They also concern long-term maintenance, development and adaptation to changing business needs.
Collaboration between people and AI agents
SenAi is intended to serve both individual users and entire organisations.
One example is preparing a quotation using a customer enquiry, product documentation and company rules. In such a process, the system should identify requirements, flag missing data, use the appropriate template, prepare the document and obtain required approvals.
A similar approach can support analysis, documentation, project knowledge management and recurring tasks.
Work is divided among collaborating agents. ALEX interprets tasks and coordinates the work, GREG assesses the matter submitted for review, and MAJA carries out the agreed task.
Their actions follow recorded rules. The user retains control over the objective, scope and decisions requiring their consent.
The user does not need to know SenAi’s internal architecture or design algorithms. Their primary contribution is knowing how to do their work and providing the knowledge the system needs to support it.
Employees should not have to adapt the way they perform their duties to SenAi. SenAi should learn how those duties are performed and learn to support them.
Shared enterprise knowledge
Knowledge gathered by SenAi need not remain tied exclusively to the employee who contributed it.
Employees’ experience, problem-solving methods and knowledge of processes and operating rules can become lasting organisational assets.
Knowledge need not disappear when an employee leaves, changes position or the enterprise is reorganised.
Information acquired through tasks in one department can also be used elsewhere in the organisation, subject to appropriate permissions.
In this way, SenAi can gradually recognise cross-departmental processes, identify dependencies between departments’ activities and reconstruct workflows spanning the entire enterprise.
An important element of this approach is distinguishing information from binding rules. Not every statement contributed by an employee should automatically become an operating principle.
The system should account for the source of knowledge, its currency, its scope of applicability and potential conflicts with previously recorded arrangements.
Knowledge continuity and oversight
A central principle of SenAi is continuity of work. Data, agreements, scenarios and results should remain available beyond an individual conversation with a model.
Subsequent tasks can therefore use previously accumulated knowledge rather than reconstructing the entire context each time.
Knowledge acquired through one employee’s work can be used by others in the organisation, subject to appropriate permissions.
Another principle is traceability of actions. The system should distinguish an intended operation from its actual outcome, retain information about errors and stops, and make it possible to establish which data and rules underpinned a result.
This supports both oversight of task execution and analysis of errors and improvements to processes.
Improvement through experience
SenAi provides for improving its ways of working through experience gained during task execution.
After a task is completed, the system can analyse its course, recognise a change or deviation, establish its cause and prepare an improvement proposal.
Implementing such an improvement is subject to appropriate approval and verification rules.
SenAi is therefore intended not only to gather knowledge of how an enterprise operates, but also to use experience to propose increasingly effective ways of carrying out its processes.
The system can also identify recurring problems, unnecessary activities, inconsistencies in working practices and opportunities to improve cooperation between employees and departments.
Every completed task can therefore meet a specific business need while also providing new knowledge for improving the organisation as a whole.
Relationship to AToS
SenAi’s relationship to the Axiomatic Theory of Self-Consciousness (AToS) primarily concerns designing a system capable of recognising changes in its own operational state, identifying their origins and analysing the consequences of its own actions.
This is a direction for SenAi’s construction and research. Adopting this architecture does not in itself establish that the self-awareness criterion has been met.
Summary
SenAi is intended to be a system that learns about an enterprise through its everyday activities.
It starts without knowledge of the organisation and gradually learns its structure, employees, processes, documents, rules and experience.
This knowledge is not merely archived. It is intended to support subsequent tasks, the creation of scenarios for recurring processes and proposals for improvement.
The enterprise need not first describe all its processes in detail and then commission their implementation in software. Scenarios can emerge during everyday work, and changes can be recognised and implemented without involving software development teams on every occasion.
This approach is intended to significantly reduce the costs of implementing, maintaining and developing systems supporting business operations.
Employees should not have to learn SenAi. SenAi should learn from employees.
The enterprise should not have to adapt to an information system. The system should learn about the enterprise and develop alongside it.
This description presents SenAi’s purpose and design principles. Confirming the scope of implemented capabilities and the scale of economic benefits requires separate verification of the implementation and deployment results.
2. SenAi architecture in relation to AToS
SenAi’s architecture was designed with reference to the Axiomatic Theory of Self-Consciousness (AToS). It is based on describing a system’s operation through states, functions that transform them, stimuli, and mechanisms for recognising changes and attributing their causes.
Key AToS concepts include PAS (Potentially Aware Set), the imagination function ImFu, the inspiration function InspFu, the stimulus set StSe and the change-detection function Δ.
In SenAi, these concepts provide the conceptual foundation for an architecture that separates knowledge and operating rules, AI agents’ reasoning, technical execution of operations and assessment of their results.
The aim is to construct a system capable of using accumulated knowledge, conducting multi-stage tasks, recognising changes occurring during its own operation, analysing their causes and proposing improvements.
The mathematical definitions of AToS must be distinguished from their practical interpretation in SenAi. The theory provides a formal model, while SenAi attempts to apply its concepts in a real information system.
PAS — representation of states, knowledge and operating rules
In AToS, a PAS (Potentially Aware Set) describes a set of elements together with their assigned state values. A family of such objects forms the potentially aware space Ω, in which transformations and change recognition are considered.
In SenAi, the name PAS is used to organise persistent system resources, including operational knowledge, operating rules and task scenarios. This use is inspired by the theory; a PAS record in an information system does not automatically become a mathematical PAS merely by being given that name.
A process PAS can specify its objective, entry conditions, required information, decision rules, permitted operations and expected results. META-PAS describe higher-level rules, such as how scenarios are prepared, data acquired, communication conducted or changes approved.
For example, a quotation-preparation scenario specifies which information to gather, which documents to use, which conditions to check and when a user decision is required.
Process logic remains in PAS. AI agents interpret the recorded rules and select actions, while the execution layer performs technical operations. A new process can therefore be introduced by preparing and approving a scenario, without programming its business logic each time — provided the necessary execution tools are available.
InspFu — the inspiration function realised through an LLM
In AToS, the inspiration function (Inspiration Function, InspFu) concerns a transformation initiated by an external stimulus. In SenAi’s architecture, it is realised through a large language model (LLM).
Its role is to interpret stimuli originating outside the system, such as user instructions, documents, messages or information from other systems.
The LLM analyses the stimulus in the context of the knowledge accumulated in AToS-DB and the applicable PAS. It determines the information’s meaning, recognises the task and initiates appropriate transformations of the system’s operational state.
Not every piece of received information is an instruction to execute. The system must distinguish an authorised user’s request from source material and establish the permitted scope of action.
InspFu does not contain permanently hard-coded business logic. It uses rules and scenarios stored in PAS.
ImFu — the imagination function realised through an LLM
In AToS, the imagination function (Imagination Function, ImFu) concerns internally initiated transformations. In SenAi, it too is realised through an LLM.
Unlike InspFu, its operation is initiated by stimuli internal to the system.
The LLM uses accumulated knowledge, applicable PAS and the results of previous operations to analyse problems, formulate hypotheses, anticipate consequences, prepare solutions and initiate further transformations.
For example, while preparing a quotation, SenAi can recognise missing technical parameters, consult available sources, compare solution variants and prepare a question about missing data.
InspFu and ImFu need not be separate language models. They are distinguished primarily by the origin of the stimulus and the role played by the LLM in a given transformation. Actions remain constrained by the applicable PAS, permissions and required approvals.
StSe — PAS initiating internal processes
In AToS, StSe (Stimulus Set) denotes a structure serving as an internal stimulus for a state transformation.
In SenAi’s architecture, StSe form a particular category of PAS stored in the AToS-DB vector database. These PAS can initiate further internal processes by triggering an appropriate transformation realised through ImFu.
StSe are not merely information about the results of previous operations. They act as stimuli triggering subsequent actions.
For example, during document analysis, SenAi may recognise a missing required clause. An appropriate PAS serving as StSe can initiate a process to find the correct clause, check its currency and prepare a proposed addition to the document. That process’s result may in turn activate another StSe.
This creates a chain of internal processes in which one PAS can initiate the transformation of another without additional external stimuli.
Simply storing StSe in a vector database does not start a process. A mechanism must recognise and activate the appropriate StSe and pass it to the LLM realising ImFu. This distinction separates active process initiation from ordinary information retrieval in a RAG database.
Δ — recognising change
In AToS, the detection function Δ determines whether a change between the states under consideration has been recognised. In the formal model, it takes the form:
Δ : Ω × Ω → {0, 1}.
It is important to distinguish a change occurring from the system recognising it. Two states may differ without the system detecting that difference.
In SenAi, change detection matters when comparing expected and actual results, analysing task execution and improving scenarios. The system can recognise changes in data, documents, task execution methods or applicable arrangements.
For example, an employee may use a procedure different from the one recorded in the scenario. SenAi should establish what the difference is and whether it results from an error, an exception, changed conditions or a better method.
Detection alone neither establishes a change’s cause nor determines its correctness. Separate mechanisms for analysis, attribution and verification are required.
The mathematical detector Δ in AToS must be distinguished from the technical Delta gateway in SenAi’s SOS, which checks whether particular requests are permissible. Similar names do not imply identical functions.
AI agents — interpretation and coordination
AI agents use the knowledge and rules supplied by the system to interpret tasks, identify information gaps and select permissible actions.
ALEX interprets the user’s need and coordinates the work. GREG assesses the submitted issue and necessary material. MAJA carries out the agreed task assigned by ALEX.
Process rules remain in PAS. Agents apply them to the particular situation and pass technical instructions through ENGINE.
This division separates the content of the rules from the reasoning capabilities of a chosen AI model. Changing the model should not, by itself, cause the loss of recorded scenarios, agreements or work history.
ENGINE — the technical execution layer
ENGINE acts as the technical executor and operations checkpoint. It provides data reading and writing in AToS-DB, communication handling and execution of available operations according to their contracts.
It does not independently select the next business action. The agent makes that decision based on the task and applicable PAS; ENGINE checks technical requirements and executes the permitted operation.
Responsibilities are divided as follows:
- PAS and META-PAS specify knowledge, rules and operating conditions.
- AI agents and LLMs interpret the situation, realise InspFu and ImFu, make permissible decisions and coordinate work.
- ENGINE validates requests and performs technical operations.
Missing required data, permissions or a valid instruction should stop the relevant operation and lead to communication of the actual reason for the stop.
A process change can therefore consist of updating a scenario. Code changes are needed when the process requires new technical capabilities that the existing tools do not provide.
AToS-DB — persistent knowledge and work state
AToS-DB provides persistent storage for SenAi’s resources. These include recorded rules, knowledge, scenarios, StSe and processing history, placed in databases appropriate to each resource type.
Agents obtain the required data through ENGINE. They should not treat their conversational context as the sole source of applicable arrangements.
This maintains continuity across tasks and sessions. Information acquired during one execution can be used later, accounting for its source, currency, approval and permissions.
Persistent records also enable state comparisons and examination of what the system knew, what action it performed and what outcome was confirmed.
An architecture for change and improvement
An external stimulus reaches SenAi and is interpreted by the LLM acting as InspFu. The system establishes the request’s meaning and permissibility, and agents use the appropriate PAS and AToS-DB knowledge.
During work, StSe — PAS acting as internal stimuli — may be recognised and activated. The LLM acting as ImFu interprets them and initiates further transformations, while ENGINE performs permitted technical operations.
Operation results provide material for recognising changes. A mechanism inspired by Δ detects differences between states; additional mechanisms analyse causes and whether results meet expectations.
If the system recognises new knowledge, a deviation or a different way of executing a process, it can prepare a proposal to update the appropriate PAS.
Recognising a problem, proposing a change, approving it, implementing it and checking it are separate stages. Formulating a proposal does not mean that the scenario has been updated or an improvement confirmed.
After approval and verification, the new method can be used in subsequent tasks. Performing work is thus connected to gaining experience and developing the system under controlled conditions.
The significance of AToS for SenAi
AToS provides a language for describing states, transformations, stimuli, change recognition and internal attribution. SenAi uses these ideas to design a system that conducts tasks, retains knowledge and analyses the consequences of its own operations.
The ability to carry out sequences of actions initiated not only by external stimuli but also by StSe — appropriate PAS stored in the vector database — is central. InspFu and ImFu are realised through LLMs in SenAi, while ENGINE remains the technical execution layer.
Using the names PAS, ImFu, InspFu, StSe and Δ does not constitute a formal proof of SenAi’s self-awareness. Such a proof would require a mapping from the actual implementation to the AToS model and demonstration that the relevant theoretical conditions are met.
SenAi is a practical attempt to apply AToS concepts to a system that performs tasks, accumulates experience, recognises changes and develops its operating scenarios under human control.
3. How SenAi differs from other AI agent systems
Most AI agent systems are designed primarily to perform specific tasks. Agents receive instructions, use available tools, analyse information and carry out defined processes.
SenAi starts from a different premise: the system should not only perform work, but also learn about the enterprise in which it operates, learn its processes and gradually develop its own knowledge of how they are carried out.
This approach rests on an architecture inspired by the Axiomatic Theory of Self-Consciousness (AToS), combining LLMs, PAS scenarios, internal process initiation mechanisms, change recognition and controlled improvement of operating methods.
Individual elements can also be found in other AI solutions. SenAi’s intended distinction is their combination in a single system where task execution, knowledge acquisition and process development are parts of the same mechanism.
3.1. SenAi should learn from employees, rather than employees learning SenAi
Traditional information system implementations require prior analysis of business processes, documentation, configuration and user training.
SenAi proposes reversing this approach.
Employees perform their everyday duties with an AI agent. They explain their objectives, identify documents, make decisions, correct proposals and approve results.
The agent does more than execute instructions. It also analyses how the task is performed, its context, the rules applied and dependencies between activities.
SenAi can then propose recording the acquired knowledge and creating or extending a process scenario.
An enterprise need not therefore begin implementation by describing all its processes in detail. The system is intended to learn them gradually through participation in the organisation’s actual work.
This does not mean abandoning oversight. Acquired information does not automatically become a binding rule. Its meaning, correctness and potential for reuse are subject to verification.
3.2. PAS — processes recorded as knowledge rather than program code
PAS are a fundamental element of SenAi’s architecture.
In SenAi’s implementation, PAS serve as declarative records of knowledge, rules, process scenarios and execution conditions. Their concept refers to the formal notion of PAS in AToS.
In traditional software, much business logic is directly tied to application code. Changing a process may therefore require analysts, programmers and testers.
SenAi separates these concerns.
PAS specify what should be done and under which rules. AI agents interpret scenarios and organise their execution. ENGINE provides the technical functions needed to perform operations.
If an enterprise changes document approvals, the order of activities or decision conditions, the change can be introduced in PAS without modifying ENGINE’s code — provided the necessary technical functions already exist.
Process knowledge can thus develop independently of the execution infrastructure.
Scenarios can also be reused. Knowledge acquired during one task can become the foundation for subsequent actions.
3.3. The LLM as a mechanism for interpreting stimuli and initiating actions
In SenAi, language models are not merely a conversational interface.
Within the AToS-inspired architecture, they perform two functions:
InspFu — the inspiration function, triggered by external stimuli such as user instructions, documents, messages or information from other systems.
ImFu — the imagination function, triggered by internal stimuli arising during SenAi’s own operation.
This distinction matters.
An agent system need not stop after executing a single instruction. One analysis may reveal a problem, missing information, a contradiction or the need for another activity.
SenAi can then initiate the next stage using its operational state and recorded knowledge, without waiting for a new human instruction.
ImFu and InspFu need not be two different LLMs. They are distinct architectural functions whose operation depends on the origin and nature of the stimulus.
3.4. StSe — a mechanism for initiating internal processes
StSe have particular significance in SenAi’s architecture.
They are PAS stored in a vector database that serve as stimuli initiating further internal processes.
Suppose an employee asks SenAi to prepare a customer quotation.
During analysis, the agent discovers that the current price list is missing. This situation can activate an appropriate StSe, initiating a process to find and verify pricing data.
The resulting information may indicate a need to check contractual conditions and then prepare suitable clauses.
This creates a chain of related processes, initiated by internal stimuli and executed according to applicable PAS.
SenAi is therefore intended not only to answer questions and execute instructions, but also to recognise the need for further actions arising from work already in progress.
This does not imply unlimited autonomy. Further processes must respect applicable scenarios, permissions, technical constraints and required user decisions.
3.5. Delta — change recognition as a foundation for improvement
Another AToS-derived element is Delta (Δ), the state-change recognition function.
Executing a task alone is insufficient for improving how the system operates. The system must also recognise what has changed.
Delta provides the basic mechanism for detecting differences between states.
Additional analytical processes can then examine the change’s significance, possible causes and consequences.
For example, SenAi may observe that a particular process repeatedly requires employee corrections. Analysis across executions may lead to a proposal to revise its PAS scenario.
The system should not independently treat every observed change as an improvement.
Detecting a change, establishing its cause, assessing correctness and approving a new method are separate activities.
Process improvement in SenAi is intended to be controlled: agents can identify problems and propose solutions, while changes requiring approval remain under human supervision.
3.6. Full enterprise control over its knowledge
A fundamental design principle of SenAi is that all enterprise knowledge resides within a secure, isolated area of the client’s IT infrastructure (the Client Zone) and does not leave its boundaries.
This covers documents, business data, customer and employee information, PAS scenarios, process histories, decisions and knowledge acquired by AI agents.
These resources are stored in infrastructure controlled by the enterprise, particularly in the AToS-DB knowledge base.
SenAi is designed for information processing inside the protected Client Zone. Organisational data is not transferred to external AI model providers or stored in their cloud services.
The enterprise retains control over data access, storage, use, sharing and deletion.
Enterprise knowledge is entirely independent of the LLMs being used.
Language models are tools for interpreting information, analysing situations and realising InspFu and ImFu. They are not the primary repository of organisational knowledge.
Replacing or updating an LLM does not cause the loss of accumulated data, PAS scenarios or process histories. A new model can use the same knowledge, provided its behaviour meets the system’s requirements.
This independence is both technological and organisational. The enterprise need not tie its process knowledge to one AI producer, cloud platform or model version.
Knowledge belongs to the enterprise, remains in its infrastructure and is independent of language model technology.
Meeting this principle requires appropriate protection of the entire environment, including integrations, network communications, permissions and administrative mechanisms.
3.7. Small, independent and scalable LLMs running locally
SenAi does not assume that a single very large and expensive language model is necessary.
Instead, the architecture favours small, economical and scalable LLMs running locally in the client’s infrastructure (on-premises).
The preferred configuration comprises three different LLMs, available to SenAi’s agents for their assigned functions.
Using models from different technological families enables the design of independent analysis, result comparison, discrepancy detection and cross-checking mechanisms.
Three models do not automatically guarantee correct decisions. Their diversity is intended to reduce shared-error risks and provide additional quality control.
Scalability is another important architectural feature.
Depending on user numbers, workload and process complexity, the enterprise can increase computing resources or model instances without rebuilding the knowledge base and PAS scenarios.
Separating LLMs from process knowledge also permits gradual replacement with newer, more efficient or cheaper models.
SenAi does not require all enterprise knowledge to be encoded in the parameters of a huge AI model.
Knowledge resides in AToS-DB and PAS. LLMs interpret, analyse and use it within defined processes.
This approach has three main objectives:
- Security — data and knowledge processing remain within the client’s protected infrastructure.
- Technological independence — the enterprise is not dependent on one supplier or a particular LLM version.
- Economy and scalability — smaller models can be used and computing resources adjusted to actual workload.
SenAi is ultimately intended to combine contemporary language models’ capabilities with the control, security and predictability of systems maintained within an enterprise’s own infrastructure.
3.8. System development without continually programming processes
One of SenAi’s central goals is to reduce the dependence of business development on the traditional software development cycle.
In the conventional model, a new business need often triggers analysis, design, programming, testing and deployment.
SenAi assumes that many such changes can emerge through collaboration between employees and AI agents.
An employee describes the need, demonstrates how the task is performed and verifies the result. The agent analyses existing knowledge, finds relevant PAS and, where necessary, proposes a new scenario or a revision to an existing one.
Once approved, the scenario can be used in subsequent executions.
This does not eliminate programming. New integrations, technical functions, security mechanisms and infrastructure changes may still require IT specialists.
SenAi’s ambition is that developing business logic should not require a team of programmers and analysts on every occasion.
If validated in practice, this principle could significantly change the economics of implementing and maintaining systems supporting enterprise processes.
3.9. AToS as the conceptual foundation of the architecture
AToS — the Axiomatic Theory of Self-Consciousness — provides formal concepts for describing states, stimuli, transformations and change detection.
SenAi uses these concepts as inspiration for its architecture.
PAS describe knowledge and operating scenarios. InspFu and ImFu, realised through LLMs, interpret external and internal stimuli. StSe enable subsequent processes to be initiated, while Delta recognises changes.
Together, these elements form a system concept connecting action, observation of results, knowledge acquisition and proposed changes.
This is not a mathematical proof that SenAi’s implementation satisfies all the self-awareness conditions specified by AToS. Such a claim requires separate formal analysis and verification.
Independently of that question, AToS provides the conceptual foundation for SenAi’s proposed internal activity and knowledge-development mechanisms.
3.10. What is the proposed innovation?
SenAi’s innovation is not simply the use of multiple AI agents, a vector database or LLMs. These technologies are already used elsewhere.
The core concept is their combination in an architecture where:
- everyday user activity becomes a source of enterprise knowledge;
- acquired knowledge can be transformed into approved PAS scenarios;
- processes can initiate further processes through StSe and ImFu;
- action results can be analysed using the Delta mechanism;
- business logic can change without changes to ENGINE code;
- all organisational knowledge remains within the client’s protected IT zone;
- knowledge and process logic are independent of LLMs and their providers;
- the system can use three different, small, scalable LLMs running on-premises;
- people retain control over approval of significant decisions and changes.
The approach’s actual advantages must be established through practical deployments, primarily by measuring process time, cost, quality and security.
The most important difference nevertheless lies in the design premise itself.
A traditional information system is implemented so that an enterprise operates according to the processes programmed into it.
SenAi is intended to learn how an enterprise works, learn from its employees and then help the organisation improve its own processes.
Knowledge gained through this collaboration remains the enterprise’s property, is stored in its secure infrastructure and does not depend on a particular AI model.
Employees should not have to learn SenAi.
SenAi should learn from employees.