I built an operating system for AI agents.
Not a terminal. Not a chat app. A full dashboard that coordinates three agents — opencode (code/DevOps), Hermes Agent (memory/scheduling), and Gemini CLI (research) — into one unified control plane.
GitHub: github.com/modimihir07/agentic-os (https://github.com/modimihir07/agentic-os)
The Problem
I was jumping between three tools:
- opencode for coding tasks
- Hermes for scheduling and memory
- Gemini CLI for web research
No shared context. No central dashboard. Every session started from zero.
The Solution: 7-Layer Architecture
Layer 7 Identity / Constitution
Layer 6 Self-Evolution
Layer 5 Scheduler + Health
Layer 4 Memory Graph
Layer 3 Skills Hub + Eval
Layer 2 Business Brain
Layer 1 Agent Router
Layer 1 routes tasks automatically: code → opencode, memory → Hermes, research → Gemini.
Layer 3 gives each skill a standardized structure (SKILL.md + learnings + eval + score history) so they improve over time.
Layer 4 provides persistent memory via a shared brain/ folder and SQLite FTS5 — agents remember context across sessions.
12 Features
- 3-Agent Engine — opencode + Hermes + Gemini CLI with auto-routing
- 16 Skills — executable packs with eval scoring
- Cron Scheduler — APScheduler jobs (heartbeat, standup, audit)
- Cost Analytics — track spending across providers
- One-Click Backup — full tar.gz snapshots
- Audit Trail — every action logged
- Prompt Library — 10 reusable templates
- Dark/Light Theme — GitHub-style dark mode
- Standards System — auto-discover project conventions
- Plugin Registry — extend via custom skills
- Client Timeout — 200s AbortController for long queries
- Memory — SQLite FTS5 + shared brain/ files
vs Claude Agent OS
Honest comparison with Julian Goldie's video project:
Claude Agent OS: Claude + OpenClaw + Hermes · $20/mo · Obsidian memory · No cost tracking · No backup · Tutorial only
Agentic OS (Mine): opencode + Hermes + Gemini · $0 (all free tiers) · Built-in memory · Built-in cost tracking · One-click backup · MIT License
Tech Stack
Backend: FastAPI (Python) · Frontend: vanilla JS SPA · Scheduler: APScheduler · Memory: SQLite FTS5 · Cost: $0 (Gemini Flash, OpenRouter free models)
Quick Start
git clone https://github.com/modimihir07/agentic-os.git
cd agentic-os && ./install.sh && ./start.sh
Open http://127.0.0.1:8080
Agentic OS is MIT licensed. Star it on GitHub if you find it useful.
👉 github.com/modimihir07/agentic-os (https://github.com/modimihir07/agentic-os)
Top comments (2)
the scheduler + cost analytics parts are where i'd probably poke first.
once agents start doing background work, the hard question becomes: is this actually a cron job, or should some external event wake exactly one agent with a small payload?
if you expand the plugin registry, i'd be tempted to make "watch this source and route only matches to Hermes/opencode/Gemini" a real job type instead of turning everything into another heartbeat.
Great question — you're touching on exactly the architectural tension I've been thinking about.
Cron vs event-driven: Right now everything is cron-based (heartbeat every 5min, memory consolidation weekly, etc.) because it's simple and deterministic. But you're right — for things like "new commit on a branch" or "new file in a folder," a polling cron is wasteful. The better pattern is: a lightweight watcher triggers exactly one agent with a small payload. Hermes already supports event hooks in its scheduler (pre/post skill execution), so the plumbing is there. The missing piece is a generic event source abstraction — file system watcher, webhook receiver, git hook — that can feed into the same routing layer.
Plugin registry → job types: Love this idea. Instead of "heartbeat" being the only recurring job type, imagine:
job_type: "source_watch"
source: "./skills/"
filter: "new SKILL.md added"
route_to: "opencode"
action: "register_skill"
That turns the registry into a living thing that reacts to changes rather than being manually curated. The router already does keyword-based agent selection — extending it to event-based filtering is a natural next step.
Cost analytics side: The harder problem is attribution — when a cron job spawns an opencode subagent which calls Gemini for research, which agent do you bill? Right now I track per-provider, but per-task attribution across agent chains is the real gap.
I'm building toward a v0.3.0 that adds event-driven job types. Want me to open a GitHub issue so you can follow along?