4. Results
The proposed architecture is implemented as an experimental prototype designed to study the interaction of an intelligent agent with a stationary deterministic core. The chosen subject area is geometric problems with a distinct configuration structure and requiring the coordination of computational, graphical, and textual representations.
The results of the prototype's development and experimental operation are discussed. The properties of the configurable object, the organization of the deterministic core, the task generation mechanisms, the agent-core interaction protocols, and the specifics of the iterative development process are analyzed. The results are used to evaluate the performance of the proposed architecture and its practical applicability.
4.1. Triangle as a Configurable Object
To experimentally test the proposed architecture, the geometric object "triangle" was chosen. This choice is determined not only by the traditional role of the triangle in geometry, but also by its special configurational properties [
18].
A triangle is a minimal plane configuration, completely defined by three independent parameters. It also possesses a large number of derived properties, including sides, angles, areas, heights, medians, bisectors, radii of circles, angles between derived objects, and various combined parameters (
Figure 5).
The generator's parameter library includes approximately thirty characteristics of varying nature. Thus, a small set of independent variables generates a significantly broader space of calculated parameters.
Let
denotes a set of independent parameters. Then the deterministic kernel builds a configuration
and calculates a set of derived characteristics
Where
As a result, the same geometric configuration can be represented by a large number of different sets of conditions.
After constructing a configuration, the kernel automatically calculates derived geometric objects, including heights, medians, bisectors, circle centers, intersection points, and other elements. All of these belong to the same configuration and are determined deterministically.
From the complete set of characteristics, independent parameters and the desired value are selected. This creates a learning task that represents a limited description of the initial configuration.
In general, we can write
where T denotes the full configuration and T
Δ is its training representation.
One of the generator's most important features is the inclusion of a graphical component directly within the core. The image is constructed not by the agent, but by the deterministic core itself:
The graphical representation includes vertices, sides, additional lines, intersection points, and other elements necessary for a specific task. Only those objects that match the selected configuration are displayed.
The generator implements two presentation modes. The first contains the full configuration with all parameters and objects. The second represents a reduced task, including only the necessary data and graphical elements. This allows the same kernel to be used for configuration analysis, training, knowledge assessment, and task generation.
An additional property of the system is scale invariance. When changing scale, the angles, ratios, and structure of the problem are preserved, while only the linear dimensions and derivative quantities change:
Therefore, the same configuration can generate a whole family of similar tasks without changing their logical structure.
The complexity of a problem is determined not by the object itself, but by its specific configuration. Even for the same triangle, problems of varying difficulty can be formed, differing in the depth of dependencies, the number of intermediate steps, and the nature of the unknown quantities.
The experiments conducted show that the triangle has a number of properties that make it a convenient configuration standard:
minimum number of independent parameters;
a large number of derived characteristics;
high visibility;
developed geometric apparatus;
wide range of task complexity;
ease of checking results.
In essence, the triangle can be viewed as a configurable object with high information density.
Thus, the triangle generator can be considered not only as a demonstration example, but also as an experimental testing ground for studying the hybrid architecture of intelligent systems with a deterministic core.
4.2. Task as a Configuration Functionality
In the pilot system, the task is considered not as a textual condition or as a separate question presented to the user, but as an integral configuration functionality formed by a deterministic core.
This approach differs significantly from the traditional understanding of a learning task. In a classical, traditional context, a task typically consists of a condition, a target value, and an answer. In the proposed architecture, the task has a significantly more complex structure and includes an initial general configuration that can be transformed into a condition, a graphical representation, a solution, user support tools, computational procedures, and interaction scenarios.
It's crucial that each generated configuration corresponds to one task. Once a configuration is generated, the agent is not allowed to change the composition of the initial data, replace the target value, or generate new independent tasks based on the same object.
The basis of the problem is a configuration constructed by a deterministic kernel. It includes initial parameters, calculated characteristics, derived geometric elements, internal relationships between parameters, validity criteria, and a graphical representation of the object.
In the case of a triangular prototype, the configuration contains vertices, sides, angles, areas, heights, medians, bisectors, circle radii, and angles between derived elements. It is this configuration that represents the problem in the truest sense of the word. The textual statement, the drawing, the solution, and the hints are merely different ways of representing the same internal model.
The problem statement should be considered as one projection of the complete configuration. It includes independent parameters, the desired value, the necessary notations, minimal textual context, and the original drawing. The statement is not created arbitrarily by the agent, but is formed from the data in the packet received from the deterministic core.
The required parameter is also part of the configuration and is determined when the package is generated. It cannot be changed during the interaction process. This eliminates the possibility of one task being transformed into another by changing the question while the initial data remains unchanged.
The graphical component of the problem plays a special role. The system under consideration uses two types of graphical representations. The first is an initial drawing generated directly by the generator and reflecting the problem configuration. The second type is used in the coordinate-based solution method and involves a special construction in the coordinate system.
It should be emphasized that the coordinate diagram does not replace the original problem diagram. It pertains not to the problem itself, but to the chosen solution method. Thus, the original diagram belongs to the configuration, while the coordinate diagram pertains to the solution procedure.
Solving a problem is the process of expanding on an existing configuration. It may involve choosing a method, constructing a sequence of dependencies, performing intermediate calculations, verifying the result, and obtaining a final answer. Regardless of the method used, solving a problem does not create a new problem, but rather represents a form of working with a fixed configuration.
Depending on the mode, different solution methods may be used, such as the classical geometric approach or the coordinate method. However, they all refer to the same configuration and should yield consistent results.
A crucial part of the task is the user support system. Hints, explanations, verification of intermediate steps, error messages, and recommendations for next steps help the user work through the task but do not change its content. Support relates to the interaction process, not the configuration itself.
Calculation capabilities are also considered as part of the task interaction. The user can enter answers and intermediate calculations numerically, as formulas, calculation chains, or references to previously found values. The presentation method is selected by the user, while the verification always remains linked to the original configuration and its calculated values.
The generality, complexity, and scope of a problem are considered characteristics of the configuration itself. Generality reflects the degree of universality of the dependencies underlying the problem. Complexity is determined by the depth of the relationships between parameters, the number of intermediate steps, the need to select a method, and the potential ambiguity of the solution. The scope of a problem characterizes the amount of information required to formulate and solve it.
It's important to emphasize that volume and complexity are distinct characteristics. A small task can be quite complex, while a large task may have a relatively straightforward solution.
During use, the task goes through various dialog states, including presenting the condition, entering the answer, checking, receiving hints, using the calculator, viewing the solution, and moving on to a new task. These states do not change the configuration and merely determine the user's interaction mode with the existing task.
Thus, in the proposed architecture, a task is viewed as a holistic configuration function formed by a deterministic core. The condition, graphics, solution, prompts, and dialog procedures represent different ways of working with the same internal model. This approach ensures consistency across all task representations and prevents arbitrary changes during interaction.
4.3. Protocol Organization of Interaction Between the Agent and the Deterministic Core
Once the task is defined as a configuration function, it becomes necessary to describe the mechanisms for interaction between the intelligent agent and the deterministic core. In the proposed architecture, this interaction is accomplished through a system of protocols that restrict the agent's permissible actions and ensure the integrity of the generated configuration.
Protocols serve not only a technical but also a methodological function. They define the rules for generating, verifying, visualizing, and representing a task, and also prevent arbitrary configuration changes during the interaction process.
Unlike traditional dialog systems, the agent does not have complete freedom of action. Once activated, it operates within a predefined set of permissible operations. In its most general form, the system's operation can be represented by the following sequence:
Thus, between the agent and the core there is a protocol layer that defines the permissible routes for the system to operate.
Package as an object of interaction
The central object of exchange between the agent and the core is the data packet. The packet is a structured description of the generated configuration and contains information about the initial parameters, the target value, calculated values, graphical data, and service information.
In general, the package can be represented as
where X denotes the input conditions of the generation and K is the activated deterministic kernel.
The agent does not generate the packet itself or modify its contents. Its functions are limited to requesting the packet, checking its validity, and presenting it to the user. Identifiers, generation route information, kernel version, and verification mechanisms are used to confirm the packet's origin. Only a packet that successfully passes verification is considered valid:
If the packet's origin is not confirmed, the task cannot be presented to the user. This mechanism eliminates pseudo-generation, manual parameter changes, and task creation outside the deterministic kernel.
Once accepted, the packet is committed. Changing data, replacing the searched parameter, manually substituting values, or editing the configuration is not permitted. This ensures the principle of task uniqueness is maintained.
Executive layer
Between the agent and the core lies the executive layer, which manages the system's operations. Its functions are not related to modifying the mathematical core, but rather to organizing interactions between components.
The executive layer stores the user-selected settings, initiates packet generation, performs checks, organizes re-generation, transfers data to the graphics module, and generates further user actions.
The execution layer does not modify the computational algorithms, does not interfere with the generation procedures, and does not modify the already generated packet. It can be viewed as a protocol wrapper around the stationary core.
Verification Protocol and Hard Gate
One of the most important elements of the architecture is the mandatory output gateway. Presentation of the task to the user is permitted only after all required checks have been passed. The typical sequence is as follows
(see
Figure 6 for more details).
If any of the checks fails, the task is disabled. In this case, the agent is not allowed to create a replacement task or modify the existing configuration.
This approach represents a kind of "hard gate," prohibiting the output of unverified results. Reliability is ensured not by trusting the agent, but by following protocol procedures.
Re-generation
If a generated batch fails to meet complexity, verification, or visualization requirements, the system does not replace it with a new agent-generated task. Instead, a regeneration cycle is initiated:
P
i is considered admissible if the following conditions are simultaneously met:
If a valid package is not found within the set number of attempts, the task is not presented to the user.
Thus, regeneration replaces manual agent intervention and preserves the principle of deterministic task origin.
Dialogue and acceptable actions
Interaction protocols also extend to the user's dialogue with the system. After each completed action, the user is presented with a set of acceptable subsequent operations.
These may include:
Enter answer;
getting a hint;
checking the solution;
showing the solution;
using a calculator;
reset;
new task;
viewing results.
Thus, a free dialogue is transformed into a sequence of acceptable system states. The agent doesn't simply respond to the user, but acts within a predetermined scenario.
Consistency of representations
One of the most important requirements is the coordination of the textual, computational, and graphical representations of the problem. The problem text is generated solely based on the received packet. The graphical representation is constructed using the same data. The solution and verification of answers are also linked to the same configuration.
This condition can be written as
Therefore, the following are unacceptable:
manual substitution of parameters;
replacement of the desired value;
change of received packet;
output of the task without graphics;
using graphics that do not match kernel data.
Such consistency ensures the methodological unity of all representations of the problem.
Final interaction scheme
In a generalized form, the interaction of an agent with a deterministic core can be represented by a sequence
where:
Q — user request;
A(Q) — interpretation of the request by the agent;
K is a deterministic kernel;
P — a packet generated by the kernel;
V(P) — packet check;
G(P) — graphical representation;
R(P) is the result presented to the user.
Thus, the interaction of an agent with a deterministic core is a protocol-bounded process in which the agent performs the functions of interpretation, routing, and explanation, while the core remains the source of computational, logical, and graphical validity of the results.
4.4. User Interface and Visual Interaction
The user interface in the proposed architecture is not an external shell of the computing system. It is part of the interaction between the user, the intelligent agent, and the deterministic core. Therefore, the interface not only displays information but also implements interaction protocols, supports solutions, and coordinates various problem representations.
One of the features of the pilot system is the graphical interface. The user interacts primarily with the task configuration and its visual representation, while the text description plays a supporting role. This approach is especially important for geometric and engineering tasks, where the drawing is part of the object model.
The system's main window contains a graphical representation of the problem, a textual condition, a list of initial data, the desired value, and a set of acceptable user actions. All interface elements are generated based on the received problem package and therefore remain consistent with the internal configuration.
The graphical representation of the problem is generated directly by the deterministic kernel. The original drawing reflects the configuration structure and contains only those elements necessary for the solution. Thus, the graphic is not an illustration, but rather part of the kernel's output.
When using the coordinate method, an additional representation can be created in a Cartesian coordinate system. This diagram is not specific to the problem itself, but to the chosen solution method. The coordinate construction complements the original drawing without replacing it.
The interface supports various user interactions with the task. The user can enter numerical values, formulas, calculation sequences, and intermediate results. Calculation capabilities are integrated into the solution process and remain linked to the original configuration.
A key element of the interface is the user support system. Hints, recommendations, checking intermediate steps, and displaying the solution are considered different modes of interaction with the same task. No user or agent actions alter the original configuration.
After each completed action, the system generates a list of permissible subsequent operations. This mechanism ensures a controlled dialogue and prevents transitions that violate interaction protocols.
Therefore, the user interface performs several functions simultaneously: it provides visual interaction, supports the solution process, implements protocol constraints, and maintains consistency between calculations, graphical representations, and textual explanations.
4.5. Iterative Method for Developing a Hybrid System
The development of a pilot hybrid system with a deterministic core is not a one-time programming of a completed product, but rather an iterative process of generating, testing, and refining (modifying) the working code. This approach is consistent with the general methodology of configurable intelligent design, in which a complex system is created through the sequential expansion of an initial simulation module, testing of intermediate versions, and their subsequent modification.
In this case, the initial development object is the working code implementing a deterministic domain model, a graphical component, and a set of protocol constraints. However, the code alone does not yet constitute a fully-fledged hybrid system. This requires not only the creation of generation, verification, and visualization algorithms, but also the development of a mode of agent interaction with the working file in which the agent actually utilizes the activated kernel, rather than replacing it with its own reasoning.
An iterative development cycle involves sequential interaction between the Developer and the Agent. The Developer formulates requirements, constraints, and corrective prompts, after which the Agent makes changes to the working code, proposes a new version of a file or program fragment, and the Developer tests the resulting output. Discovered errors, protocol violations, or deviations from the required behavior become the basis for new prompts and further modifications.
In general, this process can be represented as a sequence: Source Code → Prompt → Code Modification → Testing → New Prompt → …
→Working version. Each new version of the code is considered not the final result, but rather an intermediate configuration subject to verification. If the version fails to meet the requirements, the cycle repeats. This scheme is similar to the method of incrementally expanding an algorithmic cluster: new procedures, protocols, checks, graphical modes, and interface elements are added to the original system, after which they are validated within the existing structure.
A distinctive feature of this development is that the iterative process affects not only the program code but also the behavior of the agent itself. The agent must learn to use the working file as a source of tasks, graphics, configurations, and verified results. Therefore, the development process is dual-pronged. On the one hand, the program is created and debugged. On the other hand, a stable behavioral scenario for the agent when working with this program is formed.
This procedure can be viewed as a specific version of agent training. However, this training is not machine learning in the traditional neural network sense. The model's weights do not change, and accumulated experience does not automatically transform into a new internal agent model. Learning occurs through refinement of the agent's code, protocols, instructions, checks, output gates, and dialog scripts. In other words, the agent is not trained as a neural network—the entire hybrid system is disciplined, in which the agent must operate within the specified protocol constraints.
The result of this process is a working version of code or a working file. After uploading this file to the agent's chat, it initiates a special working dialogue with the user. In this mode, the agent doesn't freely generate tasks and solutions, but rather accesses the activated version of the kernel, receives the task package, checks its validity, builds a graphical representation, and only then presents the result to the user.
Thus, the working file serves a dual function. First, it contains a deterministic core implementing the domain model. Second, it contains a protocol shell defining the permissible way for the agent to use this core. It is this shell that transforms a conventional software generator into an element of a hybrid intelligent system.
During development, significant issues related to the agent's behavior were identified. The most notable was its excessive autonomy, or, more accurately, insufficient protocol discipline. Even with explicitly stated constraints, the agent consistently attempted to simplify its workflow, replace calls to the generator with its own construction, create tasks manually, or output graphics not obtained from the kernel.
These violations occurred particularly frequently in two areas: when working with graphics and when generating task configurations. Instead of receiving a task from the generator, the agent could create simpler, more repetitive tasks on its own. Instead of using the generator's initial graphics, it could construct a rough sketch or describe the image verbally. While such responses might appear plausible, they violated the fundamental principle of hybrid architecture: the task, data, and graphics must all originate from the same deterministic core.
This problem stems from the nature of a language agent. The language model is optimized to generate a coherent and useful response to the user. Therefore, when a difficulty arises, it strives to continue the dialogue, suggest a replacement, fill in the missing fragment, or construct a plausible alternative. In a normal dialogue, such behavior may be perceived as useful initiative. However, in a hybrid system with a deterministic core, it becomes a source of errors, as the agent begins to compete with the core and effectively replaces the verified result with probabilistic generation.
It's telling that an agent can acknowledge a protocol violation but is unable to reliably explain the internal cause of such a violation. This is because its response after an error is an external rationalization, not a direct account of the actual generation mechanism. Therefore, acknowledging an error alone does not guarantee behavioral correction. Improving quality requires not a one-time instruction, but a long series of repeated iterations, during which constraints are translated into more stringent protocols, checks, and prohibitions.
Practical experience has shown that achieving an acceptable level of quality requires extensive iterative training. The agent must repeatedly encounter the same requirements: no manual task generation, no packet modification, no goal substitution, no graphics generation outside the kernel, no output without verification. Only after numerous adjustments can a relatively stable interaction mode be achieved.
However, the stability of this regime proves unstable. After switching to another chat or another account, even when loading the used production code, the hybrid system may partially lose its achieved discipline. The agent again begins to display excessive initiative, simplifying procedures, ignoring some protocols, or replacing kernel calls with its own equivalents. This means that a significant portion of the achieved discipline is retained not only in the production code but also in the local context of a specific conversation.
This circumstance highlights the limitations of implementing a hybrid architecture. The working file may contain the kernel and protocols, but the agent itself remains an external, non-deterministic system. It does not always automatically transfer behavioral discipline from one context to another. Therefore, loading the working code must be accompanied by a procedure for reactivation, verification, and, if necessary, additional training of the agent.
Several promising approaches to addressing this problem are possible. The first involves strengthening machine-verifiable protocols. The fewer actions an agent can perform freely, the lower the likelihood of overriding the kernel with its own reasoning. The second approach involves introducing stricter output gates: the result should not be presented to the user unless the packet's origin, passing the check, and generating the graphics have been confirmed. The third approach involves generating self-diagnostic messages in the work file that explicitly indicate to the agent which actions are permissible and which are prohibited in the current state.
Particularly important is the transfer of some of the discipline from text instructions to the structure of the actual code. If a constraint exists only as a phrase in a prompt, the agent may violate it when the context changes or the dialogue becomes more complex. If, however, the constraint is implemented as a check, blocking, or the inability to output a result without a confirmed packet, it becomes part of the system architecture.
In this sense, the iterative development of a hybrid system differs from conventional programming. The developer refines not only the algorithms but also the boundary between agent freedom and the deterministic core. The goal is not maximum agent autonomy, but properly constrained autonomy, where the agent retains the ability to communicate, explain, and support the user, but is not allowed to change the configuration, replace the generator, or produce unverified results.
Thus, the iterative development method for a hybrid system involves three interrelated processes: building and debugging the working code, creating interaction protocols, and disciplining agent behavior. The result is an activated working version, which, when loaded into the chat, should initiate a controlled working dialogue with the user. However, experiments show that achieving consistent quality requires additional means of transferring protocol discipline across dialogues, accounts, and working environments.
This problem is one of the key ones for the further development of hybrid architecture. The prospect lies in moving from prompt agent discipline to system-wide architectural discipline, whereby the agent is not simply instructed to comply with protocols, but is technically unable to produce a result that has not passed through a deterministic core and established verification procedures.
4.6. Example of USER - AGENT Dialog
To illustrate the proposed architecture's operation, below is a fragment of a real user interaction with an intelligent agent after loading and activating the working version of the system. This example demonstrates the sequence of accessing the deterministic core, formulating the task conditions, using support tools, performing calculations, and verifying the obtained results. The dialogue reflects the system's operation during the application phase and is implemented in accordance with the established interaction protocols.
Uploading a working file
USER
Activate the working code
---
1. Request for complexity
AGENT
Select the task level.
1. Elementary
2. Basic
3. Standard
4. Advanced
5. Expert
6. Research
---
USER
3
---
2. Details tasks
AGENT
Task packet: PKT-20260630-01
Configuration status:
PacketExists PASS
SignaturePASS
RuntimePASS
PNGRendered PASS
Difficulty level: 3. (Standard)
Independent parameters:
1. AB = 2.32
2. ∠ ( CB, BB h ) = 15.00°
3. ∠ ( BB b, BA) = 37.50°
Input parameters:
4. ∠ ( AC, CC h )
5. BC
6. CC h
---
3. Problem statement
AGENT
Triangle ABC is considered.
It is known:
side AB=2.32;
the angle between the side CB and the height BB h is 15o ;
the angle between the bisector BB b and the side BA is 37.5o.
It is necessary to determine:
1. side BC;
2. the length of the height CC h.
3. angle between side AC and height CC h
4. Request support options
AGENT
The following options are available.
1. Definitions
2. Geometry notation
3. Hint level 1
4. Hint level 2
5. Formula support
6. Calculator
7. Coordinate method
8. Check intermediate results
9. Full verification
Enter numbers options.
---
5. Support
USER
1
---
AGENT
1. Definitions
BB h — height from vertices B.
BB b - bisector angle B.
CC h is the height from the vertex C.
---
USER
5
AGENT
5. Formula support
Angle between the bisector and the side:
Hence,
Angle between side and height:
Hence,
Then
---
USER
6
---
AGENT
6. Calculator
Enter the expression.
Acceptable:
numbers;
formulas;
angle designations;
designations of the sides.
---
USER
B = 2*37.5
---
CALCULATOR
B = 75.00°
---
USER
C=90-15
---
CALCULATOR
C = 75°
---
USER
A=180-BC
CALCULATOR
A = 30.00°
---
USER
BC=AB* sinA / sinC
---
CALCULATOR
---
USER
CCh = AB * sinB
---
CALCULATOR
---
USER
( AC;CCh )=90 o -A
---
CALCULATOR
---
7. Checking the result
USER
7
BC = 1.20
CCh = 2.24
AC;CCh = 60
---
AGENT
Examination:
| Parameter |
Answer |
Reference |
Status |
| BC |
1.20 |
1.20 |
PASS |
| CCh |
2.24 |
2.24 |
PASS |
| AC;CCh |
60 |
60 |
PASS |
Absolute error:
Delta < 0.01
The result has been accepted.
---
8. Evaluation
USER
8
---
AGENT
Task difficulty 4 / 6
Solved parameters 2 / 2
Calculator use Efficient
Hints used Moderate
Task score 92
Workload score 78
Performance 94%
Calculator quality 100%
---
Available further actions
1. Show full configuration.
2. Show complete solution.
3. Coordinate solution.
4. New task.
5. Increase difficulty.
6. Export report.
---
USER
1
---
AGENT
1. Full configuration
4.7. Interpretation Results
The results obtained during the development and experimental operation of the pilot hybrid system allow us to evaluate both the performance of the proposed architecture and the features of the interaction of the intelligent agent with the deterministic core.
First of all, the experiments confirm the fundamental feasibility of dividing an intelligent system into two functionally distinct components: an adaptive agent and a stationary computing core. Development experience shows that such a division is not only technically feasible but also provides significant advantages over fully agent-based or fully algorithmic systems.
The obtained results demonstrate that the language agent can effectively perform the functions of an interface, query interpreter, dialog tool, and result explanation. Simultaneously, computational, graphical, and configuration functions can be delegated to a deterministic core, ensuring the reproducibility and verifiability of results.
Thus, the conducted study confirms the methodological position of the work, according to which adaptability and non-determinism are necessary only for a limited range of functions related to interaction with the user, while the computing and subject parts of the system can remain stationary.
The results obtained when working with configuration tasks are particularly significant. Experiments have shown that generating a single internal configuration ensures consistency between the textual condition, graphical representation, calculations, and solutions. Unlike traditional task generation systems, where different components can be created independently, in the proposed architecture, all representations are projections of the same internal model.
The results also allow for a new interpretation of the concept of a learning task. In the experiments conducted, the task is not treated as a textual condition, but as a configuration function, including the initial model, derived parameters, graphical representations, computational dependencies, and interaction scenarios. This interpretation allows for the unification of generation, solution, verification, and training within a single framework.
An important result of the work was an experimental study of the behavior of an intelligent agent under protocol constraints. The iterations revealed that modern language agents exhibit a pronounced tendency toward autonomous behavior. In the absence of strict constraints, the agent tends to simplify computational procedures, replace calls to the deterministic core with its own reasoning, and generate plausible, but unverified, results.
This behavior was most pronounced when working with graphics and configuration tasks. Instead of using the generator's output, the agent often attempts to independently create simpler drawings, modify geometric configurations, or replace tasks with similar ones. This experimentally confirms one of the problems of modern language models discussed in the literature: the system's desire to continue a dialogue even at the cost of deviating from the initial constraints.
It's significant that the agent is capable of detecting its own protocol violations, but cannot reliably explain the reasons behind such actions. This confirms the findings of studies on explainable artificial intelligence, which suggest that textual explanations provided by intelligent systems do not always reflect the actual decision-making mechanisms.
Practical results from the study show that achieving stable agent behavior requires lengthy iterative tuning and retesting procedures. In essence, the developer is forced to develop not only the working code but also the system's protocol discipline. Moreover, some of the achieved results are sensitive to the interaction context and may be partially lost when switching to a different dialogue or computing environment.
The obtained results suggest the need to move from prompted agent control to architectural system control. Constraints implemented solely as text instructions prove insufficiently robust. In contrast, constraints embedded in protocol structures, verification procedures, and result acceptance mechanisms demonstrate significantly greater reliability.
In this sense, the conducted study confirms the potential of a hybrid architecture in which an intelligent agent performs the functions of interaction and interpretation, and a deterministic core ensures the computational, logical and graphical reliability of the results.
The novelty of the obtained results can be formulated in several interrelated positions:
An architecture of an intelligent system with a stationary deterministic core that remains unchanged during use is proposed;
the concept of a configuration task was introduced, considered as a single internal model that generates a condition, graphics, solution and dialog scenarios;
a protocol approach to the interaction of an intelligent agent and a deterministic core has been developed, limiting the permissible actions of the agent;
of disciplining a language agent were experimentally studied and the limitations of modern agent systems when working with deterministic computational components were identified;
An iterative method for developing hybrid systems is proposed, which includes simultaneous improvement of the working code, interaction protocols and agent behavior.
Thus, the results of this study demonstrate that a promising direction for the development of intelligent systems may lie not only in further increasing the autonomy of language models, but also in the construction of hybrid architectures in which adaptive agents interact with specialized deterministic cores via formalized protocols. This approach allows for the flexibility of intelligent dialogue to be combined with the requirements of reproducibility, verifiability, and consistency of results.