Growing Organisational Context with AGENTS.md, Skills, Hooks and cron | AI-Native New Business Development, Part 4: Recurring Work Is Decided by the Context Machinery

Hello, this is Ryuta Hamamoto from TIMEWELL. This is the final part of the AI-native new business development series. I spent more than ten years building new businesses inside large companies, led "CHANGE by ONE JAPAN", a challenger-support programme with over a hundred large companies, and now run WARP ENTRE, an AI-driven development programme for founders and intrapreneurs. Parts 1 to 3 covered listening, turning it into hypotheses, and turning hypotheses into documents. This part is about the machinery that lets you run all of that not once, but every week, reliably.

Series: An AI-native methodology for new business development

1. Building the mock while you interview
2. Lean Canvas, 7 Powers and design concept in a single day
3. Spec-driven development is back, and documents are becoming code
4. Growing organisational context with AGENTS.md, Skills, Hooks and cron (this article)

New business work comes in two kinds: one-off and recurring. Extracting interviews, updating the hypothesis ledger, watching competitors, the weekly progress report, drafting the deck for the management meeting. Hand recurring work to an agent and the first run goes well; around the third, quality starts to wobble. The cause is almost never the prompt. It is that the "context" the agent reads is either stale since the first run, cluttered with things that do not belong, or missing the organisation's context altogether.

In An introduction to context engineering I used a master carpenter's "preparation is eighty percent" to describe designing context so that one instruction completes the job. That article was about an individual succeeding at a single piece of work. This one is its sequel: an organisation keeping recurring work stable. For a read on where your team stands, the AI literacy check takes a few minutes.

Summary: The performance of recurring work is decided by four parts, AGENTS.md (always-read facts and conventions, under 200 lines), Skills (procedures loaded only when needed, a SKILL.md plus helper scripts), Hooks (mechanically stopping what a document cannot), cron (starting work on a schedule), plus internal knowledge grown as a knowledge-graph-shaped dataset. Running it as an organisation takes three disciplines: keep updating the context (write it down when the same mistake appears twice), exclude what lies outside it (prevent context rot; never write what can be derived from code or documents), and raise the frequency of skill updates (weekly lint and evaluation). Whether you can do those three is what stable performance depends on.

Reframing context engineering as organisational machinery

Definitions first. In June 2025 Shopify's CEO Tobi Lütke wrote that "context engineering" described the core skill better than prompt engineering: "the art of providing all the context for the task to be plausibly solvable by the LLM"¹. Andrej Karpathy replied "+1", defined context engineering as "the delicate art and science of filling the context window with just the right information for the next step", and went on: too little, or the wrong form, and it underperforms; too much, or too irrelevant, and cost goes up while performance goes down¹.

Anthropic's September 2025 engineering post turned "too much makes it worse" into an experimental finding. Context is "a critical but finite resource"; as tokens grow, a model's ability to accurately recall information from that context declines. They call it "context rot", and define good context engineering as "finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome"².

All of this has been discussed as one engineer building one app. My point is that it needs rereading as an organisational matter. Organisations carry vast tacit assumptions. How this customer is addressed. Which old product name is never used. How the approval route changes with the amount. Why last year's attempt failed. Keeping those assumptions in a state where an agent reads "just the right amount, every time" is organisational context engineering. If one person writes great prompts and quality drops the week they are on holiday, it is not machinery.

The four parts: AGENTS.md, Skills, Hooks, cron

The machinery has four parts. Names vary a little by tool; roles do not. Here I organise them by role, grounded in Claude Code's official documentation and the open specifications.

Part	Role	When it is read	Nature of content
AGENTS.md / CLAUDE.md	Standing assumptions: conventions, prohibitions, project facts	At the start of every session, always	Facts. Under 200 lines
Skills (SKILL.md)	Procedure and helper scripts for a specific job	Only when that job comes up	Procedures
Hooks	Mechanical processing before and after actions: stop, log, notify	Before and after tool calls, at session start, etc.	Enforcement
cron / schedules	Start work at a time or interval	The scheduled time	The clock

AGENTS.md is the README for agents: a shared format read by many agents including OpenAI's Codex and Google's Jules, used by more than 60,000 open-source projects³. Claude Code reads CLAUDE.md, but you can write @AGENTS.md to import it, so one document serves both⁴. The official docs are clear on how to write it. Aim for under 200 lines per file; longer files consume more context and reduce adherence. Write instructions concrete enough to verify: "use 2-space indentation" rather than "format code properly", "run npm test before committing" rather than "test your changes"⁴.

The same document gives the criteria for what to add. When the agent makes the same mistake a second time. When a code review catches something it should have known about this codebase. When you type the same correction you typed last session. When a new teammate would need the same context. Add only then⁴. Put the other way round: otherwise, do not write it.

