Stop Typing the Same
15 Requirements to Your AI
Every session started the same way: requirements typed into chat before a single line of code was written. We built a context hierarchy — routing table, domain files, search skill — that eliminated that friction entirely.
What this article covers
A context hierarchy for AI development sessions organises requirements into four layers — a routing table (L0), domain files (L1), a search skill (L2/L3), and specialist agents — so the AI reads what it needs rather than being told the same things verbally every session. This article explains why the hierarchy works, how to design one, and what open standards to use for automated review loops.
The session that made us change everything
We were building a new marketing page. Before the AI wrote a single component, we typed: ensure SEO metadata is in place. Use the design system — dark canvas, correct fonts, no purple. Generate a hero image via GPT Image-1. Check responsiveness at 390px with 44px touch targets. Run a CRO review. Add JSON-LD schema. Include internal links. Don't expose internal strategy or pricing. Follow the blog creation standard. Check robots.txt. Update the sitemap. Verify the canonical URL.
That was fifteen requirements — typed from memory, every session, before useful work began. And the next session, we typed them again.
The problem wasn't capability. The AI could do all fifteen things. The problem was that we were acting as the AI's external memory — the most expensive possible use of a human's time. Across a 40-session month, that's roughly ten hours of setup that produced nothing.
Why AI doesn't remember your requirements
AI assistants don't have persistent working memory between sessions. Each conversation starts fresh. Whatever context the model needs — your design system, your SEO standards, your security rules, your brand voice — has to enter the conversation somehow.
The default is verbal: the user provides context through the chat message. This works for one-off tasks. It doesn't scale, because the quality of the output depends entirely on how much the human remembers to say. Before designing context architecture, it's worth knowing where your team sits on the AI readiness spectrum — the gaps are usually in process and structure, not capability.
The better model is file-based context: requirements live in files the AI reads, not in the human's memory. But file-based context has its own failure mode — if you put everything in one file, that file becomes the new bottleneck.
Context is architecture, not conversation
The insight that unlocked this: context should be designed the same way software is designed. With layers, separation of concerns, and load-on-demand patterns.
A configuration file that contains 300 lines of rules — security requirements, design tokens, SEO standards, blog protocols, performance budgets, legal governance, podcast rules, trademark compliance — is a monolith. Everything loads every session, regardless of what the task needs. As requirements grow, so does the file.
The fix is the same as it is in software: decompose. Move rules out of the monolith into purpose-specific files. Give the monolith a new job: pointing to those files, not containing them.
The three-tier insight we borrowed and extended
Peter Wang, in a 2025 article on building vertical AI agents, described a context cache with three tiers: L1 (always resident — the 80% of context needed for almost every task), L2 (on-demand curated specs), and L3 (raw reference plus a search skill for long-tail lookups).
The model is elegant, but it has a gap: the L1 "always resident" tier tends to accumulate everything over time. In practice, it becomes the same monolith problem.
Our extension was to add L0 — a routing table that sits above L1. L0 is always loaded, but it contains no rules. It only contains pointers. The AI reads the table, identifies the relevant domain, loads that specific L1 file. Nothing else enters context unless the task needs it.
The four layers in practice
Each layer has a distinct job. The hierarchy only works when those jobs don't overlap.
Always loaded. Contains no rules — only pointers.
A short file (40–60 lines) that maps task areas to L1 docs. When you ask the AI to build a new page, it reads the routing table, finds the relevant domain, and loads that file. Nothing else enters context unless the task needs it.
New page / post / campaign → docs/asset-protocolDesign system (tokens, canvas modes) → DESIGN.mdWeb standards — robots, sitemap, JSON-LD → web-standards-checklistMarketing voice / ICP / objections → marketing-sourcebook
Does NOT contain rules, processes, or detail. Those live in L1.
L0: The routing table — what it is and what it isn't
A routing table is not a rules file. This is the most important distinction in the whole architecture. A rules file tells the AI what to do. A routing table tells the AI where to look.
The routing table has no opinions about design, SEO, or security. It only knows that when the task involves a new digital asset, the AI should read the asset protocol — and that file will have the opinions. In practice, a routing table looks like a two-column table: task area on the left, file path on the right. Ours is about 60 lines.
The routing table also contains one universal section: always-active security rules. These are truly non-negotiable cross-cutting concerns — four lines, not forty — that apply to every task regardless of domain. Everything else loads on demand.
L1: Domain files that load on demand
Each domain gets one file. That file owns the complete set of rules, processes, and standards for that domain — and nothing else's rules bleed into it.
Our most important L1 file is an asset protocol — a nine-step ordered workflow for every new digital asset. It starts with five intake questions: what is this asset, who is the ICP, what is the conversion objective, do we have images, and what must not appear publicly. It then steps through design brief, SEO setup, navigation, image generation, CRO review, responsiveness, performance, an IP check, and a push gate.
Before this file existed, we recreated that workflow verbally — in a different order, with different items each time. Now the AI reads the protocol and works through it in sequence. The blog creation standard is another L1 file: it specifies minimum heading counts, required interactive modules, SEO metadata format, CTA label, and QA gate checklist. The AI reads it when starting a blog post and follows it, without us enumerating requirements in chat.
L2/L3: Searching large docs without loading them whole
Some L1 files are large — 200 lines or more. Loading the whole file when you only need one section wastes context. Large files buried in the middle of a context window tend to be attended to less reliably than material near the top.
The search skill solves this. It teaches the AI to grep for section headings, get the line number, then read only that section using an offset and line count. A 200-line design system becomes a 20-line typography section when the question is only about typography.
The search skill also covers cross-doc lookups — grep across the docs directory to find which file covers a topic, rather than loading multiple files and checking. This is the AI equivalent of using an index rather than reading a book cover to cover.
The hierarchy in numbers
What the architecture looks like in concrete terms
Verbal requirements typed per session — before
Verbal requirements needed — after routing table
Layers in the hierarchy (L0 → L1 → L2 → Agent)
Open standards the CRO agent audits against
The CRO discovery that changed our review process
When we first set up a CRO review agent, we gave it twenty-five "proven conversion principles". The problem: we invented them. They carried no authority. The AI applied them dutifully, but nothing in the output was traceable to a standard anyone could challenge, verify, or improve against.
The fix was to replace invented principles with open international standards. WCAG 2.1 AA, published by the W3C, covers accessibility and readability. Core Web Vitals, published by Google, covers loading performance, layout stability, and interaction responsiveness. Nielsen's 10 Usability Heuristics, freely published in 1994, cover interaction design and interface consistency. The PAS copywriting framework (Problem–Agitate–Solve) and the 4-U headline formula are both public domain.
Five sources. All freely published. No proprietary research, no paywalled frameworks. We also removed "Expected lift: X%" from every output — expected lift is unknowable before testing. The agent now outputs PASS, FAIL, or HUMAN GATE. If you're choosing which AI tools to put into a structured workflow like this, our guide to evaluating AI tools applies the same principle: criteria you can defend beat criteria you invented.
The MAX_PASSES rule: why boundaries make loops useful
A review-fix-recheck loop without an exit condition is not an agent loop. It's an infinite regress. The AI reviews, finds a blocker, the developer fixes it, the AI reviews again — and there's no principle that says when this ends.
The MAX_PASSES boundary — we use three — imposes an exit condition. After three passes, if critical issues remain, the loop stops. The agent outputs HUMAN GATE and lists the exact open blockers. A human decides whether to iterate more, accept the current state, or redesign the approach.
Reaching HUMAN GATE is information, not failure. It means the standard three passes weren't sufficient, and a human judgment call is needed. The broader principle: any AI process that can run indefinitely should not run indefinitely. Boundaries are what make automation safe to trust.
Three scenarios, before and after
The practical difference the hierarchy makes day to day
Type 15 requirements into chat: ensure SEO, use design system, generate hero via GPT Image-1, check responsiveness at 390px, run CRO, check internal links, add JSON-LD, don't expose internal IP…
Say "build the X role page". The AI reads the routing table, loads the asset protocol, and runs through the 9-step workflow — intake, design brief, SEO, nav, image, CRO, responsive, performance, IP check — without prompting.
What changed after we implemented this
The most immediate change: we stopped typing requirements into chat. New asset tasks started with a noun and a brief, not a list. The AI read the routing table, loaded the relevant domain files, and worked through the protocol.
The less obvious change: quality became consistent. When requirements lived in a developer's memory, the output varied based on what was remembered that day. When they live in a file, every session applies the same standard. The tenth page we built with the protocol followed the same SEO, responsiveness, CRO, and IP-protection checks as the first — not because we remembered to ask, but because the file required it. We've written about this shift from a testing and quality perspective too — the pattern of "AI raises the floor, humans raise the ceiling" applies equally to context design.
This connects to the broader value of specialist AI agents: the value isn't in the AI doing things differently. It's in the AI doing the same things reliably — freeing the human for judgments that actually require judgment. If you're new to the concept of agents, our guide to AI agents covers the architecture and business case from first principles.
Three principles for any team building with AI
1. Design context, don't type it
If you're repeating the same requirements in chat across sessions, you've identified a design failure — not a workflow habit. The requirements belong in a file, the file belongs in a hierarchy, and the hierarchy eliminates the repetition without eliminating the standard. The PRIME vibe-coding framework describes this shift from reactive to structured AI-assisted building.
2. Use open standards, not invented criteria
Any AI-powered review process should be grounded in published standards the team can look up. Invented checklists are unverifiable and quietly authoritative in a way that erodes trust over time. WCAG, Core Web Vitals, Nielsen, PAS, and 4-U are freely published and widely understood.
3. Every loop needs an exit condition
Automation that can run indefinitely shouldn't. Any review cycle driven by AI needs a hard boundary. The boundary isn't a concession to AI limitations — it's what makes the output trustable.
How this connects to how we build at SmartMaya
The context hierarchy described here powers how we build every part of the Maya for Business platform — from sales role pages to marketing workflows. Every page, blog post, and campaign asset goes through the same structured protocol — because those requirements live in files, not in anyone's memory.
The same thinking underpins our 120-day platform build: 300+ AI tools shipped with consistent quality not because every session was perfect, but because the standards were in files the AI read — not in the developer's memory.
If you're building AI-assisted workflows — for operations, sales, or development — the architecture of your context matters more than the model you choose. Start with the AI Readiness Assessment to find where the gaps actually are.
Frequently Asked Questions
Work with SmartMaya
Ready to build AI workflows that actually work?
Already using Claude Code or Copilot? Good — that's exactly where this starts. We help businesses build structured AI context so the work stays consistent, not just impressive in demos.
No repeat requirements. No invented benchmarks. No infinite loops.
Schedule Your FREE Strategy Session20 minutes · No pitch · Just your workflow questions answered