nConnect

nConnect puts language-model agents on top of one or more Nova collection systems. Chat with an agent that queries the database, reads action trees and Object Basic, drafts configuration changes and explains what it finds; run agents on a schedule; give the same tools to Claude Code or any other MCP client. Reads happen on their own. Writes go through approval.

Most of the work around a Nova installation is interpretation: what does this action tree do, why did that procedure change, which cases would a rule catch, what is in this mem.ini. nConnect gives that work to an agent that can actually look — at the database, the configuration, the code and the documentation — and gives you the result in plain language, with the tool calls it made laid out beside it.

What an agent can do

Agents work through tool sets, and each tool set is switched on per system and per user:

• SQL. Run queries against any configured Nova database; read-only queries are checked by a syntax analyser, and a system can be marked read-only outright.
• Objects. A cached inventory of tables, views, procedures and functions with their dependencies, searchable, and comparable between two systems — UAT against production, or one country against another.
• Nova configuration. Action trees, cost definitions, closure and transaction codes, extra fields, batch jobs, mem.ini entries and letter templates, opened as readable YAML, edited and saved back — with a diff, and only after you approve.
• Object Basic. A parser, formatter and interpreter for Nova's scripting language, so an agent can read what a tree step does rather than guess.
• Files and documents. Nova's folders, and PDF, Word, Excel and PowerPoint files read as text.
• Knowledge. A built-in knowledge base of Nova articles and table documentation, searched by keyword or meaning. The semantic search runs locally; nothing is sent anywhere to index it.
• Memory and tasks. What an agent learns about your installation is kept as notes it can read next time, and long pieces of work are tracked as tasks you can see progress on.

Writes go through approval

Reads happen on their own. Anything that changes data or configuration is classified as a write and stops at an approval gate, where you see the exact change — the SQL statement, the diff of the YAML — and approve it, deny it, or redirect the agent. Policies can auto-approve, ask or deny per system, per tool set or per operation, and if nobody is there to answer, the write fails closed. Every call is logged.

Unattended, on your terms

A job runs an agent without you: on a cron schedule, or when a watched object gets a new version — a changed procedure, an edited action tree. It gets one instruction, a token and time budget, a kill switch, and the same approval gates as a chat. A workflow is a pipeline of agent steps you author in YAML: the steps and their order are fixed by you, and the agent only carries out each one, so it does the same thing every time it runs.

Your model, your data

Bring the model you are allowed to use. nConnect talks to Anthropic, Azure AI Foundry, any OpenAI-compatible endpoint — including EU-hosted providers — or Ollama on a machine of your own, so a fully on-premise installation is possible. Models are chosen per agent, keys can live in an encrypted vault, and the server binds to the local machine only unless authentication is turned on. Several Nova systems — development, UAT, production; Sweden, Norway, Denmark, Finland — sit side by side in one installation, each with its own access rules.

Also an MCP server

Everything the built-in agents can do is published over the Model Context Protocol, so Claude Code or any other MCP client can query Nova, open and edit objects and search the knowledge base through nConnect — under the same approval gates and the same audit log.