Technology

In an enterprise software project, a significant share of the effort goes into screens. Forms, lists, permission screens, report pages. All of it exists so a human can use what the system can do. Even after a business rule is settled, making that rule work on screen is a job in its own right.

AI agents change that picture. When a system defines what it can do in a form the machine understands, the user can work with it without waiting for a screen. For a process in your organization, that means the work can go into use without waiting its turn in the interface queue.

The same skeleton repeats in every enterprise project: data model, data access layer, service contracts, authorization, logging. These layers aren't what makes a project distinctive, but they still have to be written, and written correctly. This is often why a project falls behind — the real work specific to the organization gets its turn late.

Our own development framework and the code generation tools built on top of it produce that skeleton. We developed these tools over the years on our own projects and settled them a little further with each one. We spend the time we save on the part of the work that's genuinely specific to the organization.

There's a second benefit to this. Code coming out of the same mold behaves the same way in every project. A team taking over a system later finds the same structure they've seen before; that's why maintenance and handover aren't a problem.

We've placed AI-assisted generation on top of this line too. The code-generating side builds the well-defined structure with precision. The language model drafts quickly on the side that isn't settled yet. The two do different jobs, and they work together.

Until now, using an enterprise system meant learning its screens. New staff get trained, menus get explained, people learn which task is done from which screen. The person using the system is really learning its interface, not the system itself.

AI agents change that relationship. When a system exposes what it can do through a standard definition, the user tells the AI they're working with what they want, and the work happens inside the system. Describing the task is enough — learning the screen isn't required.

Today the common name for this kind of definition is MCP. Its name and details may change over time. What stays is that enterprise systems become explainable not just to people, but to machines too.

For our own family of products, this is concrete. Document flow, mall leasing and dues structure, project tracking, sensor data. Every one of these models is in a position to go into use without a new screen being written.

Adding this kind of interface to a system is the relatively easy part. It's technically well-defined, and the definition just gets followed.

What's hard is the model behind the interface. Which state a document moves to under which condition, in what order approvals are obtained, where the regulatory process constrains things, how exceptions are handled. The answers to these questions are hidden inside how the organization itself actually operates. They can't be read off a document or guessed from outside; they're only learned by working with that organization.

That's where the value of the systems we already have comes from. These models didn't stay on paper — they ran in real organizations, and got corrected while they ran.

So our direction isn't to build a new product from scratch. We're carrying the systems we already have into this new way of working.

Where we use this model

We apply the approach of building AI-open systems in our own products and R&D programs first; the choices on this page are backed by what's running there.

Products and systems

We don't write the repeating part of the code

Not every system needs a screen written for it

The hard part is on our side

Where we use this model