the real questionOnboarding isn't a prompt. It's a contract the agent can't break.
Most 'AI onboarding' advice ends at: write a CLAUDE.md, an AGENTS.md, a .cursor/rules folder. Useful, but it's a suggestion, not a guardrail. The agent reads it, then drifts — long sessions drop instructions, the file gets ignored 'in the middle', and conventions decay one PR at a time. Real onboarding means the rules are enforced, not remembered: the agent boots inside your architecture, naming, security posture and review bar, and a structure rejects anything that violates them before it can land.
- A rules file is read once and forgotten mid-session — research calls it 'lost in the middle'.
- More instructions don't help: bloated context files lower task success, not raise it.
- Onboarding that works is enforcement, not documentation an agent may or may not honour.
why vibe coding breaks hereThe thing that makes agents fast is also what makes them dangerous.
Vibe coding — describing software to an AI and watching it appear — is exploding, and in a solo weekend project it's magic. In a company it's where the mess starts: code nobody reviewed, conventions invented per-prompt, security holes shipped because the agent didn't know the rule existed, a 'why is it red' that takes a day. The agent isn't reckless; it was simply never onboarded into a structure that says no. Speed without an inherited rulebook isn't velocity, it's debt arriving faster.
- Each prompt re-invents naming, structure and patterns with no memory of your standards.
- Security and compliance rules the agent never learned are the ones it quietly breaks.
- Unreviewed AI output compounds: the cost shows up months later as unmaintainable sprawl.
the methodEncode the rules once — the Tech Lead — so every agent inherits them.
This is the Digital Native method. A Product Owner describes intent on the live product: this is broken, make this faster, add that. A Tech Lead encodes your rules a single time — architecture, conventions, naming, security policy, the maintainability bar, your company's specific constraints. Every agent that boots inherits that contract automatically; none of them start from a blank prompt. You onboard the rules once, not the agents endlessly. Adding a tenth agent costs the same as the first, because the standard lives in the structure, not in anyone's head.
- Intent comes from the Product Owner in plain language, on the real product.
- The Tech Lead encodes standards a single time — the canonical rulebook.
- Every agent boots inside it; the rules scale to N agents at zero extra onboarding cost.
the proofDeterministic gates verify every change before it reaches production.
Inherited rules only matter if something checks them. So before any change lands, deterministic gates run — lint, types, tests, security scans — with zero AI judgement involved: green or it doesn't ship. Everything goes through your own GitHub, on your existing AI plan, so 'I never read the code' never means 'nobody did'. It means a structure verified it, every time, instead of a tired human catching it sometimes. That's the difference between onboarding an agent and just unleashing one.
- Lint, types, tests and security run on every change — no exceptions, no tokens spent guessing.
- Red doesn't merge; the gate is the reviewer that never gets tired or skips a step.
- Ships through your GitHub on your own AI plan — your code, your history, your control.
the softwareA method needs a tool to make it real. That tool is Agentation.
You can't run this from a folder of markdown files and good intentions. Agentation is the software that makes the method operational: it turns intent on the live product into onboarded, governed work, runs the Tech Lead that holds your rules, dispatches the agents, and enforces the gates before anything reaches prod. The onboarding guide stops being a document you hope agents read — it becomes the rails they run on.
- Describe intent on the product; Agentation routes it to agents already inside your rules.
- The Tech Lead and gates are built in — encoding rules once is the product, not a chore.
- From annotation to verified, shipped change — the method, made into software.
cocoricoFrench software, European stack — sovereign on the tooling layer.
Agentation is a French company, built by a French team. We're honest about sovereignty: nobody in Europe is fully sovereign on the frontier models — Claude, GPT and the rest are American. But the model is only half the story; with just a model you can't do much. The orchestration layer — the Tech Lead, the gates, where your code lives, how it's governed — is the half you can own. That's the half we make sovereign: hosted in the EU (Hetzner, Germany), data in the EU (Supabase), your code in your own GitHub, GDPR by construction.
- French team, French company — building the layer that orchestrates the models.
- Sovereign where it counts: EU hosting (Hetzner), EU data (Supabase), GDPR by design.
- Your code never leaves your GitHub — we orchestrate, we don't see it.
FAQIsn't a CLAUDE.md or AGENTS.md file enough to onboard an agent?
It's a good start, but it's a suggestion the agent can ignore — long sessions drop instructions, and overstuffed files lower task success rather than raising it. Real onboarding makes the rules enforceable: the Tech Lead encodes them once, every agent boots inside that contract, and deterministic gates reject anything that violates it. The file documents intent; the structure guarantees it.
What exactly should I encode when onboarding an AI coding agent?
The non-inferable rules an agent can't guess: your architecture and folder conventions, naming, the tech stack and its versions, build/test/lint commands, your security and compliance policy, and a maintainability bar — plus any company-specific constraints. With Agentation you encode these once in the Tech Lead instead of repeating them in every prompt, and every agent inherits them automatically.
If I onboard the rules once, what stops them from drifting over time?
Two things. The Tech Lead is a single canonical source, so there's no per-prompt re-invention of conventions. And the gates run on every change — lint, types, tests, security — so any drift that does creep in gets caught before it merges, not months later. The rulebook is one place and it's enforced continuously, which is exactly what a scattered set of markdown files can't promise.
Do I need engineers to set this up, or can a product owner run it?
The Product Owner drives intent in plain language on the live product — no engineering background needed. Encoding the rulebook is a one-time setup that captures your standards; after that, onboarding new work means describing outcomes, not configuring agents. The structure handles the technical enforcement so the human stays in outcome-space.
How is this different from just prompting an agent really well each time?
A great prompt onboards an agent for one task, then it's gone — the next prompt starts blank and re-invents your conventions. Encoding the rules once means every agent inherits the same contract every time, and the gates verify the result independently. You stop re-onboarding per prompt and stop being the safety net for unreviewed output.
Is Agentation safe for a European company worried about sovereignty?
That's the point of the design. We're a French team and we're candid: the frontier models are American, so nobody's fully sovereign there. But the orchestration layer is — and that's a huge part of the value, because a model alone does little. Agentation hosts in the EU (Hetzner, Germany), keeps data in the EU (Supabase), runs your code through your own GitHub, and is GDPR-aligned by construction. Sovereign where it's actually achievable.