// the platform for agent-based development · in development

Your project. On course.

Kernonaut aims to connect product goals, agent work and test results. You see what’s changed, which work is affected and what still needs to be confirmed for the current state.

./notify-me./see-example
  • statusin development
  • corerust
  • firstlinux · windows
  • forteams with agents
vorhaben  Rundenspiel mit eigener Engine
ziel      Runde unter 3 Minuten         v2
├─ auftrag   Spiel: Regeln, Balancing    betroffen
├─ auftrag   Engine: Rendering           gilt weiter
└─ nachweis  Spieltest 1                 neu prüfen

A product takes shape through many decisions

You start with an idea, try something out and learn as you go. With every insight, what you want to build changes. At the same time, people and agents are working on code, tests and sub-products.

Kernonaut aims to align this work with the project. Goals have a history, work orders refer to a specific state, and results show what was checked and what’s still open. When the direction changes, you can see which work needs a fresh look.

An example: rounds should get shorter

  1. Change the goal. A game and its engine are tracked separately. After the first playtest, the rounds should get shorter. The new goal version becomes visible, while old decisions and acceptances stay readable.
  2. Check the impact. Known dependencies show which work and evidence are affected. Suspected impacts are flagged for review.
  3. Continue the work. A run ends at a defined checkpoint. Another suitable worker picks up the work state, context and open steps.
  4. Accept again. Evidence belongs to a specific goal, code and environment version. Whether the game is better now is your call.
ziel geändert  v1 → v2
betroffen      Regeln, Balancing
vermutet       Tutorial-Texte   prüfen
gilt weiter    Rendering Linux, Windows
→ nachweis fehlt: Spieltest 2

What we pay attention to while building

  • Uncertainty becomes visible

    Suspected impacts should be recognisable as such. A missing link doesn’t prove independence.

  • Tests aren’t acceptance

    Technically passing tests and the functional acceptance of your product remain separate decisions.

  • You decide

    Goals, functional decisions and approvals belong to a responsible person. No agent approves itself.

  • Start small

    Kernonaut should get going with little modelling effort, so the model costs less upkeep than it saves.

  • Workers with approval

    Your own machines and cloud workers should only work on a specific area after explicit approval.

  • Mobile and hardware too

    Runners should also connect mobile and embedded targets. To do this, the machine, target platform and device capabilities are described separately.

Where things stand

  1. The core is in place: a tested revision core in Rust with local SQLite persistence and a command line. Product definitions, product states and goal and work order revisions survive restarts.
  2. Next up: server, user interface, workers and verification of identities and permissions.
  3. The plan is to ship one program per platform, with control, CLI and worker modes and no additional mandatory services. Linux and Windows come first, macOS later.
$ kernonaut demo --json
# synthetisches Beispiel, ohne Dateien, Aufträge oder Netzwerk

Want to be one of the first?

We’re building Kernonaut for small professional teams that use several agents, work with existing repositories and change their requirements regularly. Sign up and we’ll get in touch as soon as teams can try Kernonaut.

./notify-mecd ../for-developers