Skills are procedures. In the open Agent Skills specification, a skill is a folder containing a SKILL.md with name and description metadata plus instructions, optionally bundling executable scripts, reference material and templates⁵. The dividing line from AGENTS.md is one sentence in the official docs: create a skill "when you keep pasting the same instructions, checklist, or multi-step procedure into chat, or when a section of CLAUDE.md has grown into a procedure rather than a fact. Unlike CLAUDE.md content, a skill's body loads only when it's used"⁶. Facts in the always-read document, procedures in skills. That separation is the first means of keeping context small.

Hooks are enforcement. This is the part most people overlook. Claude Code's docs state that CLAUDE.md and memory are treated "as context, not enforced configuration", and that to block an action regardless of what the agent decides, you use a PreToolUse hook⁴. Write "do not touch production" in a document and it is context: likely to be respected, not guaranteed. A hook runs an external script immediately before a tool executes and stops it if the condition is not met, so it is a guarantee. Sending data outside, changing production, reading secrets: operations where one mistake is one too many are stopped by hooks, not documents. I collected the event types and how to write them in The complete guide to Claude Code Hooks.

cron is the clock. Claude Code has three modes: /loop, which repeats while a session stays open; Desktop scheduled tasks on your own machine; and Routines, which run on Anthropic-managed cloud. Per the official comparison, the cloud mode needs no machine left on, runs autonomously without permission prompts, has a minimum interval of one hour, cannot touch local files, and runs in a fresh clone⁷. Unattended work goes to the cloud; work that needs local files goes to Desktop. Open-source agents such as the one I covered in the Hermes Agent guide have cron of the same kind, and deny dangerous commands by default when running unattended. For unattended work, decide the stopping line first. That holds for every tool.

Growing internal context as a knowledge-graph-shaped dataset

Even with the four parts in place, if the "internal knowledge" the agent reads is scattered, it searches from scratch every time. Here is what I consider the most important idea: hold internal context not as a pile of documents to search but as a dataset you grow.

Karpathy's short "LLM Wiki" note from April 2026 states it most concisely. Most people's use of LLMs with documents is RAG: retrieve relevant chunks from raw documents at query time, with no accumulation. He proposes instead that the LLM ingest what it reads and continuously maintain an interlinked Markdown wiki. Each time a new source arrives, the LLM summarises it, updates existing pages, and flags where new data contradicts old claims. "The knowledge is compiled once and then kept current." He describes the arrangement as "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase"⁸.

Three things in that note matter most to me. First, the three layers: raw sources (immutable; the LLM reads but never modifies them), the wiki (owned, written and maintained by the LLM), and the schema (CLAUDE.md or AGENTS.md, the "key configuration file" defining the wiki's structure and conventions). Second, the "lint" operation: periodically have the LLM health-check the wiki for contradictions between pages, stale claims superseded by newer sources, orphan pages with no inbound links, and concepts mentioned but lacking their own page. Third, the business-team application: an internal wiki fed by Slack threads, meeting transcripts, project documents and customer calls, maintained by the LLM with humans reviewing⁸.

"Knowledge-graph-shaped" means holding those cross-links explicitly, as entities such as people, products, customers and problems, and the relations between them. Our ZEROCK holds internal documents in that form (GraphRAG) so an agent can trace the connections between this customer, this product and last year's failure. But my point here is not the product; it is the order. Do not start by building a graph. Take the interview extractions from Part 1, the hypothesis ledger from Part 2, the four documents from Part 3, put them in one place as a Markdown wiki, have an agent maintain it, and run lint once a week. That alone lets next week's agent start from "what we knew as of last week". The graph gets drawn once the wiki has grown and the need is real.

Three disciplines for running it as an organisation: update, exclude, frequency

This is the heart of the article. Tidying context as an individual and running it as an organisation are difficult in different ways. Alone, you notice when the document drifts from what is in your head. In an organisation, the author moves on, assumptions change, and nobody fixes the document. The agent reads that stale document faithfully, every time. Whether performance stays stable depends on three things.

Discipline 1: keep updating the context. Decide the triggers in advance. Make "the same mistake twice", "caught in review", "the same correction typed twice" the team's rules. Decide who writes. My recommendation is that the agent drafts and a person reviews and merges. As Part 3 said, documents are code. Changes to AGENTS.md go through a pull request so the diff is seen. When the owner changes, the history remains.

Discipline 2: exclude information outside the context. Harder than updating is deleting. Anthropic's context rot advances as stale text, duplicates and irrelevant material pile up. Two criteria. One: never write what can be derived from code or documents. Claude Code's /doctor proposes trimming content derivable from the codebase, such as directory layouts and dependency lists, and keeping pitfalls, rationale and conventions that differ from defaults⁴. Apply the same criterion to documents people write. Two: move anything that need not be read every time out to paths or skills. A convention needed only in one directory goes in a path-scoped rule and loads only when those files are touched⁴. Procedures go to skills. That is how the always-read document stays under 200 lines. Deleting is frightening. So have the agent do the lint: "list the statements in this document that can be derived from the code, that have not been referenced in six months, or that contradict other documents". A person makes the deletion decision; the agent produces the candidates.

Discipline 3: raise the frequency of skill updates. Skills are procedures, so they go stale as the work changes. Nothing is more dangerous than an agent faithfully executing an outdated procedure. Claude Code's docs provide a way to find unused skills and a process for evaluating and improving them⁶. The cadence I recommend is weekly. Once a week, a person grades the results of the skills used that week and fixes the steps that missed. A skill that was never used has either a bad description or no reason to exist, so fix it or delete it. Whether this weekly lint-and-grade loop runs is the difference between organisations whose agents are stable three months later and those whose are not.

What the three disciplines share is that the weight is on keeping, not writing. Anyone can write an impressive AGENTS.md at the start. Whether, six months later, it is still 200 lines, still correct, still free of contradictions, is where an organisation's AI adoption succeeds or fails.

Designing a recurring job with the four parts

One worked example, end to end: automating the interview extraction and ledger update from Part 1, every Friday.

First, facts in AGENTS.md: where the ledger file lives, what its columns mean, the rule "never mark verified on one statement", and the prohibition on reading any file that has not been masked. Twenty lines is enough. Next, the extraction procedure as a skill. SKILL.md holds the Part 1 prompt verbatim, the rules requiring quotes and timestamps and flagging post-mock statements, and the output format. A helper script bundled with it detects candidate personal data in transcripts mechanically.

Two hooks. One stops the agent if it tries to read a file whose masking is not complete. The other requires human approval before any operation that sends results to Slack or outside the company. Not "do not send" in a document, but a mechanical stop. Finally, cron starts the skill at 17:00 on Fridays. If it runs unattended, choose the cloud mode with no permission prompts, and in exchange let the hook hold every send for approval.

Then Monday. The owner spends ten minutes reading the diff of the ledger the agent updated and the extraction. If an insight without a quote slipped in, fix the skill's procedure. If a ledger column is missing, fix AGENTS.md. Those ten minutes are the substance of disciplines 1 and 3. Once a month, run a lint of the whole wiki and prune contradictions and stale claims. That is discipline 2.

The trap for large companies is their past with internal wikis. Most have one that nobody updates any more. To avoid repeating that with agents, fix the division of labour from the start: the agent does the maintenance, people only review. In Karpathy's words, "the wiki stays current because the LLM does the maintenance that no one on the team wants to do"⁸. People do the reviewing and the deleting decisions.

In WARP we assemble these four parts on participants' themes and run them unattended for a week. The full methodology of the four-part series maps onto the programme structure on the WARP page.

Wrapping up

The performance of recurring work is decided by the context machinery, not by prompts. Facts in AGENTS.md, procedures in Skills, the stopping line in Hooks, the time in cron. Internal knowledge grown not as a pile to search but as a wiki the agent maintains and people review, with a graph drawn when needed. And when an organisation runs it, everything depends on three disciplines: keep updating, exclude what lies outside the context, and raise the frequency of skill updates.

Across the four parts, what I wrote about was, in the end, order. Listen, then build. Turn what you built into hypotheses. Turn hypotheses into documents. Turn documents into machinery and run it weekly. AI speeds up every step; it does not decide the order. If you do one thing tomorrow, open your AGENTS.md and count the lines. If it is over 200, start by finding the lines that can be derived from code or documents. If you want to design your organisation's context with us, let's talk through a consultation.

Footnotes

1. Andrej Karpathy (X, June 25, 2025): "+1 for "context engineering" over "prompt engineering"…" (replying to tobi lutke's June 19 post: "the art of providing all the context for the task to be plausibly solvable by the LLM") ↩ ↩²

2. Effective context engineering for AI agents (Anthropic Engineering, September 29, 2025) ↩

3. AGENTS.md — A simple, open format for guiding coding agents ("used by over 60k open-source projects", retrieved September 12, 2026) ↩

4. How Claude remembers your project — Claude Code Docs (CLAUDE.md and auto memory, the 200-line guideline, when to add, importing AGENTS.md, /doctor, path-scoped rules, "context, not enforced configuration") ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

5. Agent Skills Overview (agentskills.io, the SKILL.md specification) ↩

6. Extend Claude with skills — Claude Code Docs (when to create a skill, finding unused skills, evaluating and iterating) ↩ ↩²

7. Run prompts on a schedule — Claude Code Docs (comparison of /loop, Desktop scheduled tasks and cloud Routines) ↩

8. LLM Wiki — A pattern for building personal knowledge bases using LLMs (Andrej Karpathy, GitHub Gist, April 4, 2026) ↩ ↩² ↩³