my_architect is a visual architecture tool: WBS, User Story Mapping, C4 and UML live on one React Flow canvas, with its own MCP server running alongside, through which an agent reads and edits the project hierarchy, requirements and docs. "Engineering notes" is where we take apart how the tool works inside and what engineering decisions stand behind it. Not press releases or feature tours, but honest write-ups of specific problems: what hurt, which hypothesis we tested, what worked in the end, and what turned out to be hype.
The project's defining trait is that it runs itself. Every my_architect feature is first entered as a node in its own hierarchy, grows requirements and a source-of-truth doc, and only then gets built — by the same agent, through the same MCP. This is dog-fooding in its purest form: the tool goes through its own pipeline before a user ever sees it. So our notes aren't abstract musings about "AI agents in general" but telemetry from real runs, release numbers, bugs caught before production, and figures we measured on our own repository rather than copied from someone else's marketing.
For a reader who broadly understands the problems of LLM agents but hasn't been inside our tasks, expect stories with a beginning and an end. We try to explicitly separate measured facts from opinions and to invent nothing — if we didn't check something, we say so. These are notes from practitioners for practitioners, not a showcase.
How the agent's working loop is built in my_architect: get_next_task, start_task, complete_task, the status cascade up the hierarchy, the blocker gate, and docs as a living source of truth.
How we gave the my_architect agent persistent memory of the repository through a local code graph — and baked in a discipline that forbids trusting a stale index.