Cortex context has become the backbone of my process.
Cortex was initially conceptualised specifically as an engine to feed cleaner, more relevant context into AI; the goal was to produce more token-efficient and context-aware code. However, after the initial AST parsing and data graph code was built, I saw a noticeable increase in quality across new sessions, but I also saw the foundation for a closed-loop agent system that can use the context to refresh itself at every turn.
This theory in my mind solved 2 of the larger issues in the AI space:
- Long-persisting sessions degrade in quality.
- AI agents have to search through codebases on a new session to blindly find and locate the code sites for any proposed changes.
So to use the context foundation to produce a closed-loop coding system initially made sense in theory, but I wanted to see it in practice. So I decided to draw up an initial design of the agentic loop:
-> quality-oriented prompts: putting specific guardrails in place for language rules and best practices to avoid poor-quality code.
-> builder/auditor/QA checker process: configuration-controlled budget per cycle, max cycles, max turns per cycle and number of builder cycles prior to an auditor cycle. The auditor cycle is likely the most important addition to the loop - it keeps quality tight, it reviews for incorrect code, security issues etc., and it keeps the loop honest as incremental progress is made.
-> cortex-context files:
- product.md: technical specification, full breakdown of the system we want to build, everything included; the goal is to be as unambiguous as possible — frontload the decisions so the AI becomes an implementer rather than a decision maker.
- implementation.md: reverse engineer the product document into incremental, linear implementation steps, remaining focused on turning the AI purely into an implementer of the predesigned system.
- directive.md: used to keep track of completed steps, immediate next steps, status and notes - skeleton is created on startup, AI agent amends as progress is made.
- audit-log.md: each auditor cycle writes a full audit report so there is a paper trail as the build continues.
- build-log.md: incremental updates from the builder cycles, steps tackled, any issues, any decisions it did have to make.
With this design, I have been able to deliver multiple new conceptualised systems, some complex, some surface-level, across different domains, and quality held up extremely well. However, to be completely transparent, now that I have also progressed in my skillset - the initial delivery for cortex was not bad by any means, but it has a more efficient design for me to deliver in future - the foundation can remain the same with the context feeding into the loop, but this is how I'd redesign it now:
- I'd use a context-aware cycling mechanism to trigger rollover to the next agent when X amount of the context window has been used. This trigger will have the current agent produce a structured handover detailing the position they picked up from, what work was directly completed, and what was next on the agenda.
- Use a customisable or stronger harness to produce true agentic capability, such as PI or Hermes. I like PI as it has a simple out of the box state with a high level of adaptability, meaning that most likely the cycling mechanism labelled above can be built directly into the harness.
These 2 features allow for a more resilient and robust building loop. I have done similar work with the PI agent harness, extending its out-of-the-box features, so I'm aware of the strong utility this provides. This is the next work for cortex specifically.