The author’s core insight is to remove the blackboard from source control. Another insight I’ve found is to compact the agent state log. I typically do this by having plans and implementation docs written at commit time and checked into .docs/. This separates the activity communication stream from codified documentation. You can then “compact” the state log by just keeping the last N lines.
Technical constraint I want to mention: I just switched off of using .design/ because it was just too frustrating how many things don't see hidden files. The hidden directory was a win like 5% of the time, and annoying the rest of the time.
> The author’s core insight is to remove the blackboard from source control.
That's only because of a deficiency in CI. If you get smarter CI that doesn't trip on files unrelated to the build, using the repo as a blackboard or wiki is probably fine
Having somewhat accidentally also discovered this pattern, I do recommend figuring out some kind of compaction/deprecation method, potentially history-preserving, potentially just letting the git commit messages themselves serve as the canonical history.
The biggest problem I encountered using a similar setup for doing long-term and iterative data analysis is error propagation. My team and I are characterizing and modelling a physical system, there are real-world experiments that need to be run and then fed back into the analysis pipeline and then the next frontier of questions comes up. Any time there has been an erroneous analysis somewhere along the line, that error continues to be treated as a correct fact until it has been decisively eradicated. If one analysis script or document has the error written as a correct fact, that error will continue to pollute future analyses. Oh and these errors can also end up in the agents’ memory files as well. I have gotten very careful about making sure that every reference is corrected everywhere because it seems that the initial error is weighted heavier than the correction.
I have to say, when I first heard about Origin, I was skeptical. But now I do believe that the team behind it is capable of pulling it off and shipping something truly incredible.
This is one of the best technical articles I’ve read. And I came away a lot more knowledgable about a technology I have used daily for over a decade and consider myself adept at. Kudos to the author.
This is exactly why I built https://github.com/andonimichael/arxitect . I’ve found that agents by default produce tactical but brittle software. But if you teach agents to prioritize software architecture and design patterns, their code structure becomes much much better. Additionally, better structured code becomes more token efficient, requires less context to make changes, and coding agents become more accurate.
> Larger composition, though, starts to run into typical software design problems
I've been seeing the same thing. Where agents are great solving the immediate task, but as changes compound they run into software & architectural design problems. I created https://github.com/andonimichael/arxitect to help at least have coding agents self reflect on their software design. But I really like your approach to self-modification and improving the agent itself instead of just teaching it another skill in it's context.
I can’t imagine that will stay the case though. I built https://github.com/andonimichael/arxitect as a first step to using agentic coding in a more production ecosystem. Agents will be able to write useful (and high quality) software over time, their training has just under-prioritized code quality thus far
- Full content analysis by Primary LLM (Default is Gemini 2.5 Pro) with link hard-coded alongside each piece of content with structured output for better parsing.
- Temperature right down (0.2), strict instructions to synthesize, precise prompts to attribute links exactly and without modification.
What I hope to introduce:
- Hard-coded parsing of links mentioned in final report to verify with the link map created throughout the research journey
- Optional, "double-checking" LLM review of synthesized content to ensure no drift.
- RAG enhancements for token-efficient verification and subsequent user questions (post-research)
Do you have any further suggestions?
Right now I hope to strike the delicate balance between token efficiency, with enhanced grounding as optional settings in the future. I have a big task list of things, and this is one of them. I will ensure to re-prioritize alongside user requests for the different features.
Of course, being open source, contributions are highly welcome. I would love to see large community involvement. Collaboration benefits everyone.
P.s. I have spent hundreds of dollars in tests. I'd say for every 1 hour of building, about 3 hours of testing have gone into this, debugging, optimizing quality, ensuring guard-rails are in place.
If you go to the repo, also check out the config/prompts.py file - it will give you a little more insight into what is going on (there are code checks as well, but generally it gives you an idea).
Wow what a great tool! Intuitive and clean interface with realistic default equity investments/option pools. Also I love to see more and more svelte projects popping up. Really exciting seeing its growing adoption :)
reply