KAEL is AeThex's intelligence layer: the assistant, operator, and system-facing agent being built to understand AeThex context, help users move through the ecosystem, and eventually coordinate work across AeThex services.

<div class="docs-hero">

<p class="docs-kicker">KAEL // AeThex intelligence layer</p>

<h1>Build the assistant that understands <span>AeThex itself.</span></h1>

<p class="docs-hero-copy">KAEL is being developed as a living system: chat surface, platform agent, documentation guide, workflow helper, and future orchestration layer for AeThex users and teams.</p>

<div class="docs-actions">

<a class="docs-button" href="https://chat.aethex.tech"><i class="fas fa-comments"></i> Open chat.aethex.tech</a>

<a class="docs-button is-secondary" href="https://kael.aethex.tech"><i class="fas fa-terminal"></i> Open kael.aethex.tech</a>

</div>

</div>

<div class="docs-section-heading">

<h2>What KAEL is</h2>

<p>KAEL is not just a chatbot. It is the named intelligence layer for AeThex.</p>

</div>

KAEL should become the connective assistant across AeThex: able to explain docs, guide users through platform flows, help developers integrate with APIs, support communities, and eventually take carefully-scoped actions inside AeThex systems.

- **chat.aethex.tech** — the conversational entry point for KAEL-style interaction.

- **kael.aethex.tech** — the dedicated KAEL surface for system identity, experiments, builds, and future agent workflows.

- **docs.aethex.support** — the source of operational documentation KAEL should be able to reference.

- **aethex.support** — the user-facing support layer KAEL may eventually help route or explain.

<div class="docs-grid">

<a class="docs-card" href="/KAEL-Build">KAEL Build</a>

<a class="docs-card" href="/KAEL-Changelog">KAEL Changelog</a>

<a class="docs-card" href="/KAEL-Endpoints">KAEL Endpoints</a>

<a class="docs-card" href="/Aethex-Os">AeThex OS</a>

</div>

KAEL should be built as a trustworthy system component, not as a gimmick. That means:

- It should know when to answer, when to ask, and when not to act.

- It should understand AeThex products, docs, services, communities, and governance context.

- It should keep a clear separation between explanation, suggestion, and action.

- It should respect authentication, permissions, and tenant boundaries.

- It should leave a traceable record for meaningful changes.

1. Establish KAEL's public identity and documentation.

2. Connect the chat and KAEL surfaces to the same product narrative.

3. Build a living changelog for updates.

4. Define what KAEL can safely do now versus later.

5. Prepare integration paths with [[Passport]], [[Projects]], [[Support]], and [[Api-Reference]].