Marktmannen wiki Agentic OS

Agent-native Architectuur

Laatst bijgewerkt: 03-06-2026

TL;DR: Vijf principes (Parity, Granularity, Composability, Emergent, Improvement) bepalen of een applicatie écht agent-native is of slechts een AI-laagje over traditionele software heeft.

Agent-native architectuur is een aanpak voor het bouwen van applicaties waarbij agents first-class citizens zijn. Features zijn geen code die je schrijft — het zijn outcomes die je beschrijft, bereikt door een agent met tools, in een loop totdat het resultaat is behaald.

Gepubliceerd door Every.to.

De 5 kernprincipes

1. Parity

Wat de gebruiker kan doen via de UI, moet de agent kunnen bereiken via tools.

Dit is het fundament. Zorg dat de agent tools heeft voor alles wat de UI kan. Niet één-op-één UI-knoppen → tools, maar dezelfde outcomes bereikbaar maken.

Test: Kies een willekeurige UI-actie. Kan de agent dit bereiken?

Capability map voorbeeld: | Gebruikersactie | Hoe agent het bereikt | |---|---| | Maak een notitie | write_file naar notes-map, of create_note tool | | Tag een notitie als urgent | update_file metadata, of tag_note tool | | Zoek notities | search_files of search_notes | | Verwijder notitie | delete_file of delete_note |

2. Granularity

Tools zijn atomaire primitieven. Features zijn outcomes bereikt door een agent in een loop.

Een tool = een primitieve capaciteit. Een feature = een outcome beschreven in een prompt, bereikt door een agent met tools, in een loop totdat het resultaat is behaald.

Hoe atomairder je tools, hoe flexibeler de agent ze kan gebruiken. Als je beslissingslogica in tools stopt, heb je oordeel terug in code gezet.

Test: Om gedrag te veranderen, pas je prompts aan of refactor je code?

3. Composability

Met atomaire tools en parity kun je nieuwe features maken door simpelweg nieuwe prompts te schrijven.

Nieuwe "weekly review" feature? Dat is een prompt:

"Review bestanden aangepast deze week. Vat key changes samen.
Op basis van onvoltooide items en naderende deadlines,
stel drie prioriteiten voor volgende week voor."

De agent gebruikt list_files, read_file, en zijn oordeel.

Test: Kun je nieuwe features beschrijven zonder code te schrijven?

4. Emergent Capability

De agent kan dingen bereiken die je niet expliciet hebt ontworpen.

Voorbeeld: "Kruisverwijzing mijn meeting-notities met mijn takenlijst en vertel me wat ik beloofd heb maar nog niet gepland heb." Je hebt geen commitment tracker gebouwd — maar de agent kan dit als hij notities en taken kan lezen.

Dit onthult latente vraag. In plaats van features raden wat gebruikers willen, observeer je wat ze de agent vragen. Als patronen opstaan, optimaliseer je met domein-specifieke tools — maar je hoefde ze niet van tevoren te anticiperen.

Test: Kan het open-ended verzoeken in jouw domein afhandelen?

5. Improvement over time

Agent-native applicaties verbeteren door geaccumuleerde context en prompt-verfijning.

In tegenstelling tot traditionele software kunnen agent-native apps verbeteren zonder code te shippen.

  • Geaccumuleerde context: State blijft bestaan via context-bestanden
  • Developer-level verfijning: Ship bijgewerkte prompts voor alle gebruikers
  • User-level aanpassing: Gebruikers wijzigen prompts voor hun workflow
  • Zelf-modificatie (geavanceerd): Agents die eigen prompts of code bewerken — vereist safety rails (approval gates, checkpoints, rollback-paden)

Van traditioneel naar agent-native

Traditioneel Agent-native
Feature = code Feature = prompt
Gedrag wijzigen = refactor Gedrag wijzigen = prompt aanpassen
Anticipeer alle features Ontdek features via emergent use
Statische capaciteiten Verbetert over tijd

Verwante concepten

Bronnen