CS

Introducing agentic development

Home / Documentation / Agentic development /

Introducing agentic development

CS

This guide describes introducing agentic development in a full installation of NET Genium: how to set up access and rules for the agents, how to prepare a development instance, and how changes of the applications reach the production instance. The recommended procedure, to which Article 5.3 of the General Terms and Conditions of Agentic Development refers, is described in chapters 3 and 4.

1. Two ways of working

The agent may work in the development instance as well as in the production instance. The difference lies in where a change of the applications is prepared and when the users see it:

Way Where the agent changes the applications How the change reaches production Risk
Through the development instance (recommended) in the development instance by a release, once the change is verified an agent error stays in the development instance
Directly in the production instance in the production instance immediately an agent error affects the users and is borne by the operator of the instance

Both ways can be combined – for example preparing larger modifications in the development instance and making small fixes directly in production. The rules of the Combining both ways chapter then apply.

2. Agent access

2.1. Developers and personal tokens

  • Only a user with administrator rights may connect an agent to the instance. Which administrators the MCP server accepts is set by the Administrators with access to the MCP server list in the NET Genium Settings on the Permissions tab.
  • Each developer works under their own personal token – at most one in each instance. The token is not shared, not written into configuration files, shared tools or automations, and is stored in an environment variable; every write can thus be attributed to a specific person. Generating and storing the token is described in the Connecting an AI tool to the MCP server guide.
  • The token permissions determine what the agent may do:
Instance Reading all data and the model via the MCP server Writing all data and the model via the MCP server
Development yes yes
Production yes when working through the development instance no, or only temporarily for a specific data write; when working directly in production yes
  • A token is valid for 90 days. The token of an employee who leaves or changes their job position has to be deleted without delay – the “Administrator” user (ID 1) deletes the tokens of others on the MCP token tab in the Other users' tokens section.
  • If the agent works with both instances, they are connected to the AI tool as two servers. Their names are derived from the addresses of the instances (for example “portal-firma-cz” and “portal-firma-cz-dev”), so both the agent and the developer tell them apart reliably; the rule is described in the Connecting an AI tool to the MCP server guide.
  • Every access of the agent uses up a concurrent user license, just like a sign-in of the token owner.

2.2. Agent rules

Agent rules are text instructions the agent receives at the start of every piece of work – for Claude Code the “CLAUDE.md” file, for Codex the “AGENTS.md” file in the directory from which the tool is started, for an agent in Microsoft Copilot Studio its instructions. The agent acts only on what it has written down: whatever is in neither the rules nor the application model, it replaces with an assumption. The rules therefore have to exist before the agent first connects and set at least:

  • through which AI provider and which client the data of the instance may leave,
  • which instance is the production one and which the development one (the server names in the AI tool), and what the agent may do in the production instance – only read, write data, or change the applications as well,
  • what the agent must never do – typically delete an edit form or a database control, change the name of a database table or column, write into the production instance without the change history, or delete data without explicit confirmation,
  • which operations are never run against the production instance or only outside working hours – for example reading large tables and bulk batches,
  • when the agent has to ask, how it names new applications, forms and controls, and what it verifies before a change is confirmed.

The rules are extended continuously: every agent error should end in a new or refined rule. An uncertainty of the agent is better resolved by adding a description to the application or to the rules than by another instruction in the conversation – an instruction applies to one piece of work, a rule to all the following ones.

3. Recommended procedure – development instance

3.1. Setting it up

  • The development instance is a separate installation of NET Genium with a copy of the database of the production instance, used exclusively for testing changes. Installing it and transferring the database, the external functions, the print templates and the file attachments is described in the Development environment guide.
  • The development instance needs its own license key with agentic development enabled. NetGenium provides it for one development instance of the production instance at no additional fee.
  • Both instances are kept on the same version of NET Genium – the structure cannot be merged between different versions.
  • The development instance carries production data, personal data included, and the agent sends them from it to the AI provider just as it does from the production instance. Securing the development instance and anonymizing the data where needed are the responsibility of its operator.

3.2. Restore procedure

The procedure that refills the development instance with the current state of production should be described in advance – who performs the restore, when, and in which steps. Its basis is a backup of the production database restored in the development instance by the “SqlBackup.exe” program, completed as needed with the external functions, the print templates and the file attachments; the procedure is described in the Development environment guide.

  • The restore overwrites everything created in the development instance, including changes of the applications still in progress. It is therefore done after a release, when the verified changes are already in production, or knowing that the work in progress will be discarded.
  • The restore also carries the personal MCP tokens and the Administrators with access to the MCP server list of the production instance over to the development instance. A token generated earlier in the development instance stops working, and a token of the production instance starts working in the development instance too, with its permissions. After every restore, the developers therefore generate their token in the development instance again and change the value of the environment variable in which they keep it.
  • The restore also carries over the NET Genium Settings of the production instance. The procedure should include what is switched off or reconfigured in the development instance after the restore so that it does not communicate with its surroundings as production does – typically sending e-mails and connections to external systems.

