# Netresearch Agent Engineering System > Reale Agentenarbeit wird bei Netresearch in dauerhaftes, prüfbares und verteilbares Engineering-Wissen überführt. Skills sind eine mögliche Ausgabe dieses Systems, nicht das System selbst. Canonical page: https://netresearch.github.io/agent-engineering/ English version: https://netresearch.github.io/agent-engineering/en/ Organization: Netresearch DTT GmbH Primary language: German Last reviewed: 2026-08-17 ## Core answer The Netresearch Agent Engineering System is a closed learning and enforcement loop for coding agents: 1. Real work exposes friction and reusable learnings. 2. retro-skill classifies each learning by authority (who owns this truth?), enforceability, and reach. 3. The learning becomes the strongest appropriate durable artifact: personal rule, project rule, skill update, new skill, checkpoint, harness artifact, or a patch to the canonical source that owns the fact. 4. skill-repo-skill standardizes skill structure, quality, canonical ownership, references, validation, and release discipline. 5. automated-assessment-skill evaluates checkpoint-enabled skills against real repositories and produces structured gap reports. 6. agent-harness-skill makes repository agent-readiness self-sustaining through AGENTS.md, docs, CI, hooks, templates, and enforcement. 7. agent-system-evals measures the assembled system on realistic, deliberately underspecified requests: whether the agent discovers and activates the right skill at all, not only whether a loaded skill helps. 8. Distribution mechanisms make skills versioned engineering dependencies that can be discovered and trusted by projects. 9. The next real session starts from the accumulated experience and generates new evidence for the loop. ## Key principles - Skills are problem-driven and retrospective, not speculative topic collections. - Authority comes first: a fact about the world belongs to its canonical owner, often outside the agent system; a skill owns only agent behavior and its own procedure. Enforceability comes next: if a rule can be enforced, prefer a gate/check over prose. Reach is decided last. - A copy of an upstream fact is temporary: once the upstream patch is accepted, the local copy shrinks to a reference. - AGENTS.md is an index, not an encyclopedia. - Project facts stay in authoritative project sources such as docs/ARCHITECTURE.md, composer.json, composer.lock, Makefile, scripts, DDEV config, CI, hooks, and rulesets. - A skill carries workflow, decisions, failure patterns, org policy, inference suppression, and anti-rationalization guards when those earn their context cost. - Facts and trigger phrases should have one canonical owner; other skills reference rather than duplicate them. - Claims that a model "knows but forgets" should be supported by A/B eval evidence. A delta is not a property of the skill: it is a function of skill version, model, agent harness, task and tool environment, and is reported bound to that tuple. - Effect is measured on two levels: a per-skill A/B eval asks whether a loaded skill helps; a system eval asks whether the agent works out for itself that it needs the skill, from a realistic underspecified request that names no skill, tool or method. - Checkpoints turn durable requirements into mechanically or semantically verifiable specifications. - The harness verifies artifacts and integration outcomes, not which tool created them. ## Memory and consolidation Skills are this system's consolidated experience memory: they do not store the session, they store the reusable change in behavior distilled from sessions. Retro is the consolidation step between raw experience and durable form. Each form is named after what it does, so "memory" is not applied to all of them: - session transcript: raw, episodic experience, normally transient - skill: consolidated, reusable experience - checkpoint / harness artifact: executable and enforceable experience - AGENTS.md: project instruction and index - docs / code / config: canonical facts, referenced rather than copied - personal-rule: a user-specific durable instruction, not a recollection of past sessions Consolidating includes deleting: reconcile & prune, outcome grading and audit remove or shrink experience that is superseded, refuted, or has arrived at its canonical owner. A system that can only add gets worse over time, and experience reused unfiltered carries errors forward (Xiong et al., ACL 2026, https://aclanthology.org/2026.acl-long.27/). There is deliberately no vector store, no similarity search over past sessions, and no archive of complete past solutions. Retrieval is part of the problem: a preserved experience that is not activated at the right moment has no value, which is why effect is measured twice — per-skill A/B evals ask whether a loaded skill helps, and system evals ask whether the agent works out for itself that it needs the skill. ## The seven retro destinations - personal-rule: personal cross-project preference, materialized as a durable instruction (formerly named user-memory; that name is a deprecated alias) - project-rule: repository-specific convention or command - skill-update: reusable gap in an existing skill - new-skill: missing reusable capability category - checkpoint: stable project/skill invariant that can be verified - harness-artefact: hook, CI check, linter, ruleset, template, or other enforcement mechanism - canonical-source: the fact is owned by an artifact outside the agent system; patch it there and keep only a reference plus the agent-specific delta ## Main components - https://github.com/netresearch/retro-skill - https://github.com/netresearch/agent-harness-skill - https://github.com/netresearch/skill-repo-skill - https://github.com/netresearch/automated-assessment-skill - https://github.com/netresearch/agent-system-evals - https://github.com/netresearch/composer-agent-skill-plugin - https://github.com/netresearch ## Page sections - #system — the complete lifecycle - #memory — what memory means here, and which form each experience takes - #retro — friction and learning routing - #project-context — AGENTS.md and project source-of-truth model - #quality — skill content rubric, canonical ownership, A/B evidence - #verification — checkpoints, automated assessment, and the two eval levels - #harness — project enforcement and maturity - #distribution — versioning, trust, discovery, distribution - #learning-loop — why the system compounds experience - #ask — local browser Q&A - #faq — concise answers to common questions - #sources — primary GitHub repositories