-
-
-
-
-
-
AEP governance in action as a CODEX agent and its subagents work within the tight constraints of COSMOS, the system wide predecessor to AEP.
Inspiration
I was inspired by frustration more than anything. Coding agents can be exceptional early on in project work, however they can also tend to "do whatever they want" when left to work unchecked, even with well made AGENTS.md files or trying to keep "memories" for a project. So I was inspired again by the auto mode categorizer when I had been customizing it for a project - I wanted to make decisions, instructions, and requirements "Mechanically" enforced and not just "Rationally" enforced. Time for some code.
What it does
AEP serves some core roles that are split between the "Rational" agent based features and the "Mechanical" code/script based features.
AEP comes with a framework of context light skills for many coding languages, planning patterns, and best practices. These are then backed up by CLI tooling, git hooks, agent definitions (Designed via the ChatGPT documentation), ADR lifecycle management, and strict project definitions and rules that are generated and has verified to prevent AGENTS.md and like files from being subject to drift and tampering. They are core and spokes based designed, so the specifics of a given skill are only fetched on demand, however the Agents are aware of all skills via their plugin/skill *-core installations.
ADRs are a formal way to record your decisions into amend only laws that govern your project. They are both enforced via the agents AND the mechanical tooling. There is a strict mechanism for minting, amending, updating, superceeding, and maintaining ADRs in the project ecosystem. This check backed decision record become invaluable at preventing drift and banned/prevented actions. It is less a harness, and more like rails for the train of production to run on.
State management of Temp work vs ratified Documentation and Deliverables is essential, and AEP comes with strictly defined schemas and artifact templates for dealing with the mundane yet very essential act of directory heigene. The dedicated Janitor agent definition is an unassuming, but quite essential part of the puzzle as well.
How we built it
Painfully over a large amount of time and teration in a much larger full system ecosystem the first iterations of what would eventually become AEP was made. Over time, I would distill skills from my own work, or online (open source, free information, etc) to create a strictly curated set of skills and workflows.
Once that was completed, I used CODEX and GPT 5.6 Sol to do basically all of the heavy lifing of taking the spirit of that system and turning it inot a flexible template to build any other type of code based project around. Then, it was tried and tested on RAIDA and the Text to Speech demonstration shown in the attached video.
Challenges we ran into
A core challenge was tuning the strictness. Too many hooks, requirements, and guard rails could spiral an agent into an infinite review loop of never progressing. So taking the time to iterate on the tightest governance I could build that doesnt choke out results was the largest and most time consuming part.
Testing was difficult, as separating the "GPT is just good" vs AEP is helping was something initially thought to be quite challenging. However, to reproduce how much more effective AEP is, I would simply encourage a user to try to build a full deferred rendering engine in a single sitting with just a raw agent, then do it with AEP. The difference after even the first hour becomes apparent.
Accomplishments that we're proud of
Making RADIA in a single session was amazing. Then, when runnig into micorphone issues, getting an AEP project set up to control OBS and generate a Text to Speech presentatino using my own voice from another one of my vidoes in a single session was almost as impressive as the rendering engine creation. GPT 5.6 Sol works very well within the AEP ecosystem, and felt like a design partner more than an agent I had to order around and constantly remind about every little detail.
What we learned
A combination of "Rational" and "Mechanical" is the best way to set up Agent based environments. And also having a good "Janitor" for all the artifacts and experiments is very, very important for hard drive space.
What's next for Agent Enhanced Projects (AEPs)
A complete Rust based game engine development system with complete MCP, LSP, CLI, and Agent support. Singularity engine built up on the Radia rendering core will be a fun next step!
Log in or sign up for Devpost to join the conversation.