3.3. Development

  • The agent works in the rhythm described in the Agentic development guide: it writes the changes of the applications into the development instance through the MCP server, and the developer verifies them directly in its portal. The agent's outputs are a proposal that has to be verified – a claim not supported by the documentation, the application model or the data of the instance is unverified.
  • The developer keeps a list of changes of the upcoming release – which applications, forms, controls, view pages, scripts and queries change. Before the release, the difference between the instances is checked against this list.
  • The agent does not rename or delete a database table or column without the developer's decision. Merging the structure deletes a renamed column in the production instance and creates it again, and its data are lost. The displayed name of a control can be changed safely – the identifiers stay.
  • A release transfers the structure, not the data. Data that should be in production as well – typically new items of code lists – are written into the production instance separately: in the edit form, or through the MCP server with the change history.
  • Program code (external functions, API) belongs to source control; the “ngef.dll” library is copied into the production instance as part of the release.

4. Release to the production instance

A release transfers the whole application structure of the development instance into the production instance and keeps the production data. It is done with the “SqlBackup.exe” program – by exporting the structure in the development instance, a merge test and a merge in the production instance. The whole procedure, including assessing collisions, is described in the Development environment guide.

4.1. Before the release

  • Comparison with the original state. The agent reads the application model of both instances – the production one by reading only – and lists the differences: added, changed and removed applications, edit forms, controls, view pages, scripts, queries and permissions. The developer compares the differences with the list of changes of the release. A difference that is not on the list – a change in progress or a change made directly in production – is resolved before the release.
  • The merge test compares only the structure of the database tables; it does not compare scripts, queries or view pages. That is why both checks are made before the release.

4.2. Merging the structure

  1. The version of NET Genium is unified in the development and production instances.
  2. In the development instance, the structure is exported by the “SqlBackup.exe” program with the Database structure (merge) profile.
  3. The production database is backed up.
  4. In the production instance, the merge test – the Database structure (merge test) profile – is run and the developer goes through the “SqlBackup.htm” file. They have to be able to justify every deletion of a column, every rename and every change of a data type; without that, the merge is not done.
  5. The merge is done – the Database structure (merge) profile. The User settings from old version option keeps the portlets, favorite items and view table settings of the users of the production instance.
  6. Files outside the database – the “ngef.dll” library and the libraries it uses, and the files in the “Config” directory – are copied into the production instance separately. “SqlBackup.exe” offers to take over the print templates during the merge.

The merge keeps the data of the production instance, the NET Genium Settings, the allowed IP addresses, the personal MCP tokens and the membership of users in user groups. Tables the development instance does not have are deleted by the merge – it first saves their data into the “Temp” directory.

Details
  • Updating an application from an “nga” file is not suitable as a release: it first deletes the application and creates it again from the file, so it removes the references from other applications, and if the import fails, the original application no longer exists (see Import and export of applications).

4.3. After the release

  • The agent compares, by reading, the application model of the production instance with the development one – within the scope of the release they should match. Any remaining differences are explained.
  • The development instance is restored from a current backup of the production database (see Restore procedure) so that further development starts from the actual state of production.

5. Working directly in the production instance

The agent may change both the data and the applications directly in the production instance. The change affects the users immediately and without verification in a development instance, and the operator of the instance is responsible for its consequences. The risk is reduced by these measures:

  • A backup before a larger change. The agent reads previous versions of scripts, database queries and the code of HTML and JavaScript controls with the “get_model_history” tool; the previous form of edit forms, controls, view pages and permissions it cannot find out through the MCP server. Before a larger change, it is therefore advisable to back up the database. Deleting a database control or an edit form deletes its data as well and cannot be undone.
  • Writing with the change history. The agent always writes and deletes data with the change history – a write through the MCP server is not recorded in the change history by default, and the history has to be requested explicitly. This belongs in the agent rules.
  • The change history is not switched off. An edit form with record history logging disabled does not write the history even when writing with the change history.
  • The form scripts do not run. A data write through the MCP server does not run the scripts of the edit form – validations, recalculations and notifications do not take place. Data whose saving such logic depends on are written in the edit form (see Integrated MCP server).
  • Load and working hours. Changing an application the users are currently working with, and demanding operations, are best done outside working hours; which operations these are is set by the agent rules.
  • Review by the developer. The developer has the agent describe the proposed change before the agent writes it, and verifies it in the portal after the write.

5.1. Combining both ways

If the production instance also has a development instance in which releases are prepared, the following applies in addition:

  • Merging the structure takes over the application model of the development instance as a whole, so it overwrites a change of an application made directly in production. Every such change therefore has to be repeated right away in the development instance – or the development instance is restored from a current backup of production if nothing is in progress in it.
  • The comparison of the instances before a release (the Release to the production instance chapter) also shows the changes made directly in production that are missing in the development instance.
  • Data written directly in production are not overwritten by a release – the merge keeps the data of the production instance.

6. When the agent makes a mistake

  • What the agent changed in the instance is shown by the change history of the records and, for scripts, database queries and the code of HTML and JavaScript controls, also by the history of their versions, which the agent reads with the “get_model_history” tool.
  • An agent error, a question or experience with agentic development can be reported through the NetGenium Helpdesk. For analysing an error, an extract from the change history, the agent rules in force and the record of the instructions the agent received are useful – it is therefore advisable to keep the conversations with the agent. Personal data not needed for understanding the error are removed from the materials before they are handed over.
  • If the error arose while working directly in the production instance, NetGenium may make the analysis conditional on the error first being reproduced in the development instance.
  • Every agent error is reflected in the agent rules (see Agent rules).