FAQ

Questions Before You Build

A different approach to software naturally raises practical questions.

What exactly is HexaKernel?

How is it different from a conventional application architecture?

Where does AI fit?

What happens to existing systems?

What does the developer actually build?

And what changes when the domain itself becomes the source of truth?

This FAQ provides concise answers to the questions that matter when evaluating the paradigm.

What is HexaKernel?

HexaKernel is a domain-native software foundation designed around the idea that complex software should be derived from a formal representation of the domain.

It provides an execution layer beneath applications, agents and integrations.

Is HexaKernel an AI platform?

AI is an important part of the HexaKernel model, but HexaKernel is not simply an AI platform.

AI transforms and operates on domain knowledge.

The Kernel provides the stable execution foundation.

AI provides intelligence. The Kernel provides control.

Is HexaKernel an agent framework?

No.

Agents can operate on top of HexaKernel, but they are not the foundation of the system.

The architecture separates agents from the Kernel so that agents, models and orchestration technologies can evolve independently.

Is HexaKernel a workflow engine?

Not primarily.

Workflow engines can orchestrate processes.

HexaKernel focuses on the domain itself: its entities, rules, policies, states, transitions, operations and events.

A workflow engine can become one of the technologies operating around or above the domain.

Is HexaKernel an API platform?

APIs are one part of the architecture.

They expose domain capabilities to applications, agents and external systems.

HexaKernel goes deeper by providing the domain model and execution foundation behind those capabilities.

What is the role of the specification?

The specification defines what the domain means.

It describes the domain's structure and behavior independently of a particular implementation.

It can then serve as the source from which software and other artifacts are derived.

Why not just write the software directly?

Direct implementation can work well for simple systems.

The challenge appears when domain complexity becomes significant and change becomes continuous.

HexaKernel moves domain knowledge into an explicit specification so that the meaning of the system can be understood, validated and evolved independently from its implementation.

Does HexaKernel replace developers?

No.

Developers remain responsible for architecture, domain understanding, design decisions, validation, integration and engineering judgment.

The goal is to move developers toward building domain capabilities rather than repeatedly rebuilding infrastructure.

Does HexaKernel replace domain experts?

No.

Domain experts remain essential because they understand the business reality that the software must represent.

The paradigm creates a stronger bridge between domain knowledge, formal specification and software generation.

Can existing systems work with HexaKernel?

The intended model does not require every existing system to disappear.

Existing applications and external services can participate through APIs and integrations.

The relevant question is how their capabilities relate to the formal domain and execution model.

Can different AI models be used?

The architecture is intended to keep domain knowledge separate from any individual AI model or provider.

This means different AI systems can potentially operate against the same formal domain representation.

The domain remains stable even as the intelligence layer evolves.

What happens when the business changes?

The domain specification changes.

New rules, entities, states, operations, policies or relationships can be represented there.

Software and other derived artifacts can then evolve from the updated specification.

Change the domain. Derive the evolution.

Who is HexaKernel for?

HexaKernel is particularly relevant to organizations building software around complex domains:

• Startups creating sophisticated domain-native products

• Enterprises modernizing complex operations

• Organizations operating in regulated environments

• Teams building AI-native software

• Developers creating systems with rich business logic

• Companies whose domain changes faster than their software can adapt

Where should I start?

Start with Concepts if you want to understand the paradigm.

Explore Specifications if you want to see how domain meaning becomes formal.

Read Case Studies to see how the approach applies to real complexity.

Then move to Developers when you want to understand how software is built on the Kernel.

Understand the model. Then decide how to use it.