Build Systems That Reason — and Run.

AI Is a System Architecture Problem

AI becomes valuable when it can work with real data, real applications, real infrastructure and real constraints. The model is only one component. The difficult part is designing everything around it so that the complete system behaves reliably.

My work focuses on that architecture: how models access knowledge, retrieve evidence, use tools, interact with software, exchange data and become part of systems that can actually run in production.

That means working across AI architecture, application logic, APIs, databases, full-stack platforms, infrastructure, deployment and operation instead of treating AI as an isolated feature.

Current Technical Focus

My current work concentrates on the layer between model capability and reliable system behavior: deciding when a model can use its own knowledge, when it must retrieve external information, what evidence is sufficient, how agents should execute actions and where system boundaries must be enforced.

• Retrieval-Augmented Generation and retrieval triggers
• Agent systems, tool use and execution loops
• Context boundaries, evidence and answer reliability
• Model routing and capability-aware architectures
• Private, local and self-hosted AI infrastructure
• Integration of AI into real application and data workflows

AI Systems Architecture

Modern AI applications are not built from a language model alone. Reliable systems require decisions about knowledge, retrieval, context, tools, application state, validation, model selection and failure handling.

• RAG and external knowledge integration
• Retrieval decisions and evidence selection
• AI agents and tool-based workflows
• Local and remote model architectures
• Model and capability routing
• Context design and context-boundary management
• Structured outputs and API integration
• Validation, observability and failure handling

The central architectural question is therefore not simply which model to use. It is what the model knows, what it does not know, what it must retrieve, which tools it may use, what evidence is sufficient and when the system must stop trusting a generated answer.

Platform Architecture

AI is one layer of a larger software system. I design platforms around clear application boundaries, reusable services, structured data models and production-oriented architecture rather than isolated features.

• Cloud-native and self-hosted architectures
• Multi-tenant and multi-instance platforms
• Backend services and API architecture
• PostgreSQL and application data modelling
• Authentication, authorization and role-based access
• Multilingual and internationalized systems
• Headless content and structured publishing platforms
• AI services integrated into existing application logic

Full-Stack Systems Engineering

Architecture matters most when it survives implementation. I work across frontend, backend, data and infrastructure so that architectural decisions remain coherent from the user interface down to the database, runtime and deployment layer.

Typical systems combine Nuxt and Vue frontends, Node.js and TypeScript services, PostgreSQL and Prisma data layers, Python where it provides the better technical fit, and Linux-based production infrastructure.

Production Engineering

A prototype demonstrates an idea. A production system has to survive deployment, real data, changing requirements, user behavior, traffic, upgrades, failures and continued development.

• Linux server environments
• NGINX and application routing
• Application deployment and runtime operation
• Database migrations and data lifecycle
• Build and release workflows
• Logging, diagnostics and technical monitoring
• Performance, crawlability and delivery constraints
• Integration of local and hosted AI runtimes

Systems Built in Practice

The architecture described here is not theoretical. It is developed through systems that I design, build, operate and continuously extend.

Aaasaasa AI Client

A desktop AI application built around Electron and TypeScript with local and remote model support, provider abstraction, secure application boundaries and integration with external AI runtimes.

Enterprise Aaasaasa

An enterprise-oriented platform architecture combining application services, structured data, role-based access, multilingual content, AI capabilities and modular business functionality.

stajic.de Platform

A production platform used for structured publishing, multilingual delivery, AI-assisted workflows, technical research and experiments around search, retrieval and AI-readable knowledge.

Independent Production Platforms

loving.rocks, figure.rocks and related systems extend the same engineering approach into independent production environments with their own audiences, content models, multilingual structures, search requirements and operational constraints.

Technical Research & Writing

A significant part of my current work examines the boundary between language-model capability and reliable application behavior. The objective is to turn complex AI architecture into concepts that can be explained, tested, challenged and implemented.

• How RAG connects models to external knowledge
• Where an LLM gets its information and where retrieval begins
• When an AI system should stop relying on model knowledge
• How evidence should be selected and validated
• Why larger context windows do not automatically produce better answers
• How agent loops differ from managed agent infrastructure
• How private AI architecture changes infrastructure decisions
• Where answer reliability breaks down between retrieval and generation

These topics form a connected technical knowledge base rather than a collection of isolated articles. Each addresses a different boundary inside modern AI systems.

One System, Not a Collection of Features

Frontend, backend, AI, data and infrastructure are often discussed as separate disciplines. In production they continuously affect one another.

A retrieval decision changes data architecture. Data architecture affects APIs. APIs affect application state. Application state affects agent behavior. Infrastructure limits model choices. Search architecture affects how information is discovered by both people and machines.

My approach is therefore system-oriented: understand the complete chain before optimizing an individual component.

Technical Foundation

• TypeScript and JavaScript
• Nuxt and Vue
• Node.js and Nitro
• Python
• PostgreSQL and Prisma
• REST and application APIs
• Electron
• Linux and NGINX
• Docker and service-based deployment
• OpenAI APIs and agent tooling
• Local LLM runtimes including Ollama
• Structured content and EditorJS

Architecture Must Also Be Deliverable

Technical architecture exists inside products, projects, budgets, dependencies and deadlines. My work therefore combines engineering with structured delivery rather than separating technical decisions from implementation responsibility.

More than two decades of practical IT work are complemented by formal project and delivery methods, including IPMA and Professional Scrum Master certification. These methods support the engineering work; they do not replace it.

Build Something That Can Actually Run

The objective is not to attach AI to everything. It is to identify where AI provides real system capability, design the architecture around it and build the surrounding software strongly enough for that capability to become useful.

From retrieval and model behavior to APIs, data, interfaces and infrastructure, the focus remains the same: technically coherent systems that move from architecture to production.