I got tired of running team operations by hand.
Our founding team's standups happened in a channel when people remembered. Our GTM tracking lived in spreadsheets nobody updated. Weekly reports took an hour to compile and were read by no one. And nobody could answer the simplest question: "Are we on track?"
So I built a company brain. It's an AI agent that lives in our Discord, runs daily standups, tracks our GTM numbers, and generates dashboards. We named it Dojo. It costs about $2-5 a month to run.
Here's what it does every day:
The weekly workflow reads those JSON files and generates a dashboard with charts: targets vs actuals, per-person contributions, trend lines. The monthly report adds channel breakdowns and strategic recommendations. The quarterly review checks the full-year trajectory against our revenue target.
The whole thing runs on:
The stack: a Hermes Agent instance with a dedicated profile, a SOUL.md identity file, 13 skills (workflows), and a data folder of JSON files. Everything is files and schedules — no magic, fully inspectable.
The idea came from Gumclaw, the agent that runs all of Gumroad's operations. If an agent can run a company's support and engineering, I figured it can at least run our standups. It was right.
Lessons after a month of running it:
If you're a founder still compiling standups by hand, clone it and run your first standup tomorrow. It takes an afternoon, not a quarter.
The "people stop replying to standups after two weeks unless leadership answers first" line should be at the top of this post. That's the insight usually discovered after four failed async rituals, not documented in the same post that introduces the tool.
The parsing rules > model choice observation is right too. Most agent work doesn't require the most powerful model — it requires the most precise workflow definition. Tight specifications on cheap LLMs outperform expensive models on vague prompts consistently.
The silent failure monitoring note is what people almost always skip until something breaks. An agent that fails quietly is worse than no agent because the absence of output looks like absence of activity, not system failure. Learned that building my own agent layer the hard way.
Two weeks in — what's the metric that matters most to you? Standup participation rate, quality of the weekly dashboard, or something else?
Running this off an old Mac mini with DeepSeek for like $3 a month is peak indie hacker setup. Keeping everything in JSON files and plain cron jobs instead of paying $50/mo for a bloated SaaS tool or setting up a massive vector DB is so underrated. Quick question—how are you actually monitoring the gateway so you get pinged if the cron or agent silently crashes?
What's fascinating is that it's not the inexpensive LLM that is the real key to this. It is surrounded by a structure which is.
A trustworthy and debug-friendly agent that has predictable workflows, clearly defined parsing rules, and visible data helps to ease the burden of trust.Making the agent more visible, predictable, and having clearly defined parsing rules makes the agent much easier to trust and debug. A good example of this, for many internal automatons is to be flexible in the model, but boring and deterministic about the surrounding system.
It's also the culture lesson that's important. People will stop responding if leadership doesn't respond to the standup – better automation will not help with that. The system can reveal the behavior, it can't establish the habit.
The difference between the two types of automation, automating coordination and improving coordination, is easy to overlook.
The line about a brain that silently dies being worse than none is the one that matters most here, and I would push it one step further. What happens when it does not die, but starts misparsing replies quietly? You said the parsing rules matter more than the model, which means drift in those rules is a real failure mode, not just uptime. Do you have anything watching for that, or would you only catch it when a dashboard number looks obviously wrong?
The part about people stopping replies after two weeks feels painfully familiar.
The self-learning piece is interesting too. Curious whether the team actually started relying on the generated summaries over time, or if the biggest value is still just keeping the daily workflow from falling apart.
The self-learning part is probably the most interesting piece here. Once the “company brain” starts updating itself, I imagine the harder problem becomes knowing when an old piece of information is no longer true.
How are you thinking about stale or superseded context? For example, if a project decision changes, does Dojo update the old knowledge, keep both versions, or rely on the latest information winning?