Why we built a layer instead of a wrapper

The obvious approach to building AI-powered learning products is to call a foundation model API and format the output. Many products work exactly this way, and for simple use cases it is adequate. Our use cases are not simple. We need responses that are factually accurate, calibrated to the learner's level, sensitive to their recent interaction history, free from confabulation, and responsive to the specific cognitive task at hand. No single model reliably delivers all of these properties simultaneously. The architecture that does is not a wrapper around a model — it is a layer that orchestrates multiple components with defined responsibilities.

04 — Validator
Checks accuracy, calibration, task structure
03 — Generator
Produces response with model + retrieved context
02 — Retrieval
Fetches learner context, anchors, knowledge state
01 — Router
Classifies task type, selects model + latency budget
↑ Learner request enters hereOutput delivered here ↑
Four layers, one pipeline. Every inference passes through all four components before reaching the learner.

The components of the layer

Talos has four principal components. The router classifies incoming requests by cognitive type and selects the appropriate model or model combination. The retrieval system maintains per-learner context: interaction history, demonstrated knowledge state, memory anchors, and inferred misconceptions. The generator produces the response, drawing on both the selected model and the retrieved context. The validator checks the output before delivery, flagging responses that are factually inconsistent, inappropriately calibrated, or structurally malformed for the task type. These components communicate through a shared session representation that persists across the learner's interactions with any Arconite product.

The four Talos components

  • Router — classifies task type, selects model, sets latency and confidence budgets
  • Retrieval — fetches learner context, knowledge state, and memory anchor schedule
  • Generator — produces response using selected model and retrieved context
  • Validator — checks output for accuracy, calibration, and task-structural correctness

Shared learner signal across Gripho and Skemax is what makes Talos an intelligence layer — not just two separate AI integrations dressed in the same brand.

Shared signal across products

The most important architectural decision we made with Talos was to share learner signal across Gripho and Skemax. A learner who works through a concept in a Gripho conversation generates signal — demonstrated knowledge, identified gaps, memory anchor timing — that is available to Skemax when that learner opens a relevant course. A learner who struggles with a particular objective in a Skemax course generates a retrieval priority that Gripho can act on in a subsequent session. This cross-product signal is what makes Talos an intelligence layer rather than two separate AI integrations. It is also what makes the Arconite ecosystem qualitatively different from using two unconnected learning tools.

4Architecture layersRouter → Retrieval → Generator → Validator
∞Session memoryLearner context persists across all products
0Data to outside modelsLearner data never trains external systems