An agent is a folder structure.

You are helping me design a month-end close for my company, built on best practices and written so an agent can run it with a human owner. Read CLAUDE.md, CONTEXT.md, intent-framework.md, docs/systems-of-record.md and runbooks/month-end-close.md first.

Then interview me, one topic at a time, until you can fill every <placeholder> in those files:

1. The entity, the revenue model, and how customers are billed and paid.
2. The systems of record for ledger, bank, spend, payroll, billing and CRM, and who owns access to each.
3. The team: who owns the close, who operates it, who reviews it.
4. Today's close: how long it takes, what breaks, what is manual, what the reviewer complains about.
5. The policies that exist in writing, and the ones that exist only in someone's head.

When you have enough, produce:

- runbooks/month-end-close.md rewritten for my company: every phase with owner, inputs by system and report, outputs, checks, and a cutoff calendar.
- One starting SOP per phase in runbooks/sops/, with each step's freedom level.
- A proposed decisions/materiality-decisions.md with thresholds and the rationale for each.
- CONTEXT.md with my systems in plain words and my glossary.
- A list of everything you could not determine, phrased as the exact question I need to answer.

Rules: do not invent accounts, balances or approvals. Mark every assumption. Never propose that the agent post, pay or send anything; propose what it prepares and what the human signs.

Read the last close: data-index/close-runs/<run-id>/run.json and units.json, and the package in summaries/close/<YYYY-MM>/. Read runbooks/month-end-close.md, the SOPs, intent-framework.md and decisions/.

Find, with evidence from the run record:

1. The units that took the most time, and why.
2. The units that waited on a human, what they waited for, and whether the answer was the same as last time.
3. The units that were reworked, and the source of the rework.
4. The steps that were done by hand but are deterministic enough to become a script or a check.
5. The checks that never fail, and the checks that were never run.

Then propose changes, each as: the file to change, the exact edit, the evidence, and the hours it should save next period. Separate three kinds of change:

- Runbook and SOP changes (process).
- Skill and agent changes (how the agent works a unit).
- Freedom-level changes: units that earned a move from FL3 to FL2, or that need to move back.

Do not change any accounting treatment. If a treatment should change, write it as a proposed decision record for the owner to accept. Do not touch prior run records.

Read docs/systems-of-record.md and runbooks/month-end-close.md.

For every phase and unit in the runbook, list what the agent must read and what, if anything, it must write. Then for every system, determine the best access method, ranked: an official MCP server, then a documented API, then a scheduled export, then the browser. Check whether an MCP server exists for the system and say how you know.

Write docs/mcp-inventory.md with one row per system: what it is needed for, the ranked access methods, read versus write, who owns the credential, and what stays human no matter what.

Rules: do not recommend write access where read is enough. Never put a credential in any file in this folder; say where it should live instead (.mcp.json, gitignored). Flag any system where the only access is the browser, and say what that means for the close calendar.