Cortex context has become the backbone of the development 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, new sessions showed a noticeable increase in quality, and the code also provided the foundation for a closed-loop agent system that can use the context to refresh itself at every turn.

In theory, this solved 2 of the larger issues in the AI space:

  1. Long-persisting sessions degrade in quality.
  2. 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 it needed to be seen in practice. So an initial design of the agentic loop was drawn up:

-> 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 to be built, 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, multiple newly conceptualised systems have been delivered, some complex, some surface-level, across different domains, and quality held up extremely well. However, to be completely transparent, as engineering skills have also developed - the initial delivery for Cortex was not bad by any means, but a more efficient design can be delivered in future - the foundation can remain the same with the context feeding into the loop, but this is how it could be redesigned now:

  1. 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.
  2. Use a customisable or stronger harness to produce true agentic capability, such as PI or Hermes. PI is a preferred option 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. Similar work with the PI agent harness, extending its out-of-the-box features, has demonstrated the strong utility this provides. This is the next work for Cortex specifically.