GrowOS — Project Story
Inspiration
The idea came from a simple frustration: I kept building productivity systems for myself that worked for exactly one week.
Todo apps, habit trackers, Notion dashboards — I'd set them up perfectly, feel good about it, then stop opening them. Not because I didn't care. But because every morning I still had to decide what to do, still had to manually log things, still had to remember to check in with myself. The system required me to maintain it. And that's the part I kept failing.
At some point I realized: the best system is one that runs without me. One that shows up even when I don't.
I'm a big fan of Solo Levelling — the manhwa where a weak hunter becomes the strongest through a system that tracks his growth, assigns quests, and pushes him forward relentlessly. That "System" character stuck with me. It never judged. It never punished. It just kept showing up with the next mission.
That became the product vision: what if that System was real, and it lived in your Telegram?
What I Learned
Autonomous ≠ scheduled. The hardest lesson was understanding the difference between a cron job that sends a message and an agent that actually reasons. The 22:00 nightly loop taught me this concretely — parsing natural language replies, classifying completion state, detecting patterns across multiple days, making a decision to switch modes, generating new content, and overriding its own schedule. Each step depends on the previous. That's a reasoning chain, not a timer.
ADHD-first design changes everything downstream. Once I committed to "no penalties, ever" as a non-negotiable constraint, it forced every other design decision into a different shape. The XP engine only adds. The streak never breaks. Difficulty scales down on failure, not up. These aren't features — they're the product philosophy made concrete. Without the constraint, I would have built a more conventional system that felt punishing to use.
State design is the hardest part of multi-agent systems. Five agents sharing state via files sounds simple. In practice, every agent needs to know exactly what the previous one wrote, in exactly the format it expects. The adjustment_log.md → Friday Review chain was the clearest example: the nightly journal had to be structured precisely enough for the review agent to extract meaningful patterns, but human-readable enough to be useful in a demo. Getting that contract right took longer than any individual mode.
The demo is a product. For a hackathon, the video and pitch are as important as the code. I spent real time designing the 5-day seeded history so the Recovery Arc story arc would be visible in the dashboard. A real story — Monday strong, Tuesday slump, Wednesday crash, Thursday recovery, Friday review — communicates the product better than any explanation.
How I Built It
I started with two research sessions — one with Grok to validate the concept space, one with Claude to pressure-test the architecture and the ADHD-first design assumptions. I wanted to know whether the behavioral design principles were grounded (they were).
From there I wrote a full blueprint (growos-blueprint.md) followed by a Technical Requirements Document (growos-trd.md) before writing a single line of implementation. The TRD forced me to answer questions I would have hit mid-build later on.
The build happened in Cursor using Claude Sonnet 4.6. I built everything as skill mode files — markdown documents containing detailed LLM instructions for each agent mode — deployed on the Hermes agent framework. The architecture maps five conceptual agents to one Hermes skill with seven cron jobs and a gateway session handler for inbound messages.
Key build sequence:
- Scaffold + smoke test (cron fires → Telegram message arrives)
- Onboarding agent (profile schema drives everything else)
- Outbound loop (07:00 / 13:00 / 20:00 crons)
- Nightly analysis (the hardest mode — 6 sequential steps)
- Recovery Arc (slump detection + autonomous override)
- Friday Review (reads
adjustment_log.md, generates narrative) - Dashboard (Streamlit, reads live state files)
- Demo seed data (4-day story arc for the video)
Challenges
The gateway session. The outbound loop (crons pushing messages to Telegram) was straightforward. The inbound loop (user replying, sending commands, saying "done main") was much harder to specify. The gateway handler needs to parse natural language, route to the right mode, check rank gates, handle partial matches, and update state — all in one invocation. Writing that routing logic clearly enough for the LLM to execute reliably took significant iteration.
Validating Hermes CLI before writing setup.sh. I initially wrote setup.sh with made-up CLI commands (hermes skill create, hermes cron create --telegram-token). None of them were real. I had to stop mid-build, query the actual Hermes agent about its CLI syntax, and rewrite the entire setup script from scratch. The correct pattern turned out to be filesystem-based skill installation — skills are just SKILL.md files in ~/.hermes/skills/ — with hermes cron create "schedule" "prompt" --skill name for jobs. That's a fundamentally different mental model than I assumed.
The autonomy claim. The rules require the agent to demonstrate genuine autonomous reasoning. I was initially tempted to call everything "autonomous" — but the honest answer is that most of the system is well-designed scheduling, not reasoning. The Recovery Arc is the one place where the agent genuinely classifies state, generates content that didn't exist before, and overrides its own behavior. I spent extra time making sure that loop was the clearest, best-documented, most-demonstrable part of the build — because if judges probe one thing, it'll be that.
Time. This was a 12-hour build condensed into one intensive session. The hardest tradeoff was between completeness and demo quality. I chose to make the seeded demo data and the Recovery Arc story arc perfect, and accept that some secondary features (hidden quest probability, rank unlock ceremonies) are specced but not battle-tested. For a hackathon, a compelling demo of the core loop beats an untested complete system.
The Thing I'm Most Proud Of
The nightly journal → Friday Review data chain.
Every night at 22:00, the agent writes a structured entry to adjustment_log.md:
completion_rate: 2/3 quests (67%)
pattern_notes:
- Side quest skipped 2x this week
- Health quest completed every day — strong VIT trend
friday_review_flags:
- Flag: reading consistency needs attention
- Positive: 3-day movement streak — acknowledge in review
On Friday, the Review agent reads the entire week of these entries and produces:
"You skipped reading 3 times — INT growth slowed. Next week: 10 pages instead of 20 to rebuild the habit."
That's not a stats summary. That's a coach's note. The agent noticed a specific pattern, understood what it means for progression, and made a concrete recommendation. It can only do that because the nightly agent wrote structured reasoning that the weekly agent could read.
That's what multi-agent memory chains are supposed to feel like.
Log in or sign up for Devpost to join the conversation.