White Paper: a look under the hood of Agentic Application Development
How Ciphix builds enterprise applications at low-code speed, with full ownership and without platform lock-in.
Our first white paper, “From AI Experiment to Production,” focused on the strategic step: why organizations need to move their AI initiatives beyond the pilot phase and what Agentic Application Development (AAD) means for the business. This document delves a layer deeper. It is written for those who need to be able to assess the technical aspects: how an AAD application is structured, how security and quality are systematically enforced, where the application runs, and why ownership remains with the organization.
In a nutshell: AAD combines a production-ready application foundation with AI-driven development, enabling enterprise applications to be created at a high development speed, while the result is standard, portable software that is fully owned by the organization.
- Build faster without compromise
Develop production-ready applications in weeks instead of months. - Avoid loose AI experiments
Work from a single foundation for integrations, governance and architecture. - Stay in control of your software
Build without platform lock-in and maintain complete flexibility.
From promise to architecture
AAD’s core promise can be summed up simply: the speed of a ready-to-use development platform, without the usual trade-offs in the form of lock-in, user licenses, and a customization limit. That promise is only credible if the underlying technology is sound. Speed that comes at the expense of quality is not an advantage, and ownership that exists only on paper is not ownership.
This chapter and the next one show that speed does not come from skipping steps, but from eliminating repetitive work, and that quality does not come from individual expertise, but from systematic enforcement. Three building blocks make this possible:
- The Base. A production-ready application framework that includes everything an enterprise application needs—even before the first line of business logic.
- An AI agent that operates within defined parameters. Not “AI that generates random code,” but an agent that operates within a structured framework with established conventions and automated quality checks.
- Enforcement instead of agreements. Security, architecture, and quality rules are built into the tooling, not set out in a document that someone is supposed to follow.
The anatomy of an AAD application
Every application built on the Ciphix Base follows the same structure. If you understand one, you understand them all. That’s a deliberate choice: predictability makes both people and AI agents more reliable.
- One application, two parts. The interface (the front end) and the engine (the back end) are two parts of a single whole. They share a single set of agreed-upon data contracts, ensuring that both sides are always in sync and that a change on one side immediately triggers an error on the other—during development, not in production.
- Access control before every request. Before a request reaches the data, it passes through a single shared access layer. This layer verifies the user’s identity, limits the results to the records the user is authorized to view, and hides the fields the user is not authorized to read or modify. Because this layer is shared and applies everywhere, the same rules apply across the board.
- Shared building blocks. The demanding, security-sensitive components (login, access control, file management, email, notifications, background processing) come from shared, versioned packages that each project reuses. They are built once, thoroughly tested, and improved for all projects simultaneously.
- Data and storage. Application data resides in PostgreSQL, a proven enterprise database. Uploaded files are stored in managed object storage. Tasks that take time or require an external service—such as sending emails, generating documents, or processing large imports—run in the background so that the application remains responsive.
The tech stack
The Base is built on widely adopted, open technologies. These aren’t niche choices: they are the most common languages and frameworks in modern web development—and therefore the ones that every AI coding assistant understands best.
The common thread: standard tools that every web developer recognizes and that run on standard cloud infrastructure. There is no proprietary runtime and no license tied to the technology itself. In practice, this means no talent shortage (any TypeScript or Vue developer can work with it), no vendor sunset risk (open technology isn’t discontinued or acquired), and full compatibility with the entire ecosystem of AI development tools.
“Build the right thing”—in practice!
The Base and the package ecosystem
None of the Base’s major capabilities—such as authentication, email, notifications, PDF generation, or AI—are directly built into every application. Instead, each capability resides in a separate, versioned package under the @ciphix/* namespace. Base itself is a thin layer that ties these packages together using project-specific configuration.
This has three specific consequences:
- Consistency across projects. Every Ciphix application uses the same authentication, the same email handling, and the same control panel, because they all use the same packages. An improvement or fix in a package is rolled out to every project with the next update.
- Separation of responsibilities. The packages are maintained by the platform team. Project teams focus on business logic, not infrastructure.
- Modularity. A project that doesn’t require PDF generation simply omits that package. A project that requires AI features includes the AI package.
Functionally, these packages serve the same purpose as the built-in modules of a ready-made development platform: the management module, the email module, and so on. The difference is that we own them, can expand them, and there are no license fees associated with them. The capabilities include, among others: identity and access, email and Microsoft 365, notifications and push, file storage, PDF generation, Excel import, data visualization, AI and agents, real-time and locking, background tasks, internationalization, and the design system.
The set grows over time: recurring needs across projects are transformed into shared building blocks. This is also where its ongoing value comes from. Annual maintenance provides access to updates and improvements across the entire package ecosystem, including proactive security patches and framework upgrades, ensuring that the application stays current rather than slowly becoming legacy.
The Design System: Visual Consistency as a Building Block
Enterprise applications require visual consistency. On off-the-shelf development platforms, this is provided by built-in widget libraries; in AAD, it comes from its own design system: a library of pre-built, standardized interface components (form fields, data tables with built-in pagination and filtering, dialogs, panels, and empty and loading states). The developer—or the AI agent—never starts with a blank canvas but assembles pages from these components, similar to dragging and dropping widgets in a visual development environment. An interactive catalog (Storybook) displays each component in isolation and serves as the “palette” from which the agent draws. The result: even a newly generated page looks and feels like every other page in the application.
The modular system
Within an application, everything is organized into modules. A module is a self-contained block of functionality (such as a CRM, scheduling, or billing module) that includes its own components:
Modules come from two sources but follow exactly the same contract: the reusable @ciphix/* modules from the package ecosystem, and the application-specific modules that the team adds to model the domain of a specific application.
Why this matters from a technical perspective: every security decision coexists with the code it governs, not in some remote central configuration. Which roles exist, which fields are readable, which rows a user is allowed to access, which actions they can invoke—all of this is defined within the module itself. If a module is removed, its permissions are removed along with it. If a new module is added, it declares its own roles. This prevents the silent accumulation of permissions that eventually makes large applications insecure and unreadable.
Sound familiar to Mendix teams? The role model will feel familiar. Roles organized by module, grouped into user roles at the application level. The same structure as on such platforms, but expressed in standard code rather than in a proprietary model.
The security model: defense in depth
Security is built into the foundation, not just added as an extra layer on top. The model is based on a single principle: by default, everything is denied. Access is granted only where a rule explicitly permits it. This principle is enforced across multiple independent layers, so that a failure in one layer does not immediately lead to a data breach.
Identity and Roles
Users have roles at the application level. With every request, these roles are translated into the full set of specific permissions defined by the relevant modules. The code then always checks against those granular module-level permissions, never against a broad “is this an admin?” question. As a result, permissions are calculated centrally and consistently, and adding a new capability amounts to declaring a permission, not scattering checks throughout the entire codebase.
Layered Database Security
The data itself is protected by four mutually reinforcing layers, all of which are enforced within the application:
Access rules are additive: a row is visible if any applicable rule permits it. If no rule applies, access is denied. Sensitive columns, such as API keys and OAuth secrets, are also stored in encrypted form (AES-256-GCM), ensuring they remain unreadable even with direct database access.
Quality at AI speed
The legitimate question regarding AI-generated code is whether it can be trusted. AAD addresses this not by relying on the model, but through a chain of automated checks. It doesn’t matter whether code is written by a human or by an agent: it goes through the same checks, and nothing reaches production unless it passes them all.
The net result: consistent quality at high speed. Speed does not come at the expense of reliability, because reliability is not a human discipline but a property of the system.
Action security
Each endpoint specifies who is allowed to call it, possibly with additional conditions on the request itself (for example, “only if it concerns the user’s own data”). This check takes place before the handler runs, so the business logic does not need to be cluttered with its own security checks. Background tasks that do not have a user session run under a dedicated system identity and are validated at startup: if the permissions declaration is incorrect, the application will not start. This ensures that discrepancies are caught early rather than in production.
The bottom line: Deny by default, grant access in a granular manner, and enforce at every level. Authentication, access control, and auditing are provided by shared packages, ensuring that every application meets the same standard rather than depending on whether a single project has implemented it correctly.
How building works
Building with AAD feels familiar to anyone who has worked with a visual development platform. You start with a template, the structure of a function is generated, the desired functionality is described in plain language, and the tooling ensures high quality. The developer’s role shifts from writing code themselves to directing the agent and validating the results—just as a platform developer today configures modules and builds pages, but with the full power of real code underneath.
- Start from the Base. The project is forked and set up in minutes, with the development environment and all infrastructure ready to use.
- Generate a module. A single command sets up a new functional area: its data, its screens, its translations, and its access rules—all configured and in accordance with the conventions.
- Describe what is needed. In plain language, for example: “Add a status field to orders with the values ‘draft,’ ‘submitted,’ ‘approved,’ and ‘rejected.’ Admins can see all orders, while users can only see their own.”
- The officer is writing the ticket. The agent understands the conventions and patterns and generates the data changes, the backend, the screens, the translations, and the access rules.
- Automated checks validate the work. Quality guidelines, type checking, review steps, and tests confirm that the feature complies with standards and actually works.
- Ship it. The automated pipeline runs all the tests, and the feature is rolled out in hours rather than weeks.
What makes this possible is not “AI that writes code,” but the combination of: a well-structured, well-documented foundation in which the agent has clear patterns to follow; convention-enforcing tools that catch deviations; generators that ensure new modules start off correctly; a design system with a catalog; and shared packages that have already solved the difficult problems.
Hosting, Deployment, and Portability
An AAD application is a standard web application that runs in containers. The same container image runs, without any code changes, in your own cloud or on infrastructure managed by Ciphix. This is a deliberate design choice: the application has no dependencies on its hosting environment beyond the standard building blocks (a database, object storage, and a container runtime).
Ciphix Cloud (Managed Hosting)
For organizations that prefer not to manage the infrastructure themselves, Ciphix Cloud runs on EU infrastructure. The platform is multi-tenant, but data is physically separated, not just logically filtered. Each environment receives:
- a dedicated, isolated workspace on a managed Kubernetes cluster, with network policies that separate environments at the kernel level;
- a dedicated PostgreSQL database;
- dedicated object storage for files;
- their own encryption keys.
No application query can access data from another tenant, because that data is stored in separate storage. The infrastructure runs on AWS Frankfurt, distributed across three independent availability zones, ensuring the platform continues to operate even if one zone goes down. All data is encrypted in transit (TLS) and at rest; backups run automatically with point-in-time recovery. A separate management layer (the Portal, built on AAD itself) handles the configuration of environments and the rollout of releases, separate from the running applications.
Environments are purchased individually (e.g., test and production) in various sizes, with optional extensions for high availability and regional failover. For those with stricter data sovereignty requirements, a variant under EU jurisdiction—without U.S. extraterritorial reach—is available.
Self-hosted
The application can also run on your own cloud subscription (Azure, AWS, or any container platform), giving you full control over infrastructure, network policies, and security configuration. Ciphix provides the container images and infrastructure templates. PostgreSQL is included by default, so any managed database service will work, as will a self-hosted instance. Optionally, Ciphix can manage operations via delegated access, while ownership remains with the organization.
Portability: There are no technical barriers to switching: the same image runs on both models. You can start on Ciphix Cloud for speed and simplicity and later move to your own infrastructure—or vice versa. Switching requires no code changes.
Ownership and no Lock-In
This is where AAD fundamentally differs from a closed platform. The application is built using TypeScript, Vue, and PostgreSQL by default, and runs in Docker containers. There is no proprietary runtime, no license key, and no kill switch. The practical implications are:
If maintenance is not renewed, the application will continue to function. Nothing stops, nothing degrades. The organization receives a complete source code copy of all platform packages in their current version, so that any qualified development team can maintain the application independently. What expires is access to future updates, not to what has already been built. The incentive to renew is the value we continue to deliver, not a dependency built into the architecture.
Because the organization owns the code and can run it on its own infrastructure, there is also no dependence on a vendor’s compliance roadmap. Specific security or compliance requirements can be implemented directly in the application, without having to wait for a feature request to be processed by a platform vendor.
In summary
- One predictable form. Every application shares the same architecture: shared data contracts, a central access layer, and reusable building blocks.
- Modules have their own security features. Roles, rules, data, and endpoints coexist, rather than being stored in a central configuration.
- Defense in depth: deny by default. Access is granted through a fine-grained system and enforced across multiple independent layers; sensitive fields are encrypted.
- Quality is a system characteristic. Human or AI: the same automated gates; nothing reaches production without passing through them.
- Portable and owned. Standard code in containers, no proprietary runtime, no per-user fees, and a guaranteed way out.
Ready to take a closer look?
Want to learn more about how the architecture relates to a specific situation, about the migration options, or see the platform in action? Ciphix would be happy to discuss your specific use case with you.
We'd love to hear from you!
Sprint 0
Customized approach
Results
The questions you probably have
Aren't we dependent on you guys once this is built?
No. The software is all yours, standard code that any qualified development team can adopt. You are not dependent on Ciphix. If you quit the maintenance package, the application will continue to run.
How do we prevent the project from stalling?
Every project starts with Sprint 0, scope and priorities are established before construction begins. The iterative approach ensures that you continuously see working software and can make adjustments at any time.
Is AI-generated code reliable enough for mission-critical software?
Quality is not a matter of trust, it is a matter of control. All output is automatically checked for quality and safety before it reaches production. The speed is in eliminating repetitive work, not in skipping quality steps.
We already work with platforms. Should we replace them?
No. AAD does not replace your existing IT landscape, it complements it. Existing systems and platforms remain intact. Which applications benefit from AAD is up to you; we help focus that question.
How do we know we are building the right thing?
By starting with Sprint 0 – not with technology, but with the problem. What do you want to achieve? Is customization the right choice or is there a better way? Only when those questions are answered do we start building